[gmpi] Re: MIDI: Proposed Requirements (wrap up try #1)
- From: "Ron Kuper" <RonKuper@xxxxxxxxxxxx>
- To: <gmpi@xxxxxxxxxxxxx>
- Date: Mon, 5 Jul 2004 21:06:32 -0400
A few weeks ago when we were in the heated debate about MiG vs. NMiG, I
promised I would ask some people from a couple of "the majors" to weigh
in. One of them has agreed to repost his reply, but asked to be
anonymous.
I wasn't even going to post this because we've just about wrapped up the
discussion. But given the posting from the team at Smartelectronix, I
think it's worth hearing another perspective. I don't think anything
here really adds to any of the old arguments, but is interesting in that
it is the voice of a key technical person at a large musical instrument
corporation. As you'll see his position is not strongly MiG, but does
press on the importance of having a lossless conversion to/from MIDI.
Also, his final paragraph is an encouraging reminder that big companies
are interested in what we're doing.
----------
I don't think I can provide you with a corporate view from <snip> (or
even
if such a consensus view could be achieved within <snip>). Therefore I
would
prefer not to post my view to the list.
However, for what its worth, my personal view is that MIDI must be
maintained at the input and output edges of GMPI. If you decide to avoid
direct use of MIDI internally, then I am not too concerned, so long as
the
replacement is better and lossless when converting to/from MIDI. However
to
do so is a pretty big undertaking that shouldn't be entered into
lightly!
I think the reasons for maintaining MIDI are pretty obvious, not simply
for
the reason you mentioned, but also from the view that all the major
sequencers currently support MIDI sequencing and will need to maintain
that
support for real I/O (as MIDI hardware isn't going to disappear anytime
soon). I really can't see all DAW vendors rushing to support some new
music
representation just to support GMPI....unless there are truly
revolutionary
gains to be made. Obviously it's not just a case of supporting GMPI MIDI
replacement events, but also re-writing musical editors that currently
exist
for MIDI (that musicians are already familiar with). Even if DAWs do
decide
to support GMPI music representation, this won't happen overnight, so
the
take up of GMPI will be impeded.
If we assume that sequencers maintain MIDI for sequencing, but convert
to
GMPI at the edge of the graph, then it's also questionable as to what
advantages the new GMPI music representation will really add. Ultimately
the
host sequencer must cater for editing the GMPI events for the
representation
to be of benefit. So once again this adds a large burden to the host
(unless
you also propose that GMPI can provide plugin editors for its own music
representation....in which case you end up with a <snip>).
Also I think many of the cases being discussed on the list against MIDI
are
all solvable (and have been solved in the past) using MIDI. Sure, many
of
those solutions are not elegant to implement...but they do work. This is
not
to say that MIDI (particularly the hardware spec) couldn't do with being
updated (not least in terms of channel numbers, transmission speed etc),
but
I think if this is to be undertaken it should be performed in a holistic
way
that looks at the whole usage. I really can't see that you want to widen
GMPI scope to this extent.
<As an aside, I find it amusing that there are numerous references to
MIDI
in the current spec that almost implicitly indicate that MIDI will be
retained for musical representation>
You could also take another view: Given that you are defining an
extremely
flexible parameter model, you could simply define an advanced music
representation within this model side by side with MIDI. I really don't
see
why there should be a big distinction between musical data and control
data?
Ultimately all of these things are just events that control the
operation of
the device (real or virtual)!
By the way, I think the definition you have for the parameter model is
shaping up nicely and has some very interesting features. However I
think it
may requires a little more thought if you go beyond purely software
based
plugins e.g. a model where you have a software plugin communicating with
a
hardware processing engine. In particular the Dynamic Parameter sets
section
could do with some more fleshing out.
One final note, I am monitoring the list and reading the posts/spec as
and
when I can find time. There are several other people within <snip> doing
likewise. So please don't think we are not interested. It's simply a
case
that <snip> can be a little paranoid about staff posting to such open
discussion forums. Hopefully we can get involved at some stage in the
future.
Other related posts:
