Amp Envelope

[Philip Meckseper]

Hey there,

just about to finally get into my kickstarter WVRs and I was wondering if anybody implemented more full fledged ampo envelopes yet? From what I gathered, the release value accessible through MIDI CC is very short and really only there for avoiding nasty clicks.

I want to build a slightly more sophisticated classic sample player, with attack & release times of up to let's say 1000ms. I am aware this will eat into the voice count but that shouldn't be a problem for me, using the implemented voice stealing priorities.

If this hasn't been done/implemented yet, I guess i have to really go into the nitty gritty of the WVR firmwar, add that functionality myself and make a new firmware? Any pointers on how to go about that? I have my fair share of experience in general Arduino/C coding and some music dsp development on the axoloti platform, but didn't dig into the WVR libraries yet. So I'd be happy about any kind of advice here.

Best,

Philip

[Philip Meckseper]

Also, reading up some more of the documentation, I understand the concept of racks and voices. But is there also a way to simply "program change", ie. switch to a different set of samples for the current voice? Racks are only used for velocity-based switching, correct?

[WVR Audio]

Hi Philip!

MIDI channels and MIDI "programs" are smushed together, on WVR, into a single concept which I call "voices". Each MIDI channel is, by default, mapped to its corresponding voice. From there, MIDI Program Change events on a given channel cause that channel to increment or decrement the voice it is mapped to. This means that all the channels have access to all the voices. On the code side, all these file handles are just a 2 dimensional array: files[voice][note], plus another 1-dimensional array for the racks rack_files[rack_pointer]. I started to implement a system to pause the wave-player, and load a whole other batch of file handles, but I havn't finished it yet.

Setting up volume changes should not cost you any voices. There is one single DSP instruction on every sample processing loop, which is to scale the sample for volume and panning. The wav-player task does this, you would just need to modify it's behaviour, and set up control of the scaling parameter. There is no data pipeline currently for a per-sample volume, only per-channel, which is the MIDI standard. This could be solved in a number of ways, if dynamic, per-sample control of the attack and release is what you want.

I would love to get into the nitty gritty together on this!

Maybe you could take a crack at describing with some precision how you'd like this to work, exactly what kind of control you need, and how finely grained the control needs to be, as midi is just 7-bit for a lot of values, whether on a per-channel or per-note or per-file basis, whether truly dynamic (changes during playback), etc.. I am not familiar with what a classic sample player would offer for amp envelopes.

To get started, here is the line where WVR determines how fast a file should fade out, then decrements the volume by 1 every n loops, so every n samples.

https://github.com/marchingband/wvr/blob/main/src/wav_player.c#L596

[Philip Meckseper]

Thanks a lot for your fast response!

So here a more detailed description of my use case:

- A sample player just like the WVR already supplies, with sample-per-midi-note but also interpolation for "missing" notes, or desired lofi aesthetics.

- Add a classic  A-(D-S)-R amplitude envelope per voice. Now with voice i don't mean your WVR voices, but rather every concurrently played note of a polyphonic instrument. This envelope would have  the same ADSR values for the whole instrument, but the envelope being generated for each new note-on. A & R times between 0.5ms and ideally 2000ms. D and S segments can be ommited for pure amplitude usage. With this amp envelope release you want to simulate the ringing out of lets say a piano key after the note-off message. Right now, if you play a piano sound on the WVR via midi, the release will sound extremely unnatural. And with the attack value you can make sounds swell in slower. Those are two basic but most important aspects of shaping the sound of musical instruments.

- Next step here then would be to also implement a simple (low pass) filter, with another similar ADSR envelope. For a filter, the D & S stages are  important as well.

- Batch loading different sample sets would also be important to turn the WVR into a full sample player instrument. But for me personally, right now, the 16 voices would be enough.

After spending the whole day thinking about solutions for my current project, i think i will have to revert to using a Disting EX eurorack module instead of the WVR as i don't have the time and focus to really dive into working on low level WVR code. I saw the code line you linked, including the release handling. But even wrapping my head around the maths of that is too much for me right now.

While i think your code and the ESP32 should easily be capable of all this (I think you can avoid most floating point maths) I am also not sure if this is the purpose of WVR...

[WVR Audio]

Thanks for the detailed description. That all makes sense.

1) there is interpolation for missing notes currently, but the work of pitch-shifting happens in the WEB UI, and then each pitch is saved separately in it's corresponding note slot in memory. Pitch shifting on-the-fly is unlikely to be possible with much polyphony on an ESP any time soon. There are some high power RISC-V cores (t-head c906/7/8 etc) coming down the pipeline and Espressif seems to be on that bandwagon, so who knows! 

2) this seems very possible, and on a per-voice basis, it would only be a matter of setting fade_factor, and implementing the same thing at the start of playback, and then choosing the right MIDI CC command for it. No WEB UI changes would be needed, or anything fancy.

3) same as 1, DSP with polyphony are unlikely to be possible on ESP any time soon, the FPU is too slow.

4) batch uploading is possible now, there are a few ways to do it, all outlined in the docs, and there is one new (undocumented) way available, which uses .sf2 files to upload, there is a special binary (currently in beta) to play with that.

The math for the fade-out is fairly straight forward, although I know looking at another persons code can be an incredibly brain-melting task, especially when that person is me, and my code is probably chaos. Basically the loop is guaranteed to run at 44.1 khz, so if fade_factor is 4 (the fastest) the math is not that hard ... ((1 / 88.2) * fade_factor * 128) seconds to fade out ... so about 1 ms for the minimum of fade_factor = 4.

