[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Mon, 28 Nov 2005 09:21:24 -0800
On Mon, Nov 28, 2005 at 11:29:05AM +0100, Koen Tanghe wrote:
> >Think of an event as a packet on the control wire.
>
> OK.
> So: "event" = "control data", and it might be coming into or going out of a
> plugin.
That sounds right to me.
> >We weren't clear on this. I see it one of two ways:
> >
> >"Parameters" are the sinks for control data - when you send control
> >data it must terminate at a parameter. For example, the cutoff
> >frequency knob of a filter plugin would be a parameter, as would be
> >the host-to-plugin tempo syncronization of an LFO plugin.
> >
> >"Control inputs" are the sinks for control data. Control streams are
> >made between control outs and control ins. "Parameters" are the
> >user-interactive control inputs. For example, the cutoff frequency
> >knob of a filter plugin would be a parameter, where as the
> >host-to-plugin tempo syncronization of an LFO plugin would not.
> >
> >Of these, I think I prefer the first - "parameter" is just an alias
> >for "control input". What think? I am trying to keep track of these
> >clarifications for the fledgeling specification.
>
> 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. If velocity doesn't make
sense, don't provide it.
Each of these control ports can be hinted as to their MIDI compatibility.
That way, a host can automatically figure out how to turn a legacy MIDI
message into the above sequence. If it found, for example, a synth which
had no "velocity" port, then it would just not send the velocity part of
the MIDI note.
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.
> 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 #.
> 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.
> >>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..
----------------------------------------------------------------------
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:
