Subject: Re: [linux-audio-dev] plugin questions
From: Paul Barton-Davis (pbd_AT_Op.Net)
Date: su loka 10 1999 - 17:27:58 EDT
... 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 ?
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 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*. 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 you're going to need a "visible" tag associated
with each port to indicate if it appear in the GUI.
as for the "all floats" idea. this can work - its what quasimodo does
for example - but there is a problem if a plugin needs string
values (say, for a soundfile name). 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 ...
>> 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);
This archive was generated by hypermail 2b28 : pe maalis 10 2000 - 07:27:13 EST