[gmpi] Re: channels, resources and other stuff

On Thu, Oct 09, 2003 at 06:14:51PM +0200, Marco Ballini wrote:

> I'd like also to understand the exact goals of this API (for example if
> you could add, remove plugins or change connection between them while
> others are running).

To retain all the functionality of all the current plugin APIs, while
adding a healthy dose of sanity, cleaniness, and modernness.

> Here are some questions (forgive me):

I can answer all of these in two ways:  The GMPI answer and my own ideas.

> - How multiple voices are handled in a synth plugin?

GMPI: We're not there yet.  We're gathering requirements.  Do you have a
requirement in this area?

ME: Voices are not really part of the API.  They are internal to the synth.

> - Is there an agreement on what a "channel" is? 

GMPI: We're not there yet.  We're gathering requirements.  Do you have a
requirement in this area?

ME: 'Channel' is so overloaded.  What do you really mean?

> How would you handle a mixer with arbitrary inputs? (I use channels for
> that)

I've envisioned something akin to channels being used for this, too.  I
called them modules.  Each plugin can define N module templates.  Upon
request, it can instantiate those modules.  You can use a module for each
MIDI channel.  You can make a mixer that has mono, stereo, and 5.1 module
types, and load as many of each as you want.  But we're not NEARLY there
yet.

> - Will network plugins be allowed (plugin that contain other plugins in
> a graph. in that case the host could be a thin layer around a network
> plugin)?

GMPI: Nothing stops that from happening.

ME: It should be easy to take the GMPI SDK and make a plugin that is a
GMPI-host.  It should also be easy enough for a host to store a sub-graph of
plugins as a preset and re-load that.  We may decide to formalize such a
subgraph preset as part of GMPI.

> - Will sequencer plugins be allowed (on the same graph level of the
> plugins it controls)?

GMPI: Nothing stops that from happening.

ME: That is the 'right' way to do it.

> - Will shared resources be allowed (for example a wave, an envelope, a
> song or a graph-configuration shared between many plugins)?

I don't understand the question - explain?

> - Will developers have to write many plugins (as in LADSPA) to allow a
> control (example: cut-off, resonance, volume) to be handled both with
> single events or with a stream of values (for example from an audio
> output from another plugin)? Will have the user to destroy and recreate
> the plugin to change the type of connection?

Two questions here.  First control stream vs events.

GMPI: This has not been totally addressed.  Do you have a requirement in
this area?

ME: I don't think audio-rate controls need to be supported.  Generic
controller plugins should be outputting events.  If you want a side-chain in
your plugin, you can code it as such, but it is important to note the
difference between a control stream and a data stream.  It is also possible
to write a side-chain generic controller that takes audio in, and spits out
events.

2nd: Connection changing

GMPI: We're not there yet.  We're gathering requirements.  Do you have a
requirement in this area?

ME: We're not there yet.  I personally think you should be able to change
all that on-the-fly, but it doesn't REALLY matter.

> - Is the distiction between audio data and control data realy needed?
> (I consider audio and control just *hints* for a parameter)
> - How will memory be available to a plugin (a function, an event,
> or...)?

We hadn't argued this tooo much yet.  It's very paradigmatic.  If audio and
control are essentially indistinguishable, you have some advantages and some
disadvantages.  Ditto for the reverse.  I think everyone has tentatively
agreed that event-driven, just-in-time delivery of atomic (and maybe ramped)
control changes is the sanest approach TODAY.


-- 
Notice that as computers are becoming easier and easier to use,
suddenly there's a big market for "Dummies" books.  Cause and effect,
or merely an ironic juxtaposition of unrelated facts?


----------------------------------------------------------------------
Generalized Music Plugin Interface (GMPI) public discussion list
Participation in this list is contingent upon your abiding by the
following rules:  Please stay on topic.  You are responsible for your own
words.  Please respect your fellow subscribers.  Please do not
redistribute anyone else's words without their permission.

Archive: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: