[gmpi] Re: Parameters / controls / GMPI event system - refreshment

On Tue, Nov 29, 2005 at 06:45:42PM +0100, Koen Tanghe wrote:
> >This also means that most events stay fixed sizes.  An alternative
> >would be to make an expandable "note-on" event which started with a
> >'size' field and had some sort of dictionary (param = value) built
> >in.  This means a lot more work for everyone, I think.
> 
> Maybe, but it's more structured. I like the idea of having a basic event to 
> which atributes can be attached.

Yeah, there's something simple and less complicated about using this,
instead of multiple discrete events.  It's a data normalization problem.
The more normalized we get, the more intricate it gets, but the more
flexible it gets.

> But you're right that the multiple control ports idea might be easier to 
> handle. Not sure which one I prefer, but I'm fine with either.

I could be talked into either or even something else.

> >>Does the plugin have 64*6 = 256 parameters?
> >
> >nope, just 6.
> >
> >>Or do other way around, but also using parameterized events: 6
> >>control in ports, one for each type of event?
> >
> >That's the ticket.  At least *I* find it elegant.

> OK...
> So what does the host get when it asks the plugin for its parameters?
> Just 6 parameters, as it seems.
> How will the host know that events sent to these control ports are 
> parameterized with a voice ID?

However you ask the control port for it's metadata will include that info
- a flag or a special control port type or something.  Think of it as a
  flag - it keeps it simple.

> >Effectivly yes.
> >Treating them as 6 'indexable' parameters makes them more manageable
> >is all
> 
> Here I seem to understand:
> there are 256 parameters, but there are only 6 control in ports.

(6*64 != 256, by the way)

If it helps you to think of them as individual controls, that's ok, too.
That's really a matter for internal design.  As far as the API goes, there
are 6 control inputs.

> What I'm aiming at is that the host should be able to build a list of all 
> possible parameter change events that may come out of or go into a certain 
> plugin (as required by the spec part talking about plugins reporting their 
> parameters).
> When using "parameterized" events, will it be able to do that? It implies 
> that the parameterization of each event is also known to the host somehow, 
> right?

In my view the host should be able to get metadata from the plugin that is
detailed enough for it to list something like:

Controls {
        Master {
                Volume: float32 [0.0, 2.0]
                Balance: float32 [-1.0, 1.0]
                Velocity(v): float32 [0.0, 1.0]
                Pan(v): float32 [-1.0, 1.0]
                Cutoff(v): float64 [0.0, 1.0]
        }
        Oscllators {
                Osc1 {
                        Shape: enum [Sine, Saw, Square]
                        Octave: int32 [-2, 2]
                        Phase: float32 [0.0, 1.0]
                }
                Osc2 {
                        Shape: enum [Sine, Saw, Square]
                        Octave: int32 [-2, 2]
                        Phase: float32 [0.0, 1.0]
                }
        }
        Filter {
                Cutoff: float64 [0.0, 1.0]
        }
}

You should be able to get all that and more from metadata.  Arbitrary
grouping and everything you need to know to auto-generate a reasonable UI
for a plugin.  The above ignores multi-channel or multi-module plugins.
It also neglects audio IO.  Those will make it even more detailed.

> >Not perfectly clear, but going thru the host has so many advantages..
> 
> I was talking about the fact that some current plugins have the ability to 
> morph their presets from one set of parameters to another set of 
> parameters. One way to do this is by having something in the plugin's 
> "process" function that updates the parameters so that they morph towards 
> the new preset. The host will never see this (that's why I called it 
> "short-circuit"), if these parameter changes are not reported through 
> events.
> A solution we talked about was that there would be the possibility to have 
> a "proxy" plugin that generates the parameter change events, sends them 
> through the host to the plugin (in a buffer of timestamped events) right 
> before the plugin's process itself is being called. This would also allow a 
> user to record a series of random events for a plugin that has some 
> parameter randomization built-in and thus always get exactly the same sound.
> We then had discussions about overhead for morphs that are smoothed on the 
> sample resolution and ramps etc...
> 
> But from the replies I think I can safely say: ALL parameter changes are 
> done through events on a control wire.
> So this seems clear now.

Right, we definitely need to support spontaneous changes.  We talked about
a possible model, but as the details evolve, it may not be the ONLY model.
I don't want to get married to any proposals until it's time to start
actually doing them.

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