Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: David Olofson (audiality_AT_swipnet.se)
Date: ke syys 22 1999 - 02:52:41 EDT
On Wed, 22 Sep 1999, Paul Barton-Davis wrote:
[...]
> In writing Quasimodo, I struggled with the same problems of separating
> the "guts" of a plugin (called a module in Q) from its visual
> interface (if indeed there is one). Its a very difficult problem. On
> the one hand, I am a little remorseful that its hard to make Q modules
> as attractive as some of the TDM plugins for protools or the VST ones
> floating around. On the other hand, the code separation that Q
Why do you get GUI limitations here? Related to the separation?
> I don't know enough about the internals of VST or the TDM plugin
> schemes to understand who or what is generating the GUI and responding
> to its manipulation, but given that it will be rare for anyone to say
> "give me a 250msec stereo delay" - they will more likely say "give me
> a delay and let me play with the timing" - defining a control method
> for the parameters of each plugin is not a side-issue, its critical.
I don't know the details about TDM, but VST 2.0 uses 3 different methods.
1) The simple host UI: Parameter names, values and unit are strings that the
host can request and display any way it prefers.
2) Native GUI built into the plug-in. (100% Platform dependent...)
3) The new VST GUI; a "powerful" cross platform toolkit. Used for building GUIs
within the plug-in, but platform independent as opposed to 2).
In short, I don't like it, as it doesn't support any real form of GUI
separation whatsoever.
> Just to float an idea: instead of having the GUI run by anything
> related to the engine, put the parameters in shared memory (*). Then
> the plugin becomes a standalone application which does 2 things. First
> of all, it contacts the engine to request insertion of the "guts" of
> the plugin. Then it runs a (possibly multithreaded) GUI to allow
> manipulation and possibly display of the parameters and other data,
> accessed via shared memory. Benno will love this idea, I'm sure :)
>
> You could choose whether or not termination of the GUI would trigger
> removal of the "guts" of the plugin.
Two problems: Synchronization of the GUI and processing code, and network
transparency. But other than that, it does give plug-in developers full control
over their plug-in <-> GUI communication. What I *don't* like is that this kind
of solution results in plug-ins needing dual interfaces (at least) - one for
the GUI and one for automation.
With an event based system, you get automation virtually for free. Many
plug-ins won't even need to use custom events for their processing <-> GUI
communications, which means they can just send their "parameter change" events
and let the engine record the communication if desired. Custom events could be
split into two groups - "automation enabled" and "private".
As the event interface needs to be very flexible, efficient and well thought out
anyway, I don't see much reason not to use it for this as well... And it does
solve sync problems and allows true network transparency as well. And it makes
it possible for applications to host plug-ins while leaving most of the event
processing work (automation, routing, distributed processing...) to a central
system engine. (I want applications to run as clients - not hosts - in the
normal case, but I don't want that to be the only way to do it, as is the case
with most similar solutions - dedicated DSP systems included.)
What you'd need for a UI module (library, task, whatever...) is 1) a connection
to the event system and 2) any UI you like (X, console, serial port, MIDI
port...) You may then hack away pretty much any way you like, but of course, a
more civilized approach is probably desirable for the average
VST/TDM/DirectX/... GUI style plug-in.
We could propose a GUI API to use for this, but 1) that would have to be
implemented on all platforms we want to support, 2) it has to be powerful to
gain any acceptance among serious developers and 3) there are already lots of
"standard" toolkits... GTK+ is nice, but I would prefer something like
wxWindows for portability reasons. But no matter what, it's probably close to
impossible not ending up where VST is; forcing developers to either accept the
limited VST GUI, or hack platform specific GUI code if they need more control.
//David
·A·U·D·I·A·L·I·T·Y· P r o f e s s i o n a l L i n u x A u d i o
- - ------------------------------------------------------------- - -
·Rock Solid David Olofson:
·Low Latency www.angelfire.com/or/audiality ·Audio Hacker
·Plug-Ins audiality_AT_swipnet.se ·Linux Advocate
·Open Source ·Singer/Composer
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST