Page 1 of 1

[LV2] More fixes. More plugins fixed

Posted: Mon Nov 18, 2019 2:02 am
by Tim E. Real
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.

Re: [LV2] More fixes. More plugins fixed

Posted: Mon Nov 18, 2019 4:54 am
by kybos
Thanks for the fixes, will test when I am at home.

Re: [LV2] More fixes. More plugins fixed

Posted: Mon Nov 18, 2019 8:08 am
by Tim E. Real
A word about Helm and possibly similar plugins:
It handles a fixed song tempo well. But it does not handle tempo changes in the song well.
You'll notice that the step sequencer becomes out of sync.
I have deduced, I think, that it uses the current frame and tempo to determine what bar and beat it is at.
But that is the wrong bar and beat because it fails to take into account that the tempo
may have changed before it arrived at that frame!

Meanwhile, on a different brand of plugin, TAL NoiseMak3r's modulator keeps
absolutely amazing sync no matter what I throw at it!
I believe it uses the actual bar and beat we supply, as well as the tempo, and possibly (but maybe not) the frame.

Same results in QTractor.

Oh well, that's the way the cookie crumbles folks.
Cheers.

Re: [LV2] More fixes. More plugins fixed

Posted: Wed Nov 20, 2019 8:08 pm
by kybos
Tested.
Now there is sound for both synths.
Thanks.

Re: [LV2] More fixes. More plugins fixed

Posted: Wed Nov 20, 2019 8:12 pm
by Tim E. Real
I have asked the Helm team for clarification on the matter of sync, on their issues page.

Re: [LV2] More fixes. More plugins fixed

Posted: Mon Nov 25, 2019 12:54 am
by sjaehn
I'm not sure if I understood the problem in the right way. But take in account, absolute simultaneity doesn't exist. And I'm not talking about Einstein.

Internal clocks in hosts, plugins or external devices may run differently. If they run with constant speed (and constant bpm) it should be (more or less) easy to synchronize them.

Problems arise if you change the speed. The change of speed is not necessarily immediately communicated by the host via timePosition events. And also not for all data blocks. (Maybe MusE is better?) Therefore, the plugins internal clock needs to make a hard (or soft) jump to synchronize with the hosts clock once time/position is notified by the host. These hard jumps may result in unwanted effects. I experienced it painfully. And for continuous changes in host speed you will get a lot of these jumps in the plugin.

This is also the reason why I removed the continuous host synchronization in B.SEQuenzr.