Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: su loka 10 1999 - 17:38:16 EDT
On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
> ... the one i was waiting for ... :)
>
> >Why would a plug-in want to change it's input setup in a way that
> >affects other parts of the net? That's the same thing as changing
> >the net, and I *don't* think plug-ins should do that directly.
>
> what is "directly" ? what else do they do, submit a request event to
> the engine ? all this does is to delay the connection change till the
> end of the cycle/beginning of the next. this introduces a potentially
> rather complex event type ... why not let the plugin make the relevant
> call itself ?
Nonono, that's not what I meant! :-) Yes, a plug-in *could* (just as
any other node on the MCS net) talk some to the engine, and even ask
it to build a little private sub net or whatever (oops... the
permission control system needs to step in here), but a normal
plug-in would not even *know about* such operations. It just recieves
evenst and data, and sends events and data - in the normal case using
only a set of audio ports, one input event port, and one output event
port.
> given your predeliction for speed, think about the cache benefits of
> letting a plugin, which has just received a message about a desired
> reconnection from somewhere, and may well have touched some or all of
> the relevant data in understanding it, go ahead and make the
> reconnection itself while the stuff is still around in a cache line.
>
> :)
What about letting the engine handle the events it recieved on it's
own port, and leave all plug-ins affected by net modification
requests alone...?
> >What I want is the ability to build a standard GUI using the
> >information the plug-in provides, if we for some reason don't want to
> >use the custom one, or if there *is* no custom GUI. That does not
> >imply that the events themselves are typed in some way; requiring all
> >events to be floats 0.0 .. 1.0 would do. If you don't want that,
> >*real* event type can be used. Perhaps that's the way to go? Or do we
> >need integers, and perhaps some other types as well?
>
> ah! you didn't say this *at all*.
No, I was probably too lost in the low level details... *hehe*
> that makes all the difference in the
> world. my entire thinking has been that plugins are responsible for
> their own GUI. a note, however, if we do end up going down this
> pathway: most quasimodo modules, for example, typically have 4-10x more
> internal parameters than they actually display as sockets, knobs,
> etc. for MSC, each of those parameters might be specified as having an
> associated event port, but that doesn't mean that any of them should
> show up in the GUI.
So, describe them as "Advanced", "Hidden", or even "Private"...
> so you're going to need a "visible" tag associated
> with each port to indicate if it appear in the GUI.
Yep, or perhaps something more flexible, as described above.
> as for the "all floats" idea. this can work - its what quasimodo does
> for example
So does VST.
(VST events are a different, though; they're a dirty MIDI support
hack for soft synths, and some kinds of events actually carry raw
MIDI data! *aaargh!* What a cludge... Isn't one switch() for *all*
events fun enough? ;-)
> - but there is a problem if a plugin needs string
> values (say, for a soundfile name).
Yep. That's why I suggested types. And variable size events...
> i did a strange and somewhat
> beautiful hack in quasimodo, in which all such arguments are encoded
> as IEEE 32 bit NaN values. There are 22-23 spare bits in a NaN for
> indexing into a global string array ....
>
> but it *is* a hack, and so we probably want to allow passing of
> strings or other sized data as well as numeric data. note also the
> fierce arguments on the Csound mailing list about the preferability of
> double over float ...
Agreed. Just not more types than necessary, and well defined
casting/conversion rules are needed, so we don't end up with plug-ins
that are incompatible for no logical reason.
> >> If, on the other hand, a port comes with a more specific type, say
> >> "Audio level above XXdB" or "MIDI controller 32", then we need know
> >> very little about a plugin to use it - the plugin will be able to
> >> establish its own connections based on its current state ("Oh, the GUI
> >> wants me to start monitoring audio levels above XXdB. OK, I'd better
> >> establish a connection to ...")
> >
> >A connection to... what? That's the problem here.
>
> as my example showed:
>
> engine_connect (engine_get_port ("Audio Level above XXdb"),
> plugin->some_port);
Yes... But that means the plug-in is (indirectly) responsible for
looking up the port. And that, in turn, means that - unless the event
that causes the plug-in to connect contains full information on what
to connect to - you end up with a system where you can't connect to
outputs of other plug-ins in any obvious way. How to address the
output of another plug-in? And what about event address remapping?
(As I assume the normal plug-in has only one input port and one output
port.)
This is standard translation code that would *have* to be in *every*
plug-in that cares about getting connected via the event system. I
see no valid reason not to make it a part of the engine instead. What
would you be able to do, that can't be done if the engine does the
connecting and mapping?
//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