So playing with dual_prop setup here, I noticed that I have hum playing when blade detect latches off.
While it seems much of getting a blaster font to work cleanly involves omitting saber related sounds because they’ll play (preon, out, postoff etc…) I have a common folder that is where it’s picking up hum from.
I type ‘effects’ and no hum is listed, and no hum is shown as playing (only smoothswings inaudibly)
If I do next preset, or boot into blaster mode, there’s no hum. It only plays on blade removal from saber mode.
In trying to find where this is triggered, it seems we do FindBladeAgain() and SaberBase::DoBladeDetect(false), but neither of which can I track down a play hum scenario.
??
*note - in the odd 71 minute sudden hum, it WAS showing as playing in serial monitor
Try the “whatison” command.
(May need ENABLE_DEVELOPER_COMMANDS)
To add to the conundrum, sometimes there are 2 hums (at least, possible more) playing at the same time. Still not reported in serial monitor, but certainly audible. I’ll add different sounding test hums to confirm.
ok ok ok. stop the presses. I should have tested more before posting soo much during process.
now helpful info. First to clarify, this is when in the blaster mode of dual_prop, blade removed.
I found the sound. It’s NOT hum.
It’s Smoothswings that are playing.
The commonBU folder has generic smoothswings originally from TeensySF hence the confusion.
That being said, further testing confirms it’s swingh and swingl , but however they’re supposed to get muted during normal blaster operation gets missed when doing blade removal.
Also, they both play simultaneously, but each time at different volumes to one another, all seemingly as a side effect of whatever’s going on there.
Snips from whatison showing random volumes each time
15:36:37.044 -> Wav player 3: On (eof = 0 volume = 0.02 refs = 1 fade speed = 0.00 filename=commonBU/swingl/swingl01.wav)
15:36:37.044 -> Wav player 4: On (eof = 0 volume = 0.03 refs = 1 fade speed = 0.00 filename=commonBU/swingh/swingh01.wav)
15:36:23.311 -> Wav player 3: On (eof = 0 volume = 0.04 refs = 1 fade speed = 0.00 filename=commonBU/swingl/swingl01.wav)
15:36:23.311 -> Wav player 4: On (eof = 0 volume = 1.71 refs = 1 fade speed = 0.00 filename=commonBU/swingh/swingh01.wav)
15:36:04.676 -> Wav player 3: On (eof = 0 volume = 0.01 refs = 1 fade speed = 0.00 filename=commonBU/swingl/swingl01.wav)
15:36:04.676 -> Wav player 4: On (eof = 0 volume = 0.02 refs = 1 fade speed = 0.00 filename=commonBU/swingh/swingh01.wav)
15:35:54.724 -> Wav player 3: On (eof = 0 volume = 0.93 refs = 1 fade speed = 0.00 filename=commonBU/swingl/swingl01.wav)
15:35:54.724 -> Wav player 4: On (eof = 0 volume = 0.02 refs = 1 fade speed = 0.00 filename=commonBU/swingh/swingh01.wav)
15:35:44.005 -> Wav player 3: On (eof = 0 volume = 0.00 refs = 1 fade speed = 0.00 filename=commonBU/swingl/swingl01.wav)
15:35:44.005 -> Wav player 4: On (eof = 0 volume = 0.00 refs = 1 fade speed = 0.00 filename=commonBU/swingh/swingh01.wav)
15:35:20.532 -> Wav player 3: On (eof = 0 volume = 0.20 refs = 1 fade speed = 0.00 filename=commonBU/swingl/swingl01.wav)
15:35:20.532 -> Wav player 4: On (eof = 0 volume = 0.00 refs = 1 fade speed = 0.00 filename=commonBU/swingh/swingh01.wav)
I fixed it!
I think since dual_prop.h handles DoMotion to make the swings do nothing, having the function still in blaster.h causes confusion.
I put the blaster.h one inside an
#ifndef PROPS_DUAL_PROP_H and volumes of swingh and swingl stay at zero.
1 Like
There is no code that prevents a blaster from using a smoothswing font.
The way to prevent from playing is to not have them in your font path.
Wait.
Is the swingl/swingh in the blaster font path, the saber font path or both?
The DoMotion comment says // Make swings do nothing…so I took it as that’s the code preventing them from playing, which it seems it does indeed.
If swing pairs are in the path, they don’t play with any volume due to that.
Ok, so there’s no cross contamination as I may have alluded to before. That was just me mishearing swing pairs as hum.
That said, the swing pairs are in the blaster preset’s font path, but typically dormant due to the DoMotion bit.
However that bit exists in both blaster.h AND dual_prop.h, so it seems that by doing blade removal, one or neither of them were payed attention to, and the swings played (with no reaction to motion FYI)
The #ifndef in place, sensing if dual_prop is in use, seems to do the trick as per the PR, but please advise if there’s something missed here.
Just confirming that while the edit to DoMotion stops the pairs from disregarding motion and playing even with the board at rest, they do play properly now (tracking motion) and therefore simply NOT having SS pairs in the path is the ultimate answer.