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