Good luck with the Disting module, that looks AMAZING! They have a $30 high performance PIC in there, and I am getting very envious looking at its specs. 😅

I do believe that a RISC-V MCU will come along some day soon with specs like that, at a price that can suit WVR, and I will be ready and waiting :)

[WVR Audio]

For anyone else following this thread, if there is popular demand for long attack/release times, set by MIDI CC commands, on a per-voice basis, let me know, I can work on implementing it. Ideally a feature request in the GitHub can get drafted, and we can hammer out the details.

[David Battino]

CC control of attack and release would be super useful for shaping sounds on the fly. For the release, especially, the option to have a logarithmic or exponential fade as well as linear might sound more natural. Perhaps a third CC could change the curve among convex (fast dropoff), linear, and concave (slow dropoff). Maybe S-curve as well? 

Here's an interesting take on S-curve math: https://signalsmith-audio.co.uk/writing/2021/cheap-energy-crossfade

Some audio examples: https://transom.org/2003/stupid-fade-tricks-2

[WVR Audio]

ok cool, I'll work on that soon.

There are 2 outstanding questions:

1) What CCs to use for these (I am already using CC 72 release time for the anti-pop fast fade-outs)
2) What happens when a sound gets pruned to make room for another higher-priority sound? For consistency it should fade-out fast (based on CC 72) but this may be bad if the listener expects a slow fade-out.

[David Battino]

Unless I’m misunderstanding, I’d think you could continue to use CC72 for release time and extend the maximum duration. The standard CC for attack is 73. For ease of remembering, maybe make CC 22 and 23 release curve and attack curve respectively. (They’re undefined.)For note-stealing, I’d think you’d want an almost instant release. Prob need to try it to hear if that makes sense.

[WVR Audio]

So the issue is that CC72 is the release time for the fast-fade-out, which is used for pruning. So we need independent control for both both fast-fade-out and for release.

Would it make sense to use the current response-curve, which is chosen for velocity response, also for the attack/release curve?

[David Battino]

I’m not sure I understand. Could you write a rule that voice-stealing uses the near-instant release and normal note-off uses the adjustable release envelope? The curve shape controls would affect the adjustable envelopes. 

[WVR Audio]

Sorry,  maybe the confusion is that the near-instant release also needs to be adjustable ... this allows users with certain kinds of sounds to avoid pops, by making the near-instant a little less instant. We are using CC72 to be able to adjust this currently, using CC72 currently we can adjust the number of milliseconds that this near-instant release uses.

Maybe the best idea is to use CC72 and CC73 for VCA-style Attack and Release, as they are intended to control a VCA according to convention, and instead use CC75 (generic) to control the near-instant release times.

[David Battino]

That makes sense to me, though I don’t see why people would need to adjust the near-instant release. That would be used only during voice-stealing, right?

[WVR Audio]

It's used for note-off (halt) and voice stealing, the reason to modifying it is that you want it as fast as possible (about 1ms) for most samples, but slower for some unusual samples which have a mysterious tendency to cause pops.

Perhaps I should move it to the WEB UI so it can be sample-specific rather then midi controlled.

[Philip Meckseper]

Hey man,

really appreciate that you are looking into natively implementing this into WVR. I think that will open it up to a lot of new use cases.

That being said:

1. I would not worry about specific CC numbers. If there even is a standard for envelope somewhere in General MIDI (you said so, but i never encountered it before), nobody in the synth world adheres to that, really. So you can really pick whatever works in the WVR context. If it's not too much work, maybe add the option to remap to a different CC in the WVR web UI? Would be the most convenient.

2. Adjusting the linearity of the curves might be a nice feature but imho overkill. Only very, very few of the conventional synths or sampler will let you adjust that curve. They really all only allow access to the times, not the shape of the curve. It should be somewhat logarithmic though.

3. Yes, if a sound has to be cut off for voice stealing to make room for a newer note, the fast ("instant") release should be used. Depending on the range of that, it could also be a "minimal" release time of lets say 1-2ms. In case the "instant" release time is set >10ms. So the voice stealing doesn't introduce latency for the new note onset.

--
You received this message because you are subscribed to a topic in the Google Groups "WVR Audio" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/wvr-audio/iaWbwi2Jmdo/unsubscribe.
To unsubscribe from this group and all its topics, send an email to wvr-audio+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/wvr-audio/242ef7be-91d9-4902-a23d-e3fa9072124an%40googlegroups.com.

[David Battino]

Thanks for jumping back in, Philip!

I agree with your three points. To add on:

1. Page 16 of the MIDI 1.0 spec (from 1996!) does list CCs 72 and 73 for release and attack. It explains, "These controllers are intended to adjust the attack and release times of a sound relative to its pre-
   programmed values." As you noted, they're not widely known, though the SparkFun Tsunami board, which I used before WVR, does use 72 for release. So, I thought it couldn't hurt to go with the standard.
   That said, a MIDI learn or manual assignment feature in the WVR app would make it easy for people to use whatever CCs they prefer. (Maybe manual assignment at first, MIDI learn in the future.)
2. I'd say "sweet" rather than "overkill" on a curve shape feature. I'd be happy with a fixed log shape; just wishlisting since we were talking about it. ;-)
3. Yep. I can't imagine why the release segment on a stolen voice would be any longer than needed to prevent a click, since longer fades would delay the onset of the new note.

Andrew, thanks so much for considering these suggestions.

[WVR Audio]

I created a GitHub issue for the feature here.
Feel free to chime in with any input!

I will probably have time to start next week.
Thanks y'all

[WVR Audio]

Looking at this a bit today. Took a shot at it but failed so far. Rethinking it, and maybe I'll take another crack soon.