Subject: Re: [linux-audio-dev] Re: Plug-in API progress?
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: ke syys 22 1999 - 10:44:54 EDT
David writes:
>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?
Because, like the new VST GUI, Quasimodo provides its own GUI language
that the plugins use to specify their interface. This currently
provides for about a dozen or so visual elements along with way to
position them and control their ranges/values etc. However, I'm
working right now, for example, on a dynamics module which does
compression/expansion/limiting in a single unit (since they're really
all the same thing). There is no way to do this without writing the
whole widget in the native UI language (e.g. Gtk-- or Python), because
the internal UI stuff is just too limited to handle it. The end result
is a new UI element that can be used by other modules - it will be
some kind of customized curve-drawing widget with range controls,
etc. The same applies to my rather funky (and I think very cool :)
envelope UI element which started out as a necessary item for the
sampling oscillator module, and is now part of the UI element suite.
So no, there is no fundamental limitation, more just a trade-off
between always writing new visual elements in the native UI form, or
using a more limited subset. its pretty much like VST in that regard.
The existing subset could get to look pretty nice, if and when someone
(me, someone else) has the time to spend a week or so futzing with the
GIMP to get it that way.
[ ... VST ... ]
>2) Native GUI built into the plug-in. (100% Platform dependent...)
How does this work ? What is handling GUI event callbacks ? Is the
plugin a separate thread or task ? Or is it all running as part of the
engine ?
>Two problems: Synchronization of the GUI and processing code, and
>network transparency.
Network transparency is an illusory goal (for audio) in my
opinion. However, even if you want to pursue a more limited form of
it, note that by using X and simply forcing the plugin's cycles to run
on the same host as the engine, you do have a certain polarity of
network transparency.
As for the sync problem - I don't believe there is a sync
problem. This is precisely what Quasimodo does now: the UI runs
in a different thread than the DSP emulation, and it fiddles randomnly
with the data used by the DSP; there is *no* synchronization between
them at all. I have had no problems with this, and I cannot find a
theoretical reason why there should be, because of the atomicity of
the instructions to store and load floats and integers (which is what
a parameter change fundamentally reduces to). So I think this is a
non-issue too. The only sense in which I worry about this is if
Quasimodo was ever ported to run on an on-card DSP, access to the
parameter memory might not be so straightforward. But with the new AMD
Athlon/K7 out in a month or two, on-card DSP's are not looking very
attractive any more :)
> 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 kin d 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".
yes, this is certainly a nice feature, but I am afraid that its too
slow. if changing the values of a parameter involves any more than
just a fairly low-cost function call (and particularly if it involves
a context switch between the UI thread and the engine thread), I have
some real concerns (based on experiences with Quasimodo) that you
can't do it fast enough.
Particularly not if you hook up the UI to an external controller/fader
box, which I do all the time. I *sometimes* end up with a full MIDI
wire (8 MIDI faders all ramped to zero and then back up again to a
7bit value). This can translate into about 1 thousand parameter
changes per second, and this is supposed to be handled asynchronously
with the engine.
You're not going to be able to handle this by making an IPC call from
the UI thread to the engine, and if its checking for parameter changes
a thousand times a second in some shared memory queue, its going to be
wasting a lot of cycles that would otherwise be used for DSP. I don't
understand what kind of event system other than some kind of IPC that
you might be envisaging ....
I am currently investigating the XRecord extension for automation of
Quasimodo. I don't see any need to reinvent the wheel here -
automation of X interfaces is something that has been worked on for 10
years or so. The X model is fairly nice because the server will buffer
your events for you until you are ready to handle them, to a
point. So, you can go through a huge burst of UI changes, and then
pick up the event stream for automation recording once things calm
down.
>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.
Well, I think you should start by handing the plugin a connection to
the X server and leave it at that. Any native GUI API worth anything
can take such a connection and get started from there.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:12 EST