Sending a complete track

[nfroidure]

Discovering the current draft, i wonder why there is no way to send a complete track to the WebMidi API. Something like :

var track; // my track in an ArrayBuffer
var midiAccess; // my midi access object
var midiOutput=midiAccess.outputs()[0];
midiOutput.sendTrack(new UInt8Array(track));

That way it could be simple to read a file in an ArrayBuffer and read 1 or more tracks selectively without assigning new memory.

Do you think it's still time to add such feature to the spec ?

[toyoshim]

I guess track means Standard MIDI File here. We can implement it in JavaScript easily, so I think native API is not needed.

[nfroidure]

MIDI files are splitted into multiple track chunks. I know it's feasable, but it's not efficient. Getting a DataView or a Uint8Array containing events of a track (https://github.com/nfroidure/MidiFile/blob/master/src/MidiFileTrack.js#L49) and sending it to the midi output could avoid many performance problems like the one i just reported on the WebAPI polyfill : https://github.com/cwilso/WebMIDIAPIShim/issues/30

Also, in MIDI files, duration are expressed relatively to the previous events, i think it would be simpler to let the MIDI output manage it.

[toyoshim]

If just playing SMF file is hard for Web MIDI API, the API must be useless. We should fix performance problems to implement perfect SMF player in JavaScript. The API is expected to handle realtime MIDI events, and more complicated track data like DAW softwares do.

Chris's demo is just a simple example how to use the API, I think.

[jussi-kalliokoski]

could avoid many performance problems like the one i just reported on the WebAPI polyfill

As you say in the issue, the problem is caused by setTimeout, not Web MIDI API.

Performance is important, but computers have been able to play SMF since I was a little kid with no problem at all. This API is intended to be a low-level API, and my opinion is that we will start implementing parts of SMF only if it becomes a provable performance issue in the real world usage of the API (in browsers that implement the API, not polyfills). And hopefully not even then, we should instead fix the performance problems in the existing API surface. This API is very minimal in enabling something that was not possible on the web before and I hope to keep it that way.

[nfroidure]

The problem will remain the same even with a native implementation if the spec do not tell that events should be output instantly and not hang for the current main thread tick end.

If you keep that approach, i think this behavior should be added to this part of the spec. "The time at which to begin sending the data to the port (as a DOMHighResTimeStamp - a number of milliseconds measured relative to the navigation start of the document). If timestamp is not present or is set to zero (or another time in the past), the data is to be sent as soon as possible."

[jussi-kalliokoski]

If you keep that approach, i think this behavior should be added to this part of the spec.

That terminology is already in the spec, how much sooner can you do than as soon as possible?