On Sat, Jun 12, 2010 at 10:08:59PM -0500, Gabriel M. Beddingfield wrote:
> However, I don't see many options for redefining how
There's nothing subversive about it.
Normally it is assumed that control ports correspond to
user parameters, and that a host can use their values
for save/restore and for automation.
If the host provides the GUI this is reasonable - one
can't expect much more 'intelligence' from a host than
what is required to support such a simple correspondence
(which already requires the host to be aware of things
such as non-linear mappings, enumerations, illegal value
If the plugin provides its own GUI this assumption need
not be true - the interface between the DSP code and the
GUI could well be one that the host is not required or
even supposed to understand, and the access points
provided to the host (for save/restore and automation)
could very well be quite different. This means that what
the host sees as 'control ports' need not even be provided
by the DSP plugin at all.
In fact, I don't see how something like automation 'touch'
can be provided without race conditions just by letting the
host intercepting the DSP - GUI communication consisting of
get/set messages for control port values. Specific support
is required to do this in any glitch-free way.
I tried to see if/how this works today using Ardour 2.8.9
and the Calf compressor, but didn't get that far: just
using automation 'play' with the plugin GUI open crashes
both Ardour and the external GUI (memory corruption detected
O tu, che porte, correndo si ?
E guerra e morte !
Linux-audio-dev mailing list