Atom messages
are written into a ringbuffer in the LV2host in the
DSP-thread. This ringbuffer is sent to the UI by another thread
(jalv.gtk and ardour use a g_timeout() usually at 40ms ~ 25fps), and
finally things are drawn in the X11 thread ie. gtk-main or qt's main.
Other LV2 hosts may do do things differently and you have no control
over it.
As much as like LV2 from a user's perspective and host integration. It
kinds sucks for visualizations. The only realistic way do to RT
*visualizations* (e.g. a scope) right is to bypass the host (use
instance access & a semaphore) and use openGL with vblank-sync using a
custom thread in the UI (drobilla is going to blacklist me now).
Why? I have constantly said since day 1 that instance-access is
suitable for visualization use. For plugins that do a bunch of stuff
*and* have visualization, they can simply degrade to not having the
fancy visualization part if it's not available. It's people abusing the
facility to do control that I have a problem with, for very good
reasons.
Using instance-access for visualization is 100% OK (assuming graceful
degradation if the plugin does other things). Using it for control is
grounds for being taken out back and shot.
Well, there is one simple reason why I cannot use instance-access -
Ingen doesn't and won't support it :)
My requirements for this scope are:
- must be compatible with Ingen. I want this scope to be used with
other plugins from the avw.lv2 suit, and Ingen is (as far as I know)
the only host where these plugins are supported (not all hosts support
CV, Carla doesn't) and is usable to create Modular Synths. Therefor, I
cannot use instance-access
- I don't want to rely on outside jack apps I could plug Ingen into.
Although I like the way we can plug everything together with Jack, I
personally don't find it handy (Personal Opionion and Taste Here!!!)
in some situation. When I create a modular synth in Ingen, I don't
want to have to start other apps, connect them, blablabla... So
ll-scope, futur zita-scope, etc I'm not interested in
So DSP to UI Atom Vector is just a "limitation" i'm imposing to
myself, and nothing else.
As far as synchronization goes, I'm not that demanding... My scope
needs to be able to compare two inputs, so as long as they are
received in the same "event" I should be ok. The other case would be
to compare the output from a LFO with what I actually hear, but LFO
are so slow that even a 40ms delay shouldn't be much of an issue.
@Robin: I'll defo have a look at the example you sent though, that
looks like exactly the type of example I was looking for.
Aurélien