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

New Message Reply About this list Date view Thread view Subject view Author view Other groups

Subject: Re: [linux-audio-dev] Plugin APIs (again)
From: Tim Hockin (thockin_AT_hockin.org)
Date: Tue Dec 10 2002 - 03:15:42 EET


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


New Message Reply About this list Date view Thread view Subject view Author view Other groups

This archive was generated by hypermail 2b28 : Tue Dec 10 2002 - 03:21:16 EET