On Wed, 2013-11-06 at 04:33 +0100, Robin Gareus wrote:
Indeed. Don't Do That(TM). Using non-standard types is not so good,
but can be valid. This, however, is not valid. The property value has
no atom header, so the host might look for the type and/or size the
standard guarantees is there, find some float bytes instead, and boom.
Do not send corrupt atoms around!
raw() is very much a "do not use this unless you really very definitely
know exactly what you are doing" function. Perhaps the docs should say
Anyway, jalv.gtk -d is a good indicator of sanity, it should print
something human readable. Practical reasons aside (e.g. working in
separated hosts like Ingen), debugging is a heck of a lot nicer when you
can just look at the data flying around. If it crashes, it's probably
because the atoms are corrupt.
> Anyway even if you make it work, I doubt that you'll have much fun:
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
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.
> Synchronizing even one [audio] thread with the gfx-hardware is not
While this is practically true in most cases, it's not really the right
thinking for what's going on here. Essentially what you have between
the plugin instance and UI is a network. The best you get is
"recentish". So, yeah, hardish sync is inherently not happening.
While messages will work just fine for many kinds of basic
visualization, for hyper accurate scopes that want to go so far as to
sync with graphics hardware, obviously it's not the best approach.
That's why instance-access exists. By all means, use it. I'd actually
like to see somebody use the god damned thing for the intended purpose
for a change :P
(If such performance is not required, though, messages are better,
because working across processes and/or networks is handy. Scopes are a
bit much, but e.g. simple meters should certainly do so)
Linux-audio-dev mailing list