[gmpi] Re: MIDI: Proposed Requirements (wrap up try #1)

[gmpi] Re: MIDI: Proposed Requirements (wrap up try #1)Hi Ron,
That's quite interesting. This shows a more levelheaded appreciation of the no 
MIDI position...

quote..
"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)! "

..but also makes the case for MIDI...

"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."

I think the proponents of NoMiG would prefer the freedom of a clean-break from 
MIDI,  while the proponents of MiG would prefer MIDI raw and unmolested.

That's why I now think 'stapling' doesn't really satisfy either camp.  A plugin 
wants either raw MIDI, or pure GMPI, not both. Both is confusing (which of the 
two is authorative?, are future versions of GMPI stuck with stapled MIDI 
forever?).

Despite my "No MIDI" position, I would be happier if plugins declared up-front 
if they needed raw MIDI or not, and if so, the host simply delivered raw MIDI.

Before everyone flames me: Fruitlyloops shows you can write a MIDI-free host, 
yet still handle MIDI plugins via a GMPI->MIDI wrapper, after all, we assert 
that the MIDI->GMPI conversion is lossless, so it's no big deal?

Plain old MIDI hosts (Cakewalk) don't need the wrapper, it's just raw MIDI all 
the way, no hassles, no conversions.

Surely, that pleases everyone?
( In an ideal world I would push for zero MIDI, but I'm resigned to the MMA's 
intention to include MIDI in some shape or form).

Jeff
  ----- Original Message ----- 
  From: Ron Kuper 
  To: gmpi@xxxxxxxxxxxxx 
  Sent: Tuesday, July 06, 2004 1:06 PM
  Subject: [gmpi] Re: MIDI: Proposed Requirements (wrap up try #1)


  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: