I don’t want all those transitions, I want one transition up and one transition down between two consecutive modes and a way to “stitch” the transitions together when I go between non-consecutive modes. Is that what void RestartHumdoes ?
No. RestartHum will pick a transition based on the previous alt mode.
Of course, if you always transition your alt modes by one step at a time, most sounds would not be used, and you could use a short silent placeholder for those files. (Or a copy of the hum itself.)
So if I go from 3 to 8 in “one click, or one quick move on a rotary encoder”, it will make a transition that will “average” going from ‘3to4 + 4to5 + 5to6 + 6to7 + 7to8’ based on ‘3’ and ‘8’ ?
what? no? there no averaging, how would that even work?
You are either doing 3-4-5-6-7-8, with 5 transitions, or you’re doing one 3-8 transition. The prop, or the style, or whatever is controlling the transitions decides.
A transition is done by telling the current hum to fade out, then start playing alt/{current_alt}/chhum{old_alt}.wav. chhum is linked to the hum file, so once chhum ends, it does a gapless transition to the hum, and the code doesn’t have to do anything extra to make that happen.
As soon as the transition has been initiated, another transition can begin. The chhum is playing in the new hum player, so if it hasn’t ended yet, that is what gets faded out before we start the next chhum. If too many transitions happens quickly, we could run out of wav players.
And by this, I would think it means just setting up a “de-rotate” delay, similar to a debounce, so that input changes <100 or whatever don’t trigger playing anything. Then you end on your number and it plays.
You can see an example of something similar in my prop’s blade length adjustment SPEC. I didn’t want the number read out until the rotation settled for a moment, as opposed to playing partial sounds continuously interrupting itself as rotation occurred.
BCChangeBladeLengthBlade1
void update() override {
hybrid_font.PlayPolyphonic(&SFX_mclick);
this->say_time_ = Cyclint<uint32_t>(millis()) + (uint32_t)(SaberBase::sound_length * 1000) + 300;
if (!this->say_time_) this->say_time_ += 1;
this->fadeout(SaberBase::sound_length);
}
the + 300 is the delay in this case.
I’m playing around and trying to understand if one sound overrides another between altchng, chhum, and tr.
Tr is polyphonic, yes?
I tried to call chhum to monophonically and gaplessly play between the 2 alt hums, but I get altchng instead.
maybe the style code is wrong?
TransitionEffectL<TrDoEffectX<TrInstant,EFFECT_ALT_SOUND,EffectIncrementF<EFFECT_USER2,Int<2>>>,EFFECT_USER2>,
Isn’t that some sort of “averaging” between “previoushum” and “nexthum”, fading one out while two is fading in? I am starting to think that this could totally apply to non-consecutive engine levels (and consecutive ones too of course)
I think you mean cross-fade?
The old hum is faded out over 3 milliseconds, which is nearly immediate.
If there is a chhum, it is responsible for fading in the new hum, if there isn’t the new hum is started immediately at full volume.
Ok well, user error - I was editing the wrong font LOL.
Anyway, after always being a bit confused with these 3 sounds, I just thoroughly tested and can confirm this:
altchng - plays polyphonically over anything. Is triggered with alt folder switch. If it exists, it gets played.
chhum - plays monophonically and gaplessly during the switch between the previous-alt and the current-alt. If it exists, it gets played.
I did not have multiple chhums in different alt folders, only one in the root, but according to profezzorn’s post above, the chhum in the active alt when the switch is triggered is the one that would play, landing in the new current-alt when it finishes.
Also, even if chhum exists, you still need hums in alt folders for it to be played.
Now, tr.wav is also polyphonic and essentially the same behavior as altchng, but is designed to be called from Style code directly, compared to the system-played altchng.
All 3 will play at the same time if they exist, so choose wisely.
1 Like
Nice job! I understand the Alt-sound much better now.
I just need to figure if I want to use altchng or chhum (or a combination of both).
Each thrust level setting (hum) needs an up (accelerate - increase RPM) and down (decelerate - decrease RPM) transition sound.
altchng for up and chhum for down ? But they can’t be playing at the same time!
I am however still not sure if it would sound convincing enough for going between non-consecutive power levels in one move with a rotary encoder?
No, it plays alt{current alt}/chhum{previous alt}.wav
So if you’re transitioning from 5 to 7, it would play: alt007/chhum5.wav.
So if this is an RPM kind of thing, you might want to have something in your prop that delays the transitions. Basically, you would increaes or decrease the alt every so often (say once per second, or maybe once chhum is done playing) until it reaches whatever setting you set the rotary switch to. Not sure if that will end up sounding like a smooth transition or not, but it might be worth a try…
I think we’re saying the same thing?
" the chhum in the active alt (alt005) when the switch is triggered is the one that would play, landing in the new current-alt (alt007)"
In other words, if you are going from a Swedish home (alt005) to an American neighbor’s house (alt007), you’d say “adjö” (alt005/chhum) before walking out the door, then arrive at the destination and converse in English (alt007/hum).
When you return home later, you’d say “goodbye” (alt007/chhum), then arrive home and speak Swedish (alt005/hum).
… unless I am totally still confused.
No, it always uses the files from the new location.
If you transition from alt005 to allt007, it will play alt007/chhum5.wav, then play alt007/hum.wav
Sorry if I dragged it on. I guess the “chhum5” is what throws me off.
It picks which chhum to play based on which alt you came from. (calls Select() on it)
That only works properly if you have the same number of chhum files as you have alts of course.
ahh!
So what if the chhums were not in alt folders, just in the root, but you have one per alt folder, whould it still Select the same index?
/
├── alt000/
│ └── hum.wav
├── alt001/
│ └── hum.wav
├── alt002/
│ └── hum.wav
├── chhum0.wav
├── chhum1.wav
└── chhum2.wav
Yep, so if you transition from 1 to 2 it would play chhum1.wav then alt002/hum.wav
Ah, so I will need to make 82 (9 square plus 1) transitions up (for 0 to 1 plus all the cases between 1 and 10) and 100 (10 square) transitions down (you can only go from 0 to 1 while engine is starting - thrust lever has to be at idle when you start an engine or you risk destroying the engine - it’s in the checklist - but in case of engine failure, you can go from anywhere all the way down to 0)
That is 162 transitions more than I am willing to make! 
So to hammer this to death…
If there’s the same number of chhums as the alt folders :
- in the root, it selects the index of the starting alt folder.
- in the alt folders, it still selects the index of the starting alt folder, from within that alt folder.
If there’s only one chhum in the root level, it plays for all switches?
If there’s only one chhum in each alt folder, it plays the one from the starting alt folder, disregarding index selection?
If there’s a disproportionate number of chhums to the quantity of alt folders, in either root level or in alt folders… random selection?
Different number of chhums in alt folders caused “error in font directory”.
Is that correct now?
not starting alt folder, ending alt folder
no, some will just not be used.
almost
–
It might be easier to remember all of this if I explain why it works like it does:
Basically, I had the option of either playing alt{from}/chhum{to}.wav or alt{to}/chhum{from}.wav, and I chose the latter, because that way it would would automatically work if you just had one file per alt, and since the chhum has to match the hum file to transition smoothly, I thought it would be easier if they were in the same directory.
If I had chosen the other way you would pretty much always need the full set of NxN chhum files.