LFO Trigger Source

[cdbeckwith]

More control over how sfz LFOs are triggered. One common implementation would be: "I want to make a global volume LFO/Filter/Vibrato to model Trem/Vibrato Section of vintage electric pianos rhodes/wurli or other synthesizers".

free_running - LFO is independent of triggered MIDI notes, it would be synced to multiple s and voices to the exact same value. Playing and holding an arpeggiated chord would result in all notes having the same exact LFO position.

mono_keyboard - LFO position is reset to 0 for each new MIDI note trigger, it would still be synced to multiple s with the exact same value, new note would override the LFO to the 0 position for current layers playing. Very similar to free_running execpt that the LFO position is reset with each new note.

poly_keyboard - LFO position is unique to each new MIDI note trigger, each has it's own unique LFO values. This is the current sfz performance behavior.

example:

lfo06_pitch=0
lfo06_freq=0
lfo06_pitch_oncc1=1200
lfo06_freq_oncc11=6
lfo06_trigger_source=free_running

[plgDavid]

Currently experimenting with this. Right now I have this working locally:

lfo03_scope=0 //local (one LFO by region as before) defaults are always nice to have as value "0"
lfo03_scope=1 //global and reset only on first note played
lfo03_scope=2 //global but reset each note played
lfo03_scope=3 //global and never reset

Previously I used two opcodes lfo03_global being 0 or 1 then another opcode: lfo03_reset=being 0,1,2 but I thought that was a waste.
There are careful considerations to be made as well
For instance what happens in conjunction with lfo03_delay and lfo03_fade.
More experimentation needed

[cdbeckwith]

In the case of scope=3 with delay and fade, I could see those two parameters not working for that mode. With other VSTi I've seen LFO fade parameter not be applied if the LFO is in global / never reset 'free running' mode. Delay I could see going either way if it delays the application of the modulation, and not delay the LFO's output value.

[plgDavid]

Yeah in never reset its pretty much a given. In my case I do reset the LFo on DSP changes and session start, at least to get some form of deterministic behaviour. However in case 1 and 2, its a bit more complex. Right now fade/delay do what they do upon reset. I guess its up to the user not to use fade and delay when using global LFOs.

[jlearman]

This raises some good questions.

For any opcode that applies the LFO (rather than configures the LFO itself), the opcode's scope should be its normal scope (that is, region, master, etc -- whatever that opcode already supports.) Thus, the rules for LFO opcodes like pitch, filter cutoff frequency, amplitude, etc. should not be affected at all by the global/local mode.

IMHO, fade and delay could be implemented either way: as a fundamental control for the LFO, or as an "application" parameter. It'd be more useful (though less efficient) to implement them as application parameters.

In any case we should document which parameters are fundamental and which are per-application. That could allow, in the future, new opcodes to have different behavior, without breaking any existing sample sets.

For my purposes, the simpler implementation (having these be fundamental) is fine. But note that (at least, I think) it's simpler as a change from the current implementation, but not necessarily easier for a new implementation.

The bottom line here is, we should think through the question of "what is essential to an LFO" vs "what is a parameter for applying an LFO to a function." The nature of this question is pretty easily understood by thinking about how LFOs on vintage synths worked, and simply deciding, for a given parameter, whether it belongs in the LFO section of the panel, or on the (VCO, VCF, VCA) section of the panel. For many, the choice is pretty obvious; for others, it's a bit arbitrary, but let's be clear about the choices we make.

[jlearman]

IMHO a good way forward might be for David to make the initial decisions here, and we just document it, and perhaps consider a way to adjust that in the future without breaking existing samplesets that use David's choices.

It'd be good to get input from a sfizz implementer too.