Re: Web MIDI API - Please Add a Player!

Except that this isn't low cost, high payoff functionality.  Implementing
Standard MIDI File playback in <audio> would be relatively small cost,
relatively small payback functionality - but if we were really to build a
standard MIDI file player into a built in API at the level of Web MIDI, I
would expect it would quickly be inundated with requests for
synchronization, track-to-device assignment, internal GM synth
standardization, tempo control, quantization, transposition, dynamic
editing, and many more obviously interesting features.

Writing an SMF reader isn't particularly hard
<https://github.com/cwilso/Standard-MIDI-File-reader>.  Writing a routine
to schedule playback of the track events in that SMF, a la playing MIDI
files in MediaPlayer in Windows, isn't too much more difficult, if you're
hardcoding lots of decisions (like device assignment, tempo control, and
not exposing an object model for the tracks).  But let's be realistic, the
situation when you ONLY want to play back an SMF, without doing something
more interesting like syncing an onscreen display, giving control over
parameters - e.g. a DAW - is not a huge win.  It DOES match the API level
of <audio> - but you're not going to get any more enthusiasm for
implementing this in a JS API than in <audio>.  It's simply a
return-on-investment issue; clearly I love MIDI, but taking on the
additional weight in every user agent to have a MIDI file reader,
sequencer, and GM synthesizer, is more than this scenario is worth today.
If we were awash in developers wanting to have background music in SMF
form, I'd feel differently.

In short, I strongly expect a few libraries to expose this functionality in
an easily packaged way; but I don't think we know enough about the desired
level of exposure to code it into a Web MIDI-style built in API today (and
it DEFINITELY does not match Web MIDI's API level).  Web MIDI MUST support
SMF sequencers built on top of it, of course.

On Sat, Feb 28, 2015 at 10:47 AM, The Cyber Hymnal™ <cyberhymnal@hotmail.com
> wrote:

> Please reconsider your position and add MIDI player functionality to the
> Web MIDI API. Though the 26 Feb draft API mentions the HTML <audio> tag,
> there seems to be little or no enthusiasm at browser makers to support MIDI
> via the <audio> tag. Why this is the case is beyond me: Any browser that
> could play MIDIs natively would have a significant advantage over its
> competitors.
>
> At any rate, since the browser vendors seem to be ignoring MIDI, why not
> add a MIDIPlayer object to the API & let Javascript programmers do the job?
> A player interface could be defined very simply , something like this:
>
> *startPlay(url)*;
>
> *stopPlay(url)*;
>
> *setAutoplay(url, loopCount)*
>
> *setMute(true/false)*
>
> *setPreload(url, true/false)*
>
> *setCallBack(seconds, function(url, secondsPlayed, secondsRemaining) {*
>
>
> *    // The player would invoke the specified callback function*
>
> *// every xxx seconds, as specified in the setCallback() argument*
>
> *// A script could use this callback to update **an HTML*
>
> *    // **slider element** (<input type="range">*
>
> *)});*
>
>
> The methods are based on the options for the HTML <audio> tag.
>
> The current WebMIDI API seems to be geared toward sound engineers. Adding
> a simple player interface would make make MIDI accessible to the millions
> of more plebian Web developers. A browser maker that implements the rest of
> the Web MIDI API should be able to add player functionality without little
> additional work.
>
> Please consider this low cost, high payoff functionality!
>
> Dick Adams
>
>
> *___________________________The Cyber Hymnal™       <>< *
>
> *http://www.hymntime.com/tch <http://www.hymntime.com/tch>*
>