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

Tim Hockin thockin at hockin.org
Mon Dec 9 20:21:01 UTC 2002


> 	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.




More information about the Linux-audio-dev mailing list