[gmpi] Re: MIDI: Proposed Reqs (try #2)
- From: Mike Berry <mberry@xxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Wed, 07 Jul 2004 14:57:11 -0600
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: //www.freelists.org/archives/gmpi
Email gmpi-request@xxxxxxxxxxxxx w/ subject "unsubscribe" to unsubscribe
Other related posts:
