[gmpi] Re: 3.15 MIDI (goals)

  • From: Mike Berry <mberry@xxxxxxxxx>
  • To: gmpi@xxxxxxxxxxxxx
  • Date: Sun, 20 Jun 2004 17:51:00 -0600



Chris Grigg wrote:

On Sat, Jun 19, 2004 at 05:31:01 -0700, Chris Grigg wrote:

>> Switches? (OT: My Soundcraft Ghost console sends Note Ons when you
>> press the channel mute buttons.)
>
>Mapping a received NoteOn/Off to a switch can be OK, but it makes no sense
>trying to undo a NoteOn that actualy means NoteOn.

Well, Mike and Steve disagree.


I dont disagree - I think mapping a noteon ot swith (in th host) is fine,
and undoable, but the internal state (and users mental model, I think) for
notes and controls is different.

If you play some notes, move some controls, play more notes, press ctrl-z
you dont expect the notes to stop, you just expect the sliders and knobs
to go back to thier last position.

I think Mikes example was of the undo happening in a sequencer - thats
different form host-controled parameter state undo.


Uh... Mike?


The only way that I am really comfortable with MiG is if the plugins are explicit as to what MIDI messages they are receiving. I want to know types, channels, SysEx identifiers, everything. Then I as the host know exactly what incoming MIDI is going to cause a reaction from a plugin, and so I can store the stream as is comes in and play it back to the plugin to restore state.
This means that if one MIDI message is going to affect multiple parameters, then the plugin must use "actors."
I also still think that a large portion of MIDI messages can be transparently translated into GMPI events. So I throw out this strawman, which I am not even convinced of myself yet:


GMPI MIDI data type parameter

This parameter is a MIDI bytes stream. At instantiation, the plugin must enumerate exactly what MIDI messages it wishes to see delivered on this parameter input. It does this by providing a list of byte strings to the host. So to receive manufacturer ID 0x5B SysEx, the plugin would return 0xF05B as a byte string. Then all SysEx packtes with matching starts would be passed to the plugin, and the host could save them as they come in, and send the previous one in an undo situation.


My gut says that this should be limited to SysEx messages. I don't see any other MIDI messages that cannot be translated painlessly. It is an improvement over an opaque blob, because the host can actually extract these from MIDI input. All of the actor rules apply. If the incoming SysEx is going to affect multiple params, that must be handled in the actor.

Thoughts?

--
Mike Berry
Adobe Systems


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

  1. Home
  2. gmpi
  3. Archive
  4. 06-2004