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

  • From: Jeff McClintock <jeffmcc@xxxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Fri, 25 Nov 2005 08:49:17 +1300

Hello Koen,

My understanding is this:

plugins have inputs and outputs (I'll call them pins).

there are two mechanisms for delivering/sending data:
1 - audio via buffers
2 - timestamped event

there are two uses for event-driven pins:

1- Parameters. These appear on the User Interface. The equivalent of the knobs on the front of your Mini-Moog. These are saved/restored when you switch patch or save/load a bank of presets.

2- Control Signal pins. These are for sending control signals between Plugins. Imagine you have a external "Filter Amount" socket on the rear of your Mini-Moog. You connect this to other devices (plugins) to modify the sound as part of your performance. This is not stateful.

So, "events" are a delivery mechanism. What do they deliver? "Parameter Updates" and "Control Signal Updates". As far as coding goes, the two types of events should look the same, it's just the purpose that differs.
A plugin can both send and receive events.


"control port" - I believe is simply a pin that accepts Control Signals.

> - parameter changes (either incoming or outgoing) all come through GMPI
> events
> This means that all of the following semantic things:
> a. "start audio sample generation for a new C4 note"

That's the one exception.

Most everyone agrees the host will map MIDI CCs to your plugin's parameters. i.e. your plugin will receive the same event regardless of whether the user moved an on-screen knob, or moved a knob on a external MIDI control surface. This greatly simplifies your plugin code and avoids dependence on any network protocol (MIDI or OSC, or HD-MIDI, it won't matter).

What was *very* contentions, was that I suggested MIDI note data could be treated the same. i.e. upon receipt of a MIDI note on, the host would update my "Note-Pitch" and "Note Velocity" parameters etc, thereby relieving my plugin of that chore (parsing MIDI data).

This is NOT going to happen. Note data will be a special case. It will be a carefully wrapped MIDI event. By carefully-wrapped, I mean the event will retain all semantics of the original MIDI, and be convertible back to raw MIDI.

see..
http://www.gmpi-plugins.org/gmpi/gmpi_common_event_coding_proposal.txt


Usual disclaimer: Apologies if I have misunderstood something.

Best Regards,
Jeff

Koen Tanghe wrote:
Hi,

I'm currently starting to set up some abstract class for a "music-processing
block" for my own internal purposes and I was re-reading the GMPI spec so as
to make sure my stuff will be easily adaptable to the GMPI system when it's
there.


Now, I was wondering if someone could refresh the reasoning behind the
following GMPI concepts: parameters, controls and GMPI events (all of them
are different terms coined in the first final draft proposal:
http://www.gmpi-plugins.org/ ).

In section 1.3 we talk about "audio" and "controls" as possible types of
inputs and outputs.
Then, in section 3.8 we talk about GMPI "events", but only in terms of
"event delivery to a plugin", no event delivery *out* of a plugin.
Then, in section 3.11 we talk about "parameters" and say that plugins expose
their parameters to the host and that parameters are automatable (thus
directly modifiable by the host).
Finally, in section 3.12, we briefly talk about "control" input AND output.


Now, do I remember correctly that:
- GMPI events and controls are one and the same?
- parameters can only be changed through GMPI events/controls?
So, essentially, that:
- a GMPI plugin can only have two types of inputs and outputs: audio and
events (= controls)?
- parameter changes (either incoming or outgoing) all come through GMPI
events (= controls)?
This means that all of the following semantic things:
a. "start audio sample generation for a new C4 note"
b. "signal a snare drum event detection at time offset xyz"
c. "change the cutoff frequency of the filter to 200 Hz"
must come in to (a and c), respectively out off (b) the plugin using GMPI
events through a control port (aarghh, another term...)?
Or can a parameter change be done without going through a control port using
GMI events?


           +-----------+
audio   --->+  GMPI     +-----> audio
           !  plugin   !
control --->+           +-----> control
           +-----------+

And parameters don't come into this picture (except indirectly through the
control ports?

Just need some reassurance here, and it might also keep us fresh ;-)

Koen

PS
There's also the "clock/time related" input and output, but this will probably be handled through special controller messages, but I could be wrong, and for this post it doesn't matter really...



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





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