10 Dec
2002
10 Dec
'02
2:23 a.m.
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 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? :-) 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? 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: 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. 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