[gmpi] Re: channels, resources and other stuff

  • From: Tim Hockin <thockin@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Thu, 9 Oct 2003 19:48:01 -0700

On Fri, Oct 10, 2003 at 04:23:03AM +0200, Marco Ballini wrote:
> > ME: 'Channel' is so overloaded.  What do you really mean?
> 
> I didn't explain very well...sorry. 
> I meant: I know that the word "channel" is used with different meanings;
> did you agree on a definition for it? Also did you agree on way to
> handle poliphony?

We're not defining terms, just gathering clear requirements. :)  Polyphony
is the instrument's problem.  It is completely outside the scope of GMPI,
with the possible exception that we may standardize a way to get/set
polyphony info.

Multi-timbrality is different.  Since it is based purely on MIDI channels,
we will likely examine how to standardize this.  In MY opinion,
multi-timbral instruments should be just like my mixer example:  load two
modules == two channels.

> If I understood well this is quite similar to what I intended, though my
> plugin structure is little more flexible.

I'm interested in your ideas, though they are off-topic for requirements
gathering :)

> The goal of my definition of channels, states and group of parameters is
> to allow multiple voices for a synth, just like multiple...ehm, channels
> (the level controls in an hardware mixer), with the same paradigm.

I think we're saying the same thing, though 'voice' is the wrong word.
Multiple-channels is multi-timbral.  You can have 1000 voices but only one
channel, if you want.

> > > a graph. in that case the host could be a thin layer around a network
> > > plugin)?
> > 
> > GMPI: Nothing stops that from happening.
> 
> This is different from saying that the API is designed with that goal in
> mind. In this last case the API may need "interfaces" to allow plugins
> that are well written from the point of view of usability and features
> they provide.

I challenge you to show me what special API we need to support this.
Firstly, we have no API yet.  Secondly, it is being considered at the very
root of some of outr minds :)  I really believe that when we make the right
decisions wrt. parameters and IO, this ability will come for free.

> > > - Will shared resources be allowed (for example a wave, an envelope, a
> > > song or a graph-configuration shared between many plugins)?
> 
> With "resource" I static (though it may be changed by plugins) that is a
> accessed by a plugin. It's a definition (and an implementation) that can

I don't see that as a particular goal, right now.  It's a pretty low-level
idea, and when implementation time comes, we'll deal.

> > > - Is the distiction between audio data and control data realy needed?
> > 
> > We hadn't argued this tooo much yet.  It's very paradigmatic.  If audio and

> Ok, but in some cases you may want a parameter to be controlled also by
> a stream of data. What I'd really like is to avoid proliferation of

What I'm saying is that if you want to be controlled by a stream of data,
you should declare that.  If you want to be controlled by events, you should
declare that.

> plugins doing the same thing but with different input method. 
> I mean, in LADSPA when you have a plugin with a control and want to make
> the relative parameter to be controlled by a stream of values you have
> to write another plugin (for example sine plugins: sine_faaa 1063,

Ahh.  Modules solves this, too.  Define a module which has an audio-input
and a module which has a control input.  Load whichever one you want.  One
plugin with interchangeable parts.

> In this sense I prefer much more the word "property" (or another one)
> instead of parameter (I don't like to call "parameter" an audio input).

An audio-input would not be a parameter, it would be an input.  Parameters
are event-driven things.

> For the purposes I'm thinking of, it matters.
> Imagine a scenario where you're playing live music and want to add a
> plugin without stopping music (for example in an improvisation
> perfomance).

Oh, yes.  I thought you meant the ability to change a mono reverb into a 5.1
reverb dynamically.  It would be nice, but it's not so important.

-- 
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts:

  1. Home
  2. gmpi
  3. Archive
  4. 10-2003