> struct XAP_bay_descriptor
> {
> const char *name;
> XAP_channel_type channel_type;
> int min_channels;
> int max_channels;
> /*
> * Maybe some other stuff
> */
> };
>
> If you like, you may have several Bays with Audio Input Channels, for
> example. These would be totally independent WRT min/max channel
> counts, audio format or whatever properties Audio Channels may have.
So let me see if I get the the containership correct:
a Plugin has n Bays
a Bay has m Channels
a Channel has p Controls and q Ports
I know at some point you started thinking of event ports as separate
channels. I am almost convinced that different channel kinds are needed,
but Bays has thrown me. This is what I was thinking about as I slept (weird
dreams...)
Plugin {
/* everything has master controls */
n_master_controls;
master_controls[];
n_master_eventports;
master_eventports[];
/* 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;
/* mixers might start with 0, synths might start with any #, simple
* instruments might start with 1.
*/
n_channels;
n_channels_min;
n_channels_max;
channels[n_channels_min];
}
Eventport {
label;
name;
/* anything else? */
}
ChannelTemplate {
label;
name;
/* could be split to per-channel and per-voice */
n_controls;
controls[];
n_eventports;
eventports[];
n_inports;
n_outports;
}
Channel {
template
...
}
Does this sound like what you're talking about?
> Number of Bays hardcoded or not?
Assuming that we're using different words to get the same idea, no. A Mixer
would start with 0 Channels and (for example) 4 ChannelTemplates
(MONO_STRIP, STEREO_STRIP, MONO_BUS, STEREO_BUS) . The host
would somehow direct the plugin to add a new MONO_STRIP for each incoming
connection and a STEREO_BUS for output. Just as ideas..
You can now have different controls, different numbers of audio in/outs, and
different event ports per Template. And you can instantiate as many
instances of each template as needed via plug->new_channel(template_num).
This model suggests that there are a number of Channels that are de-facto
for the plugin. That could easily be changed to a per-Template min/max
which the host is expected to instantiate.
> Well, why would you ever want to *change* the number of Bays of a
> plugin? Well, consider a plugin that wraps other plugins... If
This is VERY important in my worldview. Assuming the work being done on a
VST hack on wine, a VST wrapper plugin or a LADSPA wrapper plugin makes all
those bits of code available. The VST stuff may be useless in RT, but if I
am composing in the studio (bedroom :) they can sure bring new sounds to the
table.
