[gmpi] Re: 3.15 MIDI (goals)
- From: "gogins@xxxxxxxxxxxx" <gogins@xxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Sun, 20 Jun 2004 10:43:57 -0400
Thanks for the clarification. But wouldn't it then be possible to handle
controllers and blobs purely within GMPI, yet provide a hints to enable
their translation to and from MIDI SYSEX?
Original Message:
-----------------
From: Chris Grigg gmpi-public@xxxxxxxxxxxxxx
Date: Sat, 19 Jun 2004 21:54:48 -0700
To: gmpi@xxxxxxxxxxxxx
Subject: [gmpi] Re: 3.15 MIDI (goals)
Michael G. said:
>I still don't see why (a) controllers and (b) blobs can't be handled in
>GMPI without resort to SYSEX.
They can, so if it was me who left the impression they can't, then I
expressed myself badly. But that doesn't say anything about
situations where for natural reasons you -want- to send sysex to/from
a plug. E.g., I have a Kawai MIDI fader box over in the corner that
has a mode where it sends tailored sysex's for some Kawai synth. If
they ever implement the same instrument as a plug, it'll work with
that... but only if sysex is in some form allowed to pass through
GMPI.
E.g.,
>Blobs are undoable if and only if they
>do not come in unpredictable chunks, but rather, one blob is one message.
>Then you can push the blobs onto an undo stack and undo them like any other
>parameter.
This is placing new restrictions on blobs. It's an attempt to make
blobs -- intentionally opaque to date -- less opaque semantically by
fitting into a 'specific command' model, which seems unwise to me.
Over time, people are likely to invent new things to do with blobs,
things we haven't thought of, and this seems good for GMPI longevity.
Host-as-Panopticon should have limits; you have to leave some escape
hatches.
Whether blobs always need to be undoable seems pretty debatable.
It's one thing for a host to say it will not load plugs that do not
support total undo, it's another thing to say all hosts and all plugs
must implement total undo.
NEW IDEA: Rather than globally attempting to enforce a wholly
unenforceable law outlawing hard-to-undo functionality, which we
acknowledge will not happen no matter what the spec says, why
couldn't we invent a "ImplementsTotalUndo" metadata flag for the plug
packaging? Then plugs that don't implement total undo will be easily
excludable by concerned hosts. What's the downside?
>Why would GMPI need to intersperse blob data with controllers or real-time
>data?
Because the blobs contain pictures of the dark side of the moon for
use as spectrum analyzer input, which is used as a vocoder input, and
that doesn't fit in the non-opaque datatypes? And the controllers
drive the voice filter setting? Maybe you're asking something else.
-- Chris G.
>If necessary, we could even have these different entities handled by
>different threads. But my bet is, the GMPI graph will run so fast that
>large blobs can be handled between audio sample blocks. We're not running
>at 31 kilobaud here... in my view many features of SYSEX were artifacts of
>a rather slow transmission speed.
>
>Original Message:
>-----------------
>From: Tim Hockin thockin@xxxxxxxxxx
>Date: Sat, 19 Jun 2004 18:21:38 -0700
>To: gmpi@xxxxxxxxxxxxx
>Subject: [gmpi] Re: 3.15 MIDI (goals)
>
>
>On Sat, Jun 19, 2004 at 05:35:56PM -0700, Chris Grigg wrote:
>> The assertion on the table is that no GMPI plug in any context will
>> ever be allowed to do any operation that the host could not
>> meaningfully undo by rewinding to an earlier parameter set snapshot.
>
>Yes.
>
>> Currently this is being extended even to the note-on blob, and sysex
>> level. I see problems there.
>
>Agree. I do not see any useful meaning of undoing a NoteOn (unless it
>maps to a parameter, rather than note control). I do not see any reliable
>semantic in undoing SysEx.
>
>This is how I think of undo. After a DO something, does it make sense to
>hit CTRL-Z to undo it?
>
>If I turn a MIDI knob, then hit CTRL-Z, it's pretty clear what should
>happen.
>
>If I hit a key on a MIDI keyboard, then hit CTRL-Z, I have no idea what
>you expect to happen.
>
>If I send a SysEx, then hit CTRL-Z, I mighthave an idea what I think
>should happen, but due to the nature of SysEx, no clue how to make that
>happen.
>
>----------------------------------------------------------------------
>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
>
>
>--------------------------------------------------------------------
>mail2web - Check your email from the web at
>http://mail2web.com/ .
>
>
>
>----------------------------------------------------------------------
>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
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
----------------------------------------------------------------------
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:
