Now that WavLen is becoming a thing, would it be difficult to tie in the humstart code to calculate ~80% of the out.wav and always be correct?
I suppose, why?
If humstart is set to 1000 and any of the the out.wavs are longer than 1200-1500ms, it’s pretty audible.
If the out.wav is 500, hum is instant.
Just thought it might make sense to have it automatically always start just about 20% into out.wav playing.
Custom settings could still be used. Such as humstart 1500, but also maybe a setting of humstart AUTO ?
The current way to fix this is to extend short out.wav files with silence until the hum starts at the right spot. (Which is usually the crescendo of the out.wav file.) So in you want the hum to start at 100ms, humstart is 1000 and out.wav is 500ms, then you need to extend that file with 600ms of silence.
I wouldn’t mind having a better way to do this, but no hard-coded number ever going to be right for every situation.
That’s exactly what I was saying. Maybe have an auto option that could have the humstart get the time from the out.wav length, and subtract 20%ish.
The adding silence solution works when out is too short, yes, but the case is usually the opposite, where the out contains long audio.
Then you increase humstart and extend the other wav files.
I actually think that the monophonic way of doing the ignition->hum transition is better as it gives the font maker total control over the transition.
While that’s true, I think it’s too late to ever see a retroactive revamp of all the poly fonts produced thus far.
If I wanted to tinker, hybrid_font.h around lines 330ish the right place?
Look up some WavLen stuff from the master?
Yep, that’s the right place. Specifically:
well, this doesn’t work so far.
else {
#ifdef AUTO_HUMSTART
hum_start_ = (1000 * tmp->length() - (tmp->length() * (100/40)));
STDOUT << "humstart: Auto timed to out.wav\n";
#else
if (font_config.humStart && tmp) {
int delay_ms = 1000 * tmp->length() - font_config.humStart;
if (delay_ms > 0 && delay_ms < 30000) {
hum_start_ += delay_ms;
}
STDOUT << "humstart: " << font_config.humStart << "\n";
}
#endif // AUTO_HUMSTART
}
I don’t understand the 1000 *
Something to do with integer division?
Guessing a bit that tmp is the wav’s length.
The 1000 is just converting seconds to milliseconds.
tmp->length() is the length of the chosen out*.wav in seconds.
I must be missing something. I thought maybe just my math was off, but even with this test where I just manually set hum_start_ to 200, I keep getting hum immediately played.
else {
#ifdef AUTO_HUMSTART
hum_start_ = 200;
//hum_start_ = 1000 * tmp->length() - (1000 * tmp->length() * (10/40));
STDOUT << "humstart: " << hum_start_ << "\n";
#else
if (font_config.humStart && tmp) {
int delay_ms = 1000 * tmp->length() - font_config.humStart;
if (delay_ms > 0 && delay_ms < 30000) {
hum_start_ += delay_ms;
}
STDOUT << "humstart: " << font_config.humStart << "\n";
}
#endif // AUTO_HUMSTART
}
Serial monitor does output humstart: 200. Trying 2000 as it seems hum_start is the opposite of font.config.humstart…
Nope. It seems it’s not being recognized, which seems weird since the stock code is just setting hum_start_ which is how long to wait to play hum.
Actually, what it does is to add to hum_start_.
A few lines earlier it sets hum_start_ to millis()
Yes, that’s what I saw, it’s the opposite, so when trying 2000, I expected a 2 second delay for hum. It still played the same as 200, immediately with the out.wav as if it’s not reading hum_start_.
Looking at this, I’m wondering the reason why this does the steps it does.
Couldn’t it be simpler to have just have the config.ini file’s humstart value directly be the delay_ms? Leaving in the check sthat it exists and is between 1 and 30000ms, couldn’t it just be:
if (font_config.humStart) {
if (font_config.humStart > 0 && delay_ms < 30000) {
hum_start_ = font_config.humStart;
}
}
And is the default 100 the fall through if all this is false?
Maybe that’s accounting for a monophonic font. Hmm I still don’t see why just setting a value doesn’t change anything. Still playing hum with zero delay.
hum_start_ is a time not a delay.
The unit is in milliseconds since boot.
That’s why it has to have millis() added to it, which is the current time.
When you set it to 200 or 2000, it means “start the hum at 2000 milliseconds after boot”, which was probably a long time ago.
Yes…I was typing.
The system clock time is running since power on. I get it.
They delay isn’t accounting for all the time that’s passed since power applied.
Now my math is just bad I’m getting humstart: 454396 sort of output
Might be reasonable if you booted ~7 minutes ago.
Ok I got it. Working well!
else {
#ifdef AUTO_HUMSTART
int delay_ms = 1000 * tmp->length() * 25 / 100 ;
hum_start_ += delay_ms;
STDOUT << "humstart: " << delay_ms << "\n";
#else
if (font_config.humStart && tmp) {
int delay_ms = 1000 * tmp->length() - font_config.humStart;
if (delay_ms > 0 && delay_ms < 30000) {
hum_start_ += delay_ms;
}
STDOUT << "humstart: " << font_config.humStart << "\n";
}
#endif // AUTO_HUMSTART
}
I suppose we could have both a percentage and an offset. So instead of:
delay = wavLength - humStart
We could do:
delay = wavLength * humStartPercent / 100 - humStart
humStartPercent would default to 100.
It also means that you could set humStartPercent to 0 and humStart to -200 if you always want the hum to start 200ms after the ignition.