[LV2] More fixes. More plugins fixed
Posted: Mon Nov 18, 2019 2:02 am
Thanks to kybos for pointing out a whole range of plugins that were not working correctly, if at all.
All these plugins use the LV2 TimePosition feature.
All have sequencing or stepping or syncing features that use this feature.
Helm, TAL NoiseMak3r, even the lowly LV2 Example Metronome were not well.
Because of differences I observed in plugin behaviour, you will now see some extra buttons on the generic plugin UI:
1: "fixed speed" (fixes NoiseMak3r modulator stuck in small loop at stop mode for ex.),
2: "transport affects latency" (use with self-correcting LV2 Example Metronome for ex.), and
3: "override reported latency" (for plugins with broken, inaccurate, or no latency reporting), and
4: "latency override value" (entry box for overriding the plugin's reported latency).
[ Late edit: ] I really wanted to make 1 and 2 global settings so that they would affect all instances of a plugin (set and forget).
But there wasn't enough time. It's much more complicated to do that. (Need a global plugin quirk editor.)
So the settings are per-plugin-instance for now.
Please bear with me, I'm sorta, kinda, still working out number 2. It works, (used with LV2 Example Metronome for ex.)
but I need to work out the latency reporting to the rest of the app. YMMV.
Also there's a few things that need to evolve or be developed to support frame-accurate transport changes:
Currently we simply insert just one TimePosition atom event, when necessary, at the start of each cycle at frame zero.
To insert more accurate changes at other frames in the cycle, specifically just for LV2, we need to develop a
"sorted atom data list" to replace our RT-friendly sorted MPEventList container right there in the processing routine.
TimePosition atoms are very similar to midi events but not quite. They do not jive with our MPEventList.
Thus we need to replace it with a clever atom sorting list where all atoms go before they are delivered to LV2.
This small section, found in each supported plugin framework module's process routine, is all about ensuring
that events are sorted just before they are delivered to the plugin framework.
See ChangeLog for any further details.
All these plugins use the LV2 TimePosition feature.
All have sequencing or stepping or syncing features that use this feature.
Helm, TAL NoiseMak3r, even the lowly LV2 Example Metronome were not well.
Because of differences I observed in plugin behaviour, you will now see some extra buttons on the generic plugin UI:
1: "fixed speed" (fixes NoiseMak3r modulator stuck in small loop at stop mode for ex.),
2: "transport affects latency" (use with self-correcting LV2 Example Metronome for ex.), and
3: "override reported latency" (for plugins with broken, inaccurate, or no latency reporting), and
4: "latency override value" (entry box for overriding the plugin's reported latency).
[ Late edit: ] I really wanted to make 1 and 2 global settings so that they would affect all instances of a plugin (set and forget).
But there wasn't enough time. It's much more complicated to do that. (Need a global plugin quirk editor.)
So the settings are per-plugin-instance for now.
Please bear with me, I'm sorta, kinda, still working out number 2. It works, (used with LV2 Example Metronome for ex.)
but I need to work out the latency reporting to the rest of the app. YMMV.
Also there's a few things that need to evolve or be developed to support frame-accurate transport changes:
Currently we simply insert just one TimePosition atom event, when necessary, at the start of each cycle at frame zero.
To insert more accurate changes at other frames in the cycle, specifically just for LV2, we need to develop a
"sorted atom data list" to replace our RT-friendly sorted MPEventList container right there in the processing routine.
TimePosition atoms are very similar to midi events but not quite. They do not jive with our MPEventList.
Thus we need to replace it with a clever atom sorting list where all atoms go before they are delivered to LV2.
This small section, found in each supported plugin framework module's process routine, is all about ensuring
that events are sorted just before they are delivered to the plugin framework.
See ChangeLog for any further details.