Re: [linux-audio-dev] Plugin APIs (again)

But why does it have to be that each Channel (using your terms until we find better ones) is a single I/O? It seems like that is a lot of meta-data and indirection to just get a single mono port. You mention further down about having a Bay for "Left Audio" and "Right Audio". There is an implicit 1-1 mapping there that is not explicity defined anywhere and is pointless. If you want them bonded, make the Bay be a stereo bay. This is how I am thinking of things. I'll use an example of an old and unrelated bit of equipment that I think exemplified my understanding. US Robotics used to make modem chassis' called Total Control. It was a 6U monster with 16 slots in the front and 16 slots in the back joined by a midplane. In the front slots you could put any of the cards they made for Total Control - single modems, 4-port modem cards, 16 port modem cards, ISDN cards, and later even HDLC, I think. In the back part of each of these cards you connected it's I/O card. Not every card had I/O mind you. I forget all the options, but anyway. You could have 1 POTS, 4 POTS, 16 POTS, 1 T-Span, etc. To make the Chassis useful you added in a Control card which had software running on it to run the chassis. It's I/O was 10/100/1000 ethernet or fibre or Token Ring or whatever. As I see the 'Bay Model' working - it is like this. Each plugin is a Total Control Chassis. First, you have to have a Master, and the master might have some I/O. Then you have a (limited or unlimited) number of slots into which you put Control Channels. Each control Channel could have (or not) an I/O Channel. There are different I/O Channels that the plugin understands (mono, stereo, etc) and different control Channels can be used with different I/O Channels, within limits set by the plugin. You want a Stereo mixer slot, you add a stereo I/O and one of the compatible control channels (simple, 3-band EQ, 7-band EQ, etc). It is somewhat elegant. The only ugly bit is that the Plugin writer needs to define a compatibility matrix somehow. Now, I'll accept your assertion that Channel Control and Voice Control are different Bays. I don't see ANY reason to have I/O be mono. Now that all that is out, I'm still not convinced that splitting my Channel struct { I/O, channel control, voice control } is needed. The 'link feature' is ugly, IMHO :) heh - I did that below :) This is pretty much what GStreamer is doing. I don't like a ton of 'register me' functions. Ideally a simple descriptor for a simple plugin can be static data, and all the plugin does is return a pointer to it, or similar SIMPLE. yeah - I raised it as a joke, but it's not really :) I think that almost every plugin will have a number of 1:1 releationships. Every synth will have {1 Channel Control, 1 Voice Control} associations. An icky way of describing associations, IMHO. Well YOU are the one who wants to add Bays, which forces me to counter with Templates :) I mis-spoke, that's what I meant. Except for I/O Channels which are nothing more than an I/O port described by two separate entities. Good - that's what I thought, too. If we assume MIDI style channels, though (multiple configurations of the same controls), then loading a preset into a channel might be very cool. Right - even voice_on/off can be control(s) Example? A Control Channel is a Channel (your terms :) with Controls as opposed to a channel with Audio I/O. Fine - Audio Port and Control Port. And what lives in a Control Port is an Event Queue. uggh. For the time being let's take what you've been calling a Channel (an instance of what a Bay describes) and call it a Foo. Now, we can agree that a Channel is a set of Foos, probably in different Bays. Totally abstract - a purely relational entity. And this is why Channels should be addressed one-dimensionally :) A host really wants to instantiate Channels, usually. By instantiating a Channel, it gets all the Foos, each in their own Bay, all associated together some how. Channels are addressed linearly, and Channels of the same type are not necessarily grouped together. So why do we need Bays and Foos again, and not just ChannelDescriptors? Simpler is better ... Hmm, I'd been debating whether it was simpler to have the Plugin write to a real EventQueue and have the host detach the Event list and re-attach it where it belongs. It's a simple operation, and it removes the need for a host to conditionally shadow EventQueues. It means a HAIR more work in the host, but less complexity. However, then it needs to ALWAYS read ALL Control-Out ports on a Plugin. I guess a host that wants to can do that itself and just shadow EVERY port. Fine, you're right, probably. Plugins only write Control-Output iff the Control port is connected. Does a Host need to disable_port() on the Control out ports, like it does audio? Or there is a StereoOut bay which has two Audio Ports. I prefer this. Or Channels. It's simple. The terms are already understood and even map onto a well-known paradigm reasonably well. The complexity goes down. It's at least one less object in our model. The ONLY things we lose: * Ability to instantiate an arbitrary number of Audio ports - bad anyway, since plugins will all have fixed or small ranges of allowable values. * Ability to ignore Inputs if you have none - now you need to explicity say '0 inputs' * Ability to later add new Bay types besides the currently known ones. The only thing I see this as a loss on is Audio formats, and truthfully, I don;t care. Simple Channels can be expanded to: struct XAP_ctrl_channel_desc { char *name; char *label; unsigned flags; int n_controls; XAP_control *controls; }; struct XAP_io_channel_desc { char *name; char *label; unsigned flags; int n_ports; XAP_port *ports; }; struct XAP_Descriptor { ... XAP_ctrl_channel_desc *ctrl_channel_descs; XAP_io_channel_desc *io_channel_descs; int **channel_compat; /* if (compat[ctrl][io]) */ ... int (*xap_new_channel)(int ctrl_idx, int io_idx); ... }; Tim