Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: su loka 10 1999 - 12:15:24 EDT
On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> [ ... init() ... ]
>
> >> what do you have in mind ?
> >
> >It should do both. The event system is used instead of the
> >structures or callbacks that many other plug-in APIs use.
>
> sure, but you talk about it being called many times. thats not how i
> think of an "init()" function.
What about all the callbacks that VST plug-ins do to the host?
Anyway, multiple calls would only be needed if the host and the
plug-in really have a problem agreeing on something. That should be
possible to avoid, I think.
For <clients, servers, nodes, whatever...>, it's different. As soon
as you're connected to the client/server (...?) API, it's time to
register with the communication system manager and perhaps look for
some services that you'll use. Or, preferably, you should look up
your services when you need them. That's not a single, two stage init
sequence. There are more details to sort out here...
[...]
> >I don't like that since I don't think connection management belongs
> >in the plug-in code, and I do think that it's a good idea to be able
> >to tell what a plug-in actually cares about. And the characteristics
> >*have* to be published one way or another, or you're forced to use
> >the plug-in's custom GUI for the values to make any sense.
>
> What are you describing is not "telling you what events they care
> about", but "telling us what events they accept".
How? I'm being unclear again, I guess...
> This is (subtly)
> opposite, and i think that your version is a bad design pattern. the
> linkage between a plugin that wants to receive events and another
> source that sends them should be based on the event types of the
> source, not the nature of the destination.
True, but how do you know what you can actually connect without just
being ignored? The info I'm talking about could be placed in a config
file that comes with the plug-in, but I wonder if that's a good
idea...
> there is simply no reason to publish any of the characteristics of the
> plugin.
The engine could still ignore the information (whether in the
plug-in, or in a separate file), but what's the point? User: "Why the
h*ll can I connect this output to that plug-in, when the plug-in
doesn't care anyway?"
> this is completely private to it.
No. Don't you want to know what MIDI events a synth supports?
> if a plugin wants to use
> MIDI CC 34 to control one of its internal parameters, then thats
> fine. we don't care.
MIDI... When I realized that there's no way around the cost involved
with broadcasting events, I dropped that idea. The fact that I see
event ports as quite similar to audio ports may explain why we have
very different views on this. I want the *engine* to control who
listens to what - just as with audio connections. Channels, addresses
and broadcasting belong in bus systems - while plug-ins are parts of
nets...
> other plugins have no business thinking that they
> can directly request a state change in another plugin - they should
> just be communicated how *they* see the world, and hope that everybody
> else agrees with them.
...but that doesn't conflict with a way of saying "I listen to CC
98 and CC 99 - I'll ignore anything else you send, in case you care."
And, a plug-in should certainly not think that it can directly
control *anything* - the events it outputs might well be routed to
the engine's version of "/dev/null". No different from the audio
outputs.
> this is all basic stuff from the design patterns world. its also, BTW,
> the difference between web-based "push" and "pull" technology.
>
> can you give an example that illustrates why it should be different ?
I think we're too much out of sync for me to give a sensible answer
to that question... :-) (Or the answer might be in the above?)
//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:13 EST