[gmpi] Re: MIDI: Proposed Reqs (try #2)



Chris Grigg wrote:

Mike B. said:

Chris Grigg wrote:

3.15. MIDI
...
Req. 69: EXTERNAL MIDI IN & OUT - It must be possible for hosts to control plugs from arbitrary MIDI 1.0 HW instrument controllers, HW control surfaces, and SW outside the GMPI graph (though the in-graph data need not necessarily be in pure MIDI 1.0 format). 


    This req, though I understand it, is a bit convoluted. Can I suggest:

Req. 69: EXTERNAL MIDI IN & OUT - Hosts are not required to support any external control protocol, including MIDI. However, it must be possible to write a host in which users can control plugs from arbitrary MIDI 1.0 HW instrument controllers, HW control surfaces, and SW outside the GMPI graph (though the in-graph data need not necessarily be in pure MIDI 1.0 format). This includes but is not limited to playing notes, adjusting parameters, host-side ad hoc 'click-and-wiggle' controller mappings, and System Exclusive communication. It must also be possible for plugs to communicate to arbitrary external MIDI devices (including other SW outside the GMPI graph) by effectively emitting MIDI 1.0 for the host to route to destinations outside the GMPI graph (though the in-graph data need not necessarily be in pure MIDI 1.0 format). Plugs must not need to use platform native MIDI I/O APIs to achieve this, it must be possible using only the GMPI API.


If the only change you're suggesting is changing " It must be possible for hosts to" to "Hosts are not required to support any external control protocol, including MIDI. However, it must be possible to write a host in which users can", then I see no problem there -- it's what I meant, but much clearer about there being no general req for all hosts to accept MIDI, OSC, etc. 

    Yes, that is the only change that I wanted.



Req. 77: MIDI-PARAMETER MAPPING - Plugs with MIDI-driven parameters (in the sense of section 3.11 Parameters) must be able to expose to the host an arbitrary MIDI-messages-to-parameters map. The map must be changeable at runtime, for example when the parameter set changes.


Why is this req necessary? Can't the plugin do it itself using an actor? The host uses its own remapping, but since the MIDI is stapled to the event, the plugin preprocessor can remap at will, without having to add a new API element to publish parameter maps.


1. This was taken directly from Tim's version and the on-list discussion, there really seemed to be good agreement that maps are desirable.

I'm not against maps. I am just thinking that the actors may provide all of the mapping that we need without a new requirement.

2. I had the impression that an Actor was only needed in cases of self-automation, linked parameters, and clipped parameters...? Whereas you can have MIDI maps without any of those things being true.

An actor is available for any form of pre-processing, which could include a mapping operation.

3. Not sure, but it feels like there are some assumptions in there about what the Actor reports back to the host, i.e. that the host could somehow extract the map from the Actor... if so, can you amplify?

The host could, potentially, use the actor as its map. When it receives MIDI, it translates it to GMPI and sends it to the actor, which then does the map translation. I like this model better than publishing a map and then somehow having the plugin notify that the map is stale. This way, the map always lives inside the plugin.

4. Existence of stapled MIDI is not settled anyway.


Agreed. I am still against it, though I noticed as I was writing my earlier mail that I was making a case FOR it :)

--
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: http://www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe

Other related posts: