Subject: Re: [linux-audio-dev] plugin questions
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka 10 1999 - 10:32:50 EDT
[ ... 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.
[ .. buffer size stuff .. ]
OK, understood.
>> >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.
>
>The only difference is that my plug-ins actually tell you during
>init what events they care about.
and later:
>> so, plugins don't need to publish parameters, or their
>> characteristics. they just subscribe to available ports, which the
>> engine must make available.
>
>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". 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.
there is simply no reason to publish any of the characteristics of the
plugin. this is completely private to it. if a plugin wants to use
MIDI CC 34 to control one of its internal parameters, then thats
fine. we don't care. 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.
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 ?
--p
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST