Implement Vibrato command

[maks]

The Vibrato SRPUpdater subclass is currently commented out (from LGPT) and never fully implemented but would be useful to have as command.

[LeviathaninWaves]

I'll look into this now if nobody else is, shouldn't be too hard.

I'll start with Sampler and move onto the synths.

[maks]

Go for it @LeviathaninWaves ! 👍

[LeviathaninWaves]

@maks We should probably talk about how far we want to take this vibrato command. At its simplest, we can do a simple triangle wave vibrato strictly for sample instruments. Or we could have multiple vibrato shapes configured per instrument in the instrument editor screen (like in lsdj) and have it available for SID and OPL as well. MIDI instruments depends on using the "Mod wheel" approach which is totally at the mercy of the synth engine that pT is talking to or we can utilize MIDI pitch bend.

Luckily I'm experienced in low level YM2612 and PSG dev, so I can do stuff with OPL and potentially other YM chips in the future. I've never worked with SID but I can give it a try. Am I going to have wiggle room for LUTs in flash memory for the vibrato shapes? I don't want to do this with runtime math functions if at all possible.

[maks]

@LeviathaninWaves Ideally we would want a command that works across all instrument types while keeping it as simple as possible.

My mental model of vibrato is low frequency FM, so at a guess I would expect a sine waveform modulating the frequency of an instrument.

Agree its trickier with MIDI, I guess the generic way would be to follow what was recently done for the LEG and PSL commands being applied to MIDI, even though specific MIDI devices might have their own, eg the SAM2695 module has specific NRPNs to set vibrato but I'd keep that separate to this as they can already be handled with the existing MIDI MCC command support.

Given I think it was intended to be used as command, I dont think we need to add any UI to instrument screens?

Finally with LUTs, we are lucky to have alot of flash space (compared to ram anyways) so I dont think any issue to add LUTs, just need make sure they are marked static const to have the compiler keep them in flash instead of trying to load into ram.

[LeviathaninWaves]

@maks Understood, I've written an FM and PM synth before. With sampler instruments we can use a phase accumulator that is modulated by a sine LUT. With Opal vibrato I think is built into it, so some quick register writes should handle that. SID I need to research but I imagine if it doesn't have its own LFO then frequency writes will do. MIDI will use pitch bend.

[maks]

Just a quick one about sine LUT, this would be generally useful across the entire firmware, so would be good to put it into a header for use everywhere. Note that we already even scarifice some ram to keep a couple of small LUTs for OPAL in ram as they are used by hotpath code (for every generated sample).

@LeviathaninWaves a bit off topic: if you have experience with writing FM synths before I'd be happy for any feedback you'd have on the OPAL implementation, as because it was intended for desktop tracker usage, it may have some things that could be better optimised for the RP2040. I had a go at some basic things like inlining hot path functions, putting the LUTs used in hotpath in ram but I suspect there are even better optimisations that could be done (eg using rp2040s interpolator units) to make the code much more performant.

[n1LS]

As talked about on Discord with @maks, I'll add to this as the issue seems stale.

#1234 adds an implementation of the general vibrato command definition and the implementation for the SampleInstrument.

[clickysteve]

+1ing request for a vibrato command. This would be excellent.