[gmpi] Re: Parameters / controls / GMPI event system - refreshment
- From: thockin@xxxxxxxxxx
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 30 Nov 2005 15:57:34 -0800
On Wed, Nov 30, 2005 at 03:25:16PM -0800, Chris Grigg wrote:
> Alternatively, you could keep the noteIdHasDied() callback idea but
> simply make the host responsible for keeping the note IDs it uses
> mutually unique. Then once the host starts using a given note ID, it
> can't be re-used until and unless the plug issues a noteIdHasDied()
> callback for that note ID. Not hard, especially with a host helper
> lib, and it simplifies all the plugs.
This is pretty much what I just said, too - we crossed in air. :)
> Just another take on the same idea... there are lots of ways to do
> these things, and what's best depends on what your goals are.
> Therefore: Requirements first!
Req 89: GMPI must provide a note control mechanism. This must include
at least the ability to turn specific notes on and off. GMPI note control
must provide the ability to turn on the same note number more than once,
and identify exactly which instance of a note an event is intended for.
Req 91: Voice management must be the domain of the instrument. All that
the host sees is a voice ID. Operations on a voice always use the ID.
Req 92: GMPI must provide the ability for an instrument to define an
arbitrary set of parameters that applies to each voice. These parameters
must be able to indicate whether they apply only to the start of a voice
(e.g. velocity), apply continuously to the voice (e.g. aftertouch), apply
only to the end of a voice (e.g. release velocity).
> >That's more or less similar to what is done in VST now when you're using
> >MIDI events to get sample-accurate parameter changes, right? First the host
> >calls your plugs processEvents function during which you receive all MIDI
> >events for the about-to-be-processed audio buffer, and only then the
> >process
> >function is called that actually does the audio processing stuff, taking
> >into account the timestamps and semantics of the parameter changes that are
> >done via the MIDI events (usually CC's).
>
> But my point still holds: you still need to get the order of arrival
> right, because one message may undo the action of another. If the
> order is swapped, the performance is, uhm, inverted or something.
How about these in the spec:
If more than one event for a given control is delivered for a given
timestamp, the behavior is undefined.
All events delivered for a given timestamp must be considered to be
simultaneous. All events for a given timestamp must be processed before
results are generated for that timestamp.
----------------------------------------------------------------------
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:
