Waveforms can't have 0ms attack/delay/release values

[ThePythonator]

Calling channels[x].trigger_attack() when channels[x].attack_ms = 0 causes a divide by zero error. This also happens with decay and release.

The code which causes this error is in audio.hpp.

[ThePythonator]

A quick fix (as suggested by @Daft-Freak ) would be to not allow adsr_end_frame to be 0: adsr_end_frame = std::max(uint32_t(1), adsr_end_frame);

[Daft-Freak]

Realised I've been working around this for a while: https://github.com/Daft-Freak/32blit-music-player/blob/a4cffc81413696586c7e1eaec0ab2cfc4389118e/mp3-stream.cpp#L237-L239

Clamping adsr_end_frame to a minimum of 1 would be the simplest fix, but does mean you get a 1-sample duration. It at least seems cleaner than

if(![phase]_ms) {
  adsr = [target];
  trigger_[next_phase]();
  return;
}

In all the trigger_[phase] methods...

Edit: Whoops, posted at the same time!

[Gadgetoid]

Looks like we need the ability to disable/bypass the envelope generator altogether?

The >0ms transition times are generally intentional to avoid pops/clicks from harsh audio transitions, but it would seem that's not always the desired outcome for wave samples?

[Daft-Freak]

I suppose you might want to use it as a fade-in/out for MP3-based music? Otherwise I just want to either mix a bunch of waves (DOOM) or could do without the entire audio system (emulator)... But as always, I'm slightly misusing everything :)

[Gadgetoid]

Your kind of misuse is the best kind of misuse, though, and anything we can fix to support that is probably a net benefit for the future of 32blit. Getting the audio-engine out of the way certainly isn't the crime of the century. :laughing:

Been a while since I touched the audio code, but an ADSR::Disabled state that skips the envelope generator and doesn't advance states might work.