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

Hmm.  Sounding more and more like if there is a GM synth installed (as a
virtual MIDI device) of course we would enumerate it and allow it to be
used, but we shouldn't necessarily do anything more than that; except, of
course, enabling virtual inputs and outputs to be created.

As before, of course, we should encourage HTML to explicitly mention (and
vendors to support) .MID as a file type for <audio>, but I think that's a
separate issue.
On Wed, Feb 1, 2012 at 2:30 PM, Joseph Berkovitz <joe@noteflight.com> wrote:

> 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*
> President
>
> *Noteflight LLC*
> 84 Hamilton St, Cambridge, MA 02139
> phone: +1 978 314 6271
> www.noteflight.com
>
> 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
>> MMA
>>
>>
>
>