[gmpi] Re: 3.15 MIDI
- From: "gogins@xxxxxxxxxxxx" <gogins@xxxxxxxxxxxx>
- To: gmpi@xxxxxxxxxxxxx
- Date: Fri, 18 Jun 2004 14:15:21 -0400
I think if we can bring MMC into GMPI without going nuts, we should. But if
we do end up going nuts, and if it's not musical semantics, I vote that we
forget it.
----- Original Message -----
From: "Paul Davis" <paul@xxxxxxxxxxxxxxxxxxxxx>
To: <gmpi@xxxxxxxxxxxxx>
Sent: Wednesday, June 16, 2004 10:32 PM
Subject: [gmpi] Re: 3.15 MIDI
> >What about MIDI sync? Do we want the GMPI graph to be able to chase to
> >external beat boxes?
>
> We certainly do.
>
> If the GMPI graph can chase a tempo map of some kind, then I would
> imagine chasing MIDI sync is pretty trivial. Since chasing a tempo map
> is in the reqs (somewhere, right?), this is a done deal.
>
> >What about MIDI machine control? Do we want the GMPI graph to play when
the
> >user presses [Play] on their ADAT machine?
>
> We certainly do.
>
> I don't know of any plugin that works with MMC, and its frankly hard
> to imagine how they would. What machine ID would they use? How do they
> tell the host their machine ID so that it understands to route the
> sysex to them? Or does it send sysex to all plugins? How can a plugin
> "start" if the host doesn't "start"? How can 1 plugin start if others
> do not?
>
> MMC is used today to control hosts, and I imagine that this would not
> change.
>
> >> What matters are not byte-level correspondence, but semantic
> >> correspondence, and this is easily achievable.
> >
> >I'm not convinced this is achievable. For example, let's consider the
> >conversion of MIDI volume controller to GMPI. MIDI volume doesn't have a
> >standard mapping from 0-127 to gain values. So how does this value get
> >converted within GMPI? How the does the converted value survive the
round
> >trip through a processor that does:
> >MIDI -> GMPI - > [Event Processing] -> GMPI -> MIDI.
>
> What happens today?
>
> MIDI -> MIDI processing -> MIDI
>
> Thats not what we are really talking about, hence my attempt to
> distinguish between *editing* MIDI streams and being *controlled* by
> MIDI streams.
>
> But anyway, if we do have
>
> MIDI -> GMPI -> [ Event processing ] -> GMPI -> MIDI
>
> how would
>
> chan0,CC#7=123 -> /chan[0]/volume=0.968503937
>
> [ ... ] -> /some/other/message ->
>
> chanN,CC#=iii
>
> not work? just standardize the rounding method for float<=>int, and i
> see no issues with this, save one:
>
> What if /some/other/message cannot be translated back into MIDI?
> Frankly, I just see this as a problem. If I write a processor plugin
> today that takes MIDI, converts MIDI to a position in a 2D lookup
> table, and then uses the value from the table to control some
> parameter, how can I convert that value back to MIDI? In the general
> case, I cannot. If you write an [ Event Processor ] that converts MIDI
> into a fundamentally different form, then the original MIDI byte
> stream is lost. No different than it is today. If you *must* keep it
> around (say, for "thru" processing), then you do what you would have
> to do today: copy the incoming message and forward that.
>
> >The problem with MIDI, or rather, with assuming we can cleanly convert
MIDI
> >messages to another control format, is that in many cases the semantics
of a
> >MIDI message are opaque.
>
> Thats EXACTLY why we don't want it floating around inside of the GMPI
> graph. Did MIDI CC#7=98 set the gain of all plugins to a particular dB
> level? No way to know that. In fact, there is no way to know what
> effect any MIDI CC has on any plugin, a priori. I never enforce the
> standard MIDI "semantics" of CC's in my host, because for the most
> part its just irritating to actual users.
>
> The central issue, i think: whenever a MIDI message has a controlling
> effect on a plugin, the host needs to know what effect it will have.
>
> There only two ways to do that: either the host enforces semantics on
> the message (e.g. converts it to a GMPI control message), or the
> plugin calls back to the host to notify it of a parameter
> change. Please check the archives or the reqs. document for more on
> why we didn't we want that (because to be perfectly honest, I've
> forgotten :)
>
> --p
>
>
>
> ----------------------------------------------------------------------
> 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:
