Yep.
Although, thinking out loud here, this would mean either:
A. Every font to get this change would need it’s config.ini edited.
B. One config.ini in a common folder drives all font’s humstarts. (but therefore all the other parameters as well)
C. Some sort of define to globally affect humstart but not other config.ini stuff, and totally optional to leave things as they are.
I thought it was least intrusive to the OS and existing fonts to go with C in my homework last night.
There’s so many ways to approach it; as it is back timed from end or in terms of delay from the front end, percentage or value, globally defined or per font. I’m not sure what’s best right now.
Not saying that at all. I mean, it’s on the font creator to make sure the humstart/out.wavs jive. More times than not though, the same default config.ini is included, if at all.
I was 100% trying to be backward compatible, that was my “least intrusive” intent above.
I was thinking the goal here is adding an optional feature to create a “safety net” for when humstart values are incorrect for the sounds, or missing. An automatic timing feature that would not require editing every existing config.ini file. An optional define that’s easy to implement.
I suppose. Is a global fail safe not a good idea?
I’m thinking how I personally have over 160 fonts and would prefer an option that doesn’t require going through every one of them.
I can only speak from personal experience, so hopefully some others will chime in on all of this.
For me, 99.99% of ignition sounds are a burst with a trailing zhoooom that settles into the hum.
If I had to venture an approximate average of where the hum should start, it’s like you said, at 200 ms from the start.
So that says to me it’s “needed” to have the hum start then.
I think there’s a low probability that the humstart on all these fonts is set appropriately, and again, if the odd looooong sound arises, current humstart doesn’t work for variable length wavs.
So to me, 200ms from the beginning as a default, makes the most sense.
Here’s a bunch of completely randomly grabbed out.wavs
A default only works if there is no humstart specified in the font though.
Otherwise we’re just talking about ignoring what the font says.
Also, does anybody know what a NEC board does if there is no humStart specified in the config file? The humStart was defined the way it is for NEC compatibility after all.
Of course, yes, hence why I thought an optional global override delay value of 200ms from the beginning might just be safe across the board for all fonts. The current default of 100 is delaying playing hum until 100ms from the end of out.wav
“If it wasn’t the first font you loaded it would default to the last value loaded from the last font. If it was the first font you loaded it might cause a crash.”
Seeing the relationship between ignitions and hum are monophonic…wouldn’t it be easier to make it polyphonic for these 2? As stated above, the ignition sound always has some sort of initial burst flare, followed by a slow or fast fade of “wwwhhhhsssssssssshhhhhhhhhh”. I think it would just be easier to have the ignition and hum be polyphonic so the user can have control of when the hum starts playing underneath the ignition, and they can choose to have it start immediately under the initial burst…or slightly in between (of after) the faded “wwwssshhhh” sound.
The hum should be a delay number in milliseconds based on when the ignition started playing, then the user can choose the delay hum start time to 0 ( no delay, hum starts right when you hit the button to ignite your saber), or any value in milliseconds to start the hum delay.
There are two methods for hum->ignition transition. One is gapless monophonic, and it is used if you have a “poweron” sound for ignition. The other is polyphonic, in which case the hum starts playing a specified number of milliseconds before the end of the “out” sound.
The reason it’s implemented like this is because that’s how Plecter and NEC sound fonts works. I made ProffieOS to be compatible with those fonts.
Now, making a better method for this means controlling not just when the hum starts, but how long it takes to fade in as well. And for full control, the starting point would need to be adjustable for each different “out” file.
Using per-file parameters is something that I’ve tried to avoid, because it can potentially use up a lot of memory.
This is exactly what it is currently, although just backwards, and you need to know the length of the out.wav, AND it differs for each wav. Hence my proposal of the #define AUTO_HUMSTART
