Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: Tim Hockin (thockin_AT_hockin.org)
Date: Tue Dec 10 2002 - 08:17:30 EET
> > a Channel has p Controls and q Ports
>
> Well, a Channel can have p Controls OR p Audio Ports. I would say
> that a Channel can vave p *Slots* - where a slot can be one of:
> Audio Input Slot
> Audio Output Slot
> Control Input
> Control Output
Ok - I see how you've split this out, but why? What is the reasoning for
having channels only containing one type of thing? And besides that, can't
Event Ports be bi-directional?
> Event Ports don't really belong in this picture. They're like a
I later read what you mentioned about get_event_port() and it was nicely
abstracted. Having the plugin pass a cookie to the host to be passed back
on the port was my first thought when I saw that idea. So ignore what I've
said about event ports for the duration of this discussion. The only way a
plugin exposes it's event ports is through some abstracted method.
> Bays are actually a way of grouping channels of the same kind
> together. I initially called them "Channel Kinds", until I realized
> that I had already "invented" the term "Bay" for exactly this thing
> for MAIA.
I'm not conviced Bay has the correct connotation...
> > This is what I was
> > thinking about as I slept (weird dreams...)
>
> You have those too? :-)
With all the discussion on this, and the two of you running much faster than
I can reconcile all the details, yeah. I'm having racing-mind syndrome.
> > Plugin {
> > /* many plugins will have 1 template, but they can have more.
> > * multi-timbral instruments (synth part, drum part, ...) and
> > mixer * slots (mono, stereo, ...) come to mind
> > */
> > n_channel_templates;
> > channel_templates;
>
> This sounds pretty much like my Bays. You have one template for each
> "kind" of channel you want, and then you can have varying numbers of
> channels of each kind?
Yes. The difference is that I don't see why splitting out Controls is
useful. The way I envision a Channel in my mind is a 'Page' of the plugin -
specifically instruments. I didn't see any reason for channels in effects
until mixers were brought into it, and I didn't see any reason for different
controls per channel (even now, I'm not sure - can you convince me
further?). Sometimes giving up a bit of flexibility makes things much
easier.
Each Channel (page) has similar or identical controls - LFO, Filter,
whatever as well as similar or identical voice controls (VELOCITY, PITCH,
BALANCE). Controls are identified by {channel, index} tuples. I don't see
any reason to put voice controls in a separate channel from channel
controls.
> Still a 1D array of channels, that is?
This is a minor issue by comparison :) Whether we make it an unsorted 1D
array, a sorted 1D array, or a multi-dimensional array is really nothing but
a matter of indexing. We can argue this after :)
> I'm thinking about Bays as an array of objects that each has an array
> of Channels - but it doesn't have to be that way physically,
I take back my last comment - if that is what a bay is, it is really just
another way of saying 'channels are grouped with their own kind' and you are
suggesting using it as an index into a 2D array. Instead of {channel,
index} tuples as above, you'd have {Template, Channel, Index} which is
exactly what you've proposed with different words.
> > Eventport {
> > label;
> > name;
> > /* anything else? */
> > }
> Mine look like this:
So do mine - I was suggesting an eventport descriptor, for hints. But since
that can be completely opaque to the host, it doesn't matter.
How does the host know about ports that controller plugins intend for other
plugins? Assuming the arpeggiator, which outputs voice_on (or whatever!)
events - how does it tell the host 'I have a special port which is control
data?
> Well, it just happens that channel + voice control is a very
> practical model for most synths. It's probably not perfect and
> without restrictions, but I think we can do a lot of cool stuff
> before seeing much of these issues.
I also think that we can't accommodate EVERY whim of plugin writers. They
will have to make some adaptations of their perfect model to fit the plugin
architecture. What we are doing RIGHT NOW is trying to minimize it. We
must acknowledge that we can't give them everything they will want, but we
can give them enough to accomplish their goals without asking them to be
too flexible. :)
> 1. Have two control ranges for Event Input Channels.
They don't need to be seperated, really. All the host knows of them is
their descriptors and indices. Now, that said, there isn't any real reason
NOT to split them, either.
> 2. Allow only one range of controls per Event Input Channel,
> and instead, use an extra bay of Voice Control Channels, if
> you want Voice controls. One could mark the Bays with hints
> suggesting that they are closely related.
>
> Now that the strict physical relation between channels and Event
> Ports is eliminated, this doesn't matter at all performance wise, but
> it might make the API a bit cleaner.
I think this is over-normalizing it. Some Channels really want to have
their own i/o ports to make the paradigm more comprehensible.
> > n_inports;
> > n_outports;
> > }
>
> I'd rather think of Bays as being in/out neutral, and use different
> Channel types for input and output. Only one array of Bays needed
> that way.
Why? Why convolute the host and the plugin by splitting them, if they are
naturally one entity. Again with mixer slots. Mono slots have one input
and output to the mixer's bus. Now, I can't think of anything but mixers
for which that really makes any sense. Perhaps a 'string-section physical
model'. You add a 'CELLO_PLAYER' Channel and a 'VIOLIN_PLAYER' Channel. :)
I want to keep this all simple for the simple synths, too. Maybe all
inputs/outputs are on the master and are fixed. You can add banks of
controls and parts by adding Channels, but the number of in/outs is fixed?
I don;t really see why it need be. Maybe both. Master can have in/outs and
channels can have in/outs. The host is responsible for realizing 'I just
added a channel with 2 outputs, I'd better connect them to buffers'. (Of
course this is non-RT behavior in hard RT systems).
Simple synths have all their controls and outputs in a single channel (or
simpler in the master). Drum samplers can have as many channels as they
want, each with 1 output and whatever controls. Mixers can have stereo outs
on the master and any number of mono channels. That seems pretty powerful
and pretty simple, to me.
> Linking Bays WRT Channel count may be useful, though... (If you have
> a mixer, you'd probably want exactly one strip automation control
> input for each stip audio input. :-)
Or just make them together since they are really one logical entity. As an
old database teacher once told me - always be suspicious of mandatory 1-1
relationships.
Basically we're in agreement except on terms and whether a Template/Kind/Bay
is really single-typed or not.
This model is shaping up nicely - I'm so glad to have excellent feedback.
Tim
This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 08:36:57 EET