W3C home > Mailing lists > Public > public-audio@w3.org > January to March 2012

Re: Adding MIDI APIs to Audio WG Charter (was: MIDI enumeration (was: Re: getUserMedia use cases))

From: Joseph Berkovitz <joe@noteflight.com>
Date: Wed, 1 Feb 2012 17:30:59 -0500
Cc: "Tom White (MMA)" <lists@midi.org>, Doug Schepers <schepers@w3.org>, Robin Berjon <robin@berjon.com>, public-audio@w3.org, Dom Hazael-Massieux <dom@w3.org>, jussi.kalliokoski@gmail.com
Message-Id: <BF9C4D60-05A8-46AF-94E9-AFACD09E47BA@noteflight.com>
To: Chris Wilson <cwilso@google.com>
I just want to point out that most music scoring programs (including ours) don't use GM, but include their own bespoke synth, because of the problems with lack of consistency in GM playback (and as Chris found, sometimes its outright unavailability).  Consistent playback is super important in most of these applications, since scores are inevitably tweaked to sound good with the particular playback synth used by the author and the program is seen as broken if these qualities do not come through in some other user's environment.

This problem extends to other music applications other than digital audio workstations (DAWs), in particular most training/education programs, as it's very hard to create educational content in these apps that does not wind up strongly relying on the musical character of a particular synth.  Consequently most include some sort of self-contained synthesizer.

DAWs are kind of the major exception to this issue since they are often used by one user on one machine, to create a particular work which is then rendered into audio using that machine's installed MIDI rig.

So while I think MIDI output is indeed very important, for the apps that were cited as "more likely the use case for GM", I think these are actually rather unlikely to use GM.  Rather, they are likely to perform MIDI content through a JS-based synthesizer (based on an audio API in the browser of course) whose playback characteristics are known up front.

... .  .    .       Joe

Joe Berkovitz

Noteflight LLC
84 Hamilton St, Cambridge, MA 02139
phone: +1 978 314 6271

On Feb 1, 2012, at 5:11 PM, Chris Wilson wrote:

> Hmm.  In a brief browse around my OSX machine, it seems it doesn't install a GM virtual MIDI device; when I try to play a .mid, I have to download the Quicktime 7 player.  I don't know if Windows installs a virtual device or not?
> (You make a good point - music creation programs, music scoring programs, music training/education programs, etc. are more likely the use case for GM, and the first two would be more likely to use the MIDI APIs than just trying to play a .MID through an <audio>.)
> On Wed, Feb 1, 2012 at 1:51 PM, Tom White (MMA) <lists@midi.org> wrote:
> Chris,
> >>> It seems like most of the "use GM" cases have been reduced in importance by the easy use of audio files (i.e., streaming or pre-loading a high-quality audio file isn't crazy in terms of bandwidth like it used to be).  <<<
> Yes, GM was once seen as a way for content developers to distribute music across large platforms with minimal bandwidth... but I'm not suggesting it for that purpose.
> I'm thinking about applications that use MIDI because they want MIDI, such as music creation programs, music scoring programs, music training/education programs, etc. Some of those may need custom sound renderers, but others have been able to get by just fine with GM... and since GM renderers already exist on hundreds-of-millions of Macs and PCs (including all new ones being sold) I think browsers should expose them.
> Tom White
Received on Wednesday, 1 February 2012 22:31:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:49:57 UTC