Subject: Re: [linux-audio-dev] plugin questions
From: David Olofson (audiality_AT_swipnet.se)
Date: su loka 10 1999 - 15:38:13 EDT
On Sun, 10 Oct 1999, Paul Barton-Davis wrote:
[...]
> in your scheme, when a plugin changes it mind (and the example above
> is a *very* likely one in my experience), you have to broadcast the
> change to everyone who might care, which actually means everyone.
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.
A plug-in could just publish a list of inputs that it *might* use,
just as a mixer would publish it's audio input channels - despite the
fact that they can be muted. Why add another level of routing to the
event system?
[...]
> there is a big difference between port connections that are driven
> by a user metaphorically (or literally, I don't know :) dragging a
> patch cord from one place to another, and those that happen
> because the user presses a button on a plugin GUI which says
> "Controller ID".
Yes, but that's only on the GUI level, IMO.
> in the latter case, when the plugin does its stuff to respond to a
> message from the GUI ("multiway switch XXX now has value 64"), it
> doesn't don't connect to anything as the *source*. it connects to
> another port as the *destination*. thats a key difference that ensures
> the connections "matter".
As I said, I think connecting belongs in the engine...
> in the former case (user dragging patch cords): when you're dealing
> with typed events, which we're proposing, you (the user) can only
> connect meaningfully two ports of the same type. if you connect an
> audio port to an audio port, you're guaranteed that the destination
> will care.
No. The input could be muted. :-)
> but if you connect an audio port to a MIDI port, you can be
> certain that you'll be ignored, if you can do it all.
Well, that's a bit outside the scope... There are event ports and
audio ports. Period.
> so think about this a little bit more: what are the different event
> types ? if you have only a few of them, then you'll be asking plugins
> to process all kinds of events that they *just don't care about*. if
> you have a lot, and you enforce type equivalency when connecting, you
> know you'll be paid attention to.
Actually, type is one thing, *address* (ie CC numbers) is another.
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?
Anyway, the address thing... Two dimensions. A plug-in handles a
number of different event "addresses". (Each one of a specific type,
if we have more than one type.) Plug-ins may also send events on a few
"addresses". Now, there are 3 places where the events can be remapped:
1) In the sending plug-in.
2) In the engine.
3) In the recieving plug-in.
My suggestion is that this is handled in the same domain where the
connecting of event ports is handled; that is, in the engine, as I
see it for the moment...
> >Don't you want to know what MIDI events a synth supports?
>
> Well, yes and no. If the synth comes with a MIDI IN port, and I connect
> some MIDI OUT port to it, then in order to use it effectively, I need
> to know which MIDI events make a difference.
>
> But if the synth has a button which says "MIDI Controller ID" and
> controls, say, the controller that sets pitch bend, then I don't care
> to know anymore: when I press the button, the plugin will do the right
> thing.
>
> So again, it comes back to event types. If ports can only be
> distinguished on the basis of being Audio or MIDI, then somebody will
> have to tell us which MIDI events the plugin will use if we are to
> usefully use a MIDI connection.
>
> 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.
[...]
> The MIDIPort objects have no idea who is
> listening to them, they just do their stuff, and when it matters, the
> right objects get to hear about it.
Ok... Looks like the most significant difference here is how someone
gets the idea to listen to a port. You want the plug-in to establish
a connection when someone wants it to, while I want the engine to do
that. The rest is little more than info details for the GUI.
//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