[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Tue, 29 Nov 2005 11:05:28 -0800
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
