I’ve noticed that when I switch a saber on while moving it, a swing sound immediately plays while out.wav is playing. It seems to be triggered by even the smallest motion, and it sounds out of place when first turning the saber on. Is there a way to prevent this from happening, and prevent swings from executing until out.wav is finished playing?
There isn’t an easy way to control this from the prop class since swinging is controlled almost entirely from the hybrid font.
Maybe we should replace fusor.swing_speed() in the code with prop.swing_speed(), and then have prop.swing_speed() call fusor.swing_speed() by default. That way, a prop could override the swing speed and add a multiplier which would start at zero and go up to one.
I don’t love the idea of putting this in the prop file. Would it make sense to treat this like a bug to be fixed? I honestly think that not playing swings during ignition should be standard.
If that’s not an option, then it would make more sense to have a define that could be set in the config file, rather than the prop file.
What prop and OS are you on? Try these two quick changes. Slowly move up your clash threshold and define swing speed and adjust that to where it doesn’t do it but still responds well.
Examples from the prop I am using that usually resolve this.
#define CLASH_THRESHOLD_G 3.50
#define FETT263_SWING_ON_SPEED 200
I’ll take a closer look at how this works tonight.
This is related to some stuff happening on other props as well.
I’m using saber_caiwyn_buttons.h in the current dev master. Clash threshold is already set appropriately, and this issue isn’t related to clashes.
Wait, is this an accent swing/slash that is playing? Or a smoothswing sound?
Or something else?
I think it’s a smooth swing sound, but im not 100% certain. It could be an accent swing.
Check the serial monitor?
I have to take out the speaker in order to plug in the usb connection, so I can’t be certain that what I’m seeing in the serial monitor correlates to what I’m hearing, but I ran a few tests without hearing anyways.
It looks like it’s an accent swing. It doesn’t happen every time, but here’s an example where it does. I notice that swingh and swingl are played every time, but the volume for those sounds is 0.00 so I assume these are just continuous loops that increase volume based on the motion of the hilt. The accent swing shown here, however, has volume set to 0.50, which is the same as out4.wav.
EVENT: Power-Pressed#1 millis=152175
EVENT: Power-Pressed millis=152175
Ignition.
unit = 0 vol = 0.00, Playing Caiwyn/hum/hum01.wav
channels: 1 rate: 44100 bits: 16
unit = 1 vol = 0.50, Playing Caiwyn/out/out04.wav
channels: 1 rate: 44100 bits: 16
humstart: 1800
unit = 3 vol = 0.00, Playing Caiwyn/swingl/swingl02.wav
channels: 1 rate: 44100 bits: 16
unit = 2 vol = 0.00, Playing Caiwyn/swingh/swingh02.wav
channels: 1 rate: 44100 bits: 16
Motion chip … I2C init…
Audio underflows: 7
105 found.
unit = 4 vol = 0.50, Playing Caiwyn/swng/swng03.wav
channels: 1 rate: 44100 bits: 16
EVENT: Power-Released#1 ON millis=152346
EVENT: Power-Released ON millis=152346
EVENT: Power-Shortclick#1 ON millis=152346
EVENT: Power-Shortclick ON millis=152346
EVENT: Power-SavedShortclick#1 ON millis=152699
EVENT: Power-SavedShortclick ON millis=152700
After a few more tests I notice that I can make it happen every time if I wait for this message in the serial monitor before turning it on:
I2C sleeping…
I’m able to reliably trigger an accent swing during ignition, even when the saber is sitting on my desk and not moving at all. If I shut down and power it back up again without waitng for the I2C sleeping message, the accent swing does not get played.
This looks like the ol’ Motion Chip initialization triggers a SWING event thing.
This should already be handled by a delay built into the prop file I think, so it’s weird.
Also weird that it doesn’t show EVENT SWING in the messages, yet the accent swing is shown as played.
You mean this is a known issue? What’s the delay that’s supposed to be in the prop file?
Something like this in the gesture for SWING_ON can prevent false ignitions:
if (millis() > (PROFFIEOS_STARTUP_DELAY + 3000)) {
FastOn();
but not sure if yours are triggered by the chip initiating as it didn’t show EVENT: Swing, just the sound playing.
Weird.
What you’re describing is the motion sensor falsely detecting a swing on boot, which can wreak havoc on a saber with SWING_ON gesture enabled. The delay you’re referring to is a workaround that prevents SWING_ON from working for the first 3 seconds after boot, thus preventing any false swing detected in that window from triggering an ignition.
However, my prop file doesn’t support gesture controls at all. I’m just using the power button to turn the saber on. If I let the I2C go to sleep first and then turn the saber on, it plays an accent swing during ignition, even though the saber isn’t moving at all.
I guess it’s possible this is the same issue, or that they are related, but the fix for SWING_ON doesn’t really help in my case.
Since this seems like a bug, I’ve opened a new Issue in github to address this:
It’s been known for a while that the motion chip can produce a bunch of high values right in the beginning. This is why you see a lot of workarounds for this in props. Of course, that’s probably not the right place for such workarounds really. It would be better if these bad values were filtered out before the props ever see them.
It’s a little complicated though, because the bad values are essentially random, and also the amount of bad values seems to vary a fair amount from chip to chip. (Or at least between different batches of chips.)
Possibilities include, but are not limited to:
- ignore gyro values for the first N milliseconds after wakeup. (Not sure how big N would have to be though.)
- multiply gyro values with a value that starts at zero and reaches 1.0 after N millseconds after wakeup.
- Some combination of 1 & 2
- Dynamically detect when the bad/noisy values end and stop ignoring gyro values at that point.
- Employ faires to inspect and remove the bad data
Another possibility would be to disable accent swings until SFX_out is finished playing. That would resolve the specific problem in my case. You’d be treating the symptom rather than the root cause, but that might be the right approach if you don’t mind putting multiple fixes in place for whatever other unwanted effects are caused by the motion sensor wigging out when it wakes up.
Which brings up the question: what other unwanted effects have we seen this issue cause?
“out” can be fairly long in some cases.
I think it may be confusing to people if the saber doesn’t respond to swings for several seconds.
Oh, and using SFX_out as the timer doesn’t work for fixing use cases where the motion is turned on separately from igniting the saber.
In testing for my prop, the style(s) appear to be a factor as well. With very simple styles the bad data appears earlier, with complex styles it appears later when testing different configs on the same saber. I tested across multiple sabers all with v1.5 or v2.2 boards from different batches with different configs and found 2000 ms handled most, even with more complicated styles.
To “handle” motion starting back up after a timeout from a button press I incorporated the FETT263_MOTION_WAKE_POWER_BUTTON define. This restarts the motion on the first Power button press after MOTION_TIMEOUT without igniting the blade. Instead, the first press merely wakes the saber back up, then any subsequent press ignites (this also reapplies the Swing Ignition timer that we have in place at boot).
While not “perfect”, combined with the delay for triggering Swing Ignition on both boot and re-initialize it works to prevent the bad data from triggering a swing while the blade is ON, which then prevents the false swing sound when igniting.
I think #1, 2 or 3 sound promising, just wanted to share my experience more for the N value. Perhaps make the N a define that defaults to 2000 and let users adjust if they need to?