Adds support for the VIBrato command to SampleInstrument

[n1LS]

• adds a 16bit, 64 step sine LUT with fast linear interpolation
• implements the Vibrato SRPUpdater class
• adds the InstrumentCommandVibrato definitions and help text
• vibrato depth is max. 4 semitones (0x00-0x40 is roughly the range for a soft musical vibrato above that it goes more into fx territory)

[maks]

@n1LS given the pico is already cpu limited, have you profiled how much extra work this command causes, especially for worst case of across 4 or more channels simultaneously?

[maks]

its not enough for this to be added to the onscreen help, it needs to be properly documented in both editions of the user manual.

[n1LS]

@n1LS given the pico is already cpu limited, have you profiled how much extra work this command causes, especially for worst case of across 4 or more channels simultaneously?

In VIbrato::Trigger(bool tableTick) there's a few additions, one inlined call to the table interpolation, a mutliplication and a bit shift. The table interpolation costs roughly 20 cycles, so the entire call ends up costing roughly 50 cycles.

Trigger gets called from doKrateUpdate @ 441 Hz and from doTickUpdate depending on the bpm, at 120 bpm roughly 50 times -> 160k cycles per second.

Vibrato::UpdateSRP(struct RUParams &rup) is a branch to exit and a single fixed point multiplication, so around 15 cycles. Called the same as above thats 60k cycles per second.

In total that's 220k cycles/second so roughly 0.18% CPU per voice.

[maks]

@n1LS ok that seems reasonable but what I'd want is actual profiling numbers vs theoretical instruction usage, have a look at the existing timing code and let me know if you need help using it to time this.

[n1LS]

@maks Sure.

This is the typical output.

[PROFILER] Vibrato::Trigger              : avg=   0 us, calls=  505, total=   390 us
[PROFILER] Vibrato::UpdateSRP            : avg=   1 us, calls=  505, total=   788 us
[PROFILER] Vibrato::SetData              : avg=   2 us, calls=    2, total=     4 us

Averaged over 2-3 screens worth of collected data:

Trigger: 0.77597695 µs

@ 441 Hz → 342 µs / 1s
→ 0.0342% CPU load per voice
0.27% for 8 voices

UpdateSRP: 1.63623267 µs

@ 441 Hz → 722 µs / 1s
→ 0.0722% CPU per voice
0.58% for 8 voices

SetData: 2.2375 µs

only gets called on note on, negligible

[maks]

Apart from the code comments, we are still missing user manual documentation for the command.

[maks]

This is likely not going to work well with VIB cmds in tables combined with phrases.

[n1LS]

It doesn't seem to cause any issues when applying a bunch of Vibrato commands from both tables and phrases simultaneously. What issue are you referring to?

[maks]

having reset here is likely to cause issues with cmd usage in a table, so we really want phase reset to be separate and do the phase reset only when a vibrato cmd first starts

[n1LS]

@maks I moved the vibrato reset to Start() so that a vibrato always starts at 0 without any jump in frequency. A second reset might helpful when calling ARP 0000 so that a later arp command cannot start with a jump in the frequency. What are your thoughts on that?