Subject: Re: [linux-audio-dev] plugin questions
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka 10 1999 - 00:27:57 EDT
>A while back, I got the idea of adding an init() callback function to
>the plug-in. The intention was that it should eliminate the need for
>a structure with hardcoded info entries, or a set of callbacks. As
>the same API could be used for that, and for the real time event
>system, there would be nothing more than a few event IDs to keep
>track of.
actually, i had always assumed there would be an init() function to
get things set up. but from your later talk about init stuff, its not
clear what you think this function should do.
my model of "init()" would be something that does basic data
initialization on the plugin's own internal data structures. it
doesn't involve the event system at all.
what do you have in mind ?
You didn't talk about a way to query the engine to see what
event_ports can be subscribed to by a plugin. e.g. "is there a MIDI
input port?"
>3) Buffer size requirements and similar things should be handled
> through request/reply sequences. (The host/server requests a
> certain value, and the plug-in/client replies with the
> closest value it supports.) This is probably one of the most
> complex parts to get right...
i don't think we should support this. plugins *must* handle any size
buffer. the buffer size should be controllable by the engine, either
once at startup, or during runtime if there is a good reason to do so.
why would allow them to do otherwise ?
>6) Parameters that do not fit in a standard class will have to
> go into a custom class. The properties of these events must
> be defined during the init sequence. Custom events should be
> *avoided* as far as possible, as they effectively eliminate
> the usefullnes of the event system. (How do you automate
> a parameter that you don't understand?)
i have a feeling that you are thinking of things a little backwards to
the way i am. my model is that the events that get sent to a plugin
don't say "change parameter N to X". They say "something changed to
Y". Its up to the plugin to decide what that means.
take the ubiquitous cases of (1) an onscreen "knob" and (2) MIDI CC
values. what happens in both cases is:
(1) the GUI thread sends and event when te knob is turned. It
says "this control element just changed its value to 0.345".
Any plugin subscribed to that port will get the event, and
can decide what to do with it. it might ignore it. it
might change its own parameter "foobar" to 0.345, or to
0.69, or to 12929209.23. it might post another event. who
knows ? who cares ? (one of my 5yr old daughter's favorite
lines!)
(2) the MIDI case is identical, except that the event is generated
by the MIDI input thread "this control element just
changed its value to 127".
This is modelled, BTW, on the very nice system used by a
gtk_adjustment, and more generally on the purely and sublimely superb
libsigc++.
automation - ah, automation. the first level is not that hard: we just
record the events in some file, and then play them back. this will
work fine for controlling the plugins. the GUI, which will
need to be controlled since we want the on-screen representation to
show us what the automation system is doing, is a lot more
work. whereas the plugins will get exactly the same kinds of messages
they always do, the GUI will be getting a set of messages that it
normally doesn't get at all. normally, it just reads stuff from (for
the sake of argument) the X server connection. but now, it has a whole
new event stream to deal with, and it has to map them back to its own
world of widgets, etc.
still, it can be done, its just harder.
so, plugins don't need to publish parameters, or their
characteristics. they just subscribe to available ports, which the
engine must make available.
another optimization just occured to me. to prevent the engine from
having to traverse the entire list of subscribable ports during each
control cycle, there should be a way (preferably lock free, although i
doubt that it can be done) to push a port that is in the "available
for subscription list" into a "has events pending list". that way, for
the vast majority of control cycles, the list to traverse will be
empty! big win.
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST