[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: "Koen Tanghe" <koen@xxxxxxxxxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Tue, 29 Nov 2005 18:45:42 +0100
On Monday, November 28, 2005 6:21 PM [GMT+1=CET],
thockin@xxxxxxxxxx <xxxthockin@xxxxxxxxxxxxx> wrote:
In the first case, I was just wondering: what do we do with a "start
new note" event (= control data packet)? Does that terminate in a
parameter too? There is no fixed number of notes, so how can the
plugin then export its list of parameters to the host, as required
by the spec? Or do we use the polyphony limit and just export all
possible parameters (might be a bit much sometimes I guess)?
If it's not terminating in a parameter, then what is it?
Just as a straw man alternative to the midi-style proposal from Chris:
MIDI note-on messages have a few bits of info, right? Initial
velocity, Initial pitch, and "start now".
What if:
* You have a single per-voice control port called "Velocity"
* You have a single per-voice control port called "Pitch"
* You have a single per-voice control port called "Voice"
* To turn a note on, you allocate a voice ID (not sure how) - call it
v0. Send an event to the "Velocity" port (timestamp t0) for v0, send
an event to the "Pitch" port (timestamp t0 also) for v0, and send an
event to the "Voice" port (timestamp t0) telling the plugin to turn
v0 on.
This decoupling of init-time parameters means that a plugin can have
as many or as few init parameters as it wants.
I agree that that is soemthing to aim for.
<snip>
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.
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.
Also, for each started note, we would like to influence that note
while it's being played, right? We even want to do that on a note
per note basis, even if there are several notes with the exact same
pitch (3 C4 notes, all separately controllable in pitch bend for
example)..
voice IDs != MIDI note #.
Sure! I know that, and that's what I hinted at: it will be possible to play
three notes all having a C4 pitch, but with different bend, vibrato etc...
properties. Wasn't clear apparently.
Let's say we have a very simple synth that starts playing a tone
when it receives a "start note" event and stops playback of a note
when it receives a "stop note" event. Let's also say that each note
being played can be controlled in pitch, volume, vibrato and
brightness (controlled by transmitting the appropriate event). That
makes 6 types of events (control data) per note.
yes, but you only need 1 port for each control - you can bundle a
voice ID in with your event for per-voice events.
Let's also say that the plugin has a polyphony limit of 64
simultaneous notes.
A few questions I aks myself:
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?
Now, from Jeff's reply:
Let's also say that the plugin has a polyphony limit of 64
simultaneous notes.
A few questions I aks myself:
Does the plugin have 64*6 = 256 parameters?
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.
Which is not the same anymore as saying: "parameter" is just an alias for
"control input", as their numbers are different...
In Tim's case:
plugin->getNumberOfControlInputs() = 6
and there simply is no getNumberOfParameters() function, because control
inputs = parameters.
In Jeff's case:
plugin->getNumberOfParameters() = 256
plugin->getNumberOfControlInputs() = 6
Am I getting this correctly?
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?
Or can a parameter change be done without going through a control
port using GMI events?
Do you mean internal to a plugin or between plugins?
Talking about "internal to plugins": does this imply that "automatic
parameter changes" (like morphing or random changes) are done by the
plugin (proxy?) sending GMPI events to itself? Or do we allow
short-circuits for these things (I would think not)?
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.
Koen
----------------------------------------------------------------------
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:
