I'm trying to get Zebra global LFOs to sync with Bitwig transport (song position), but I'm having some trouble with the "trigger" function. Basically, it doesn't seem to have any effect. No matter the value: "each bar", 4 bars, 8 bars, the (global) LFOs never restarts when the host play position cross the threshold. Also, when I start/stop/rewind the host it has no effect. The LFO just continues running uninterrupted, ignoring completely Bitwig transport.
Note that the rate of the LFOs does follow the host tempo, it's just that the starting point isn't on a bar, not even on a beat.
Maybe I'm missing something?
I'm running the latest beta (rev 3857), in Bitwig (both the stabe 1.1.11 and the latest beta 1.2.10), under windows 8.
I tried the same test patch in MuLab and in Reaper and it works fine in both (in fact in Reaper the global LFOs are always in sync with the transport, even when trigger is set to "off").
It could be a problem in the DAW, but I have other synths that successfully sync their LFOs to Bitwig transport...
Any idea?
Bitwig and Zebra global LFOs: problem with the trigger function?
-
- KVRist
- 140 posts since 27 Jul, 2015
-
- u-he
- 30242 posts since 8 Aug, 2002 from Berlin
It's been difficult with the so-and-so-many-bars resyncing of global LFOs. I came up with it 12 years ago for reasons I can't fully remember anymore. I think it was meant to be a feature, but it turned out to rather be a source of uncertainty.
I can't really say why it works sometimes and other times it doesn't. Like, in Logic it's a full bar off and as it seems in Bitwig it doesn't work. I guess there are so any so many ways for a host to share timing information with plug-ins, e.g. some wrap back on loops, others count further and what not.
I once wanted to add an automatable trigger or something, but this wouldn't be terribly reliable as well.
So we changed the concept in later plug-ins, but with Zebra and Filterscape we're kind of bound to drag this through for compatibility reasons.
That said, we have it on our todo list, but it hadn't had the priority to make it into this update, mostly because we don't have a good concept to fix it other than maybe a dozen of workarounds for when it doesn't work. I might look into it next week to see if there's anything else that can be done.
I can't really say why it works sometimes and other times it doesn't. Like, in Logic it's a full bar off and as it seems in Bitwig it doesn't work. I guess there are so any so many ways for a host to share timing information with plug-ins, e.g. some wrap back on loops, others count further and what not.
I once wanted to add an automatable trigger or something, but this wouldn't be terribly reliable as well.
So we changed the concept in later plug-ins, but with Zebra and Filterscape we're kind of bound to drag this through for compatibility reasons.
That said, we have it on our todo list, but it hadn't had the priority to make it into this update, mostly because we don't have a good concept to fix it other than maybe a dozen of workarounds for when it doesn't work. I might look into it next week to see if there's anything else that can be done.
-
- KVRist
- Topic Starter
- 140 posts since 27 Jul, 2015
Thanks for the detailed answer!
It's not a big deal, I'll use Bitwig LFOs instead.
I get that backward compatibility can lead to headaches while coding (and designing)! If you don't find a way to make it work, I'll just wait for Zebra3...
It's not a big deal, I'll use Bitwig LFOs instead.
I get that backward compatibility can lead to headaches while coding (and designing)! If you don't find a way to make it work, I'll just wait for Zebra3...