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: Robert O'Callahan <robert@ocallahan.org>
Date: Tue, 7 Feb 2012 09:38:46 +1300
Message-ID: <CAOp6jLZvPBZ3r2kb-JiZX7w_LL+vbg_Ln6s53w0tYNfHxAxb8Q@mail.gmail.com>
To: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>
Cc: Joseph Berkovitz <joe@noteflight.com>, James Ingram <j.ingram@netcologne.de>, public-audio@w3.org
On Tue, Feb 7, 2012 at 8:42 AM, Jussi Kalliokoski <
jussi.kalliokoski@gmail.com> wrote:

> I agree. The writeMIDI was actually something I forgot to put there, but
> had in mind initially. Also, if ProcessedMediaStream had a method to attach
> a MIDI input to it, like myPMS.addStream(MIDIInputDevice), would be pretty
> handy.

My idea is that getUserMedia would simply produce a MediaStream with a MIDI
track (or synced audio and MIDI, etc). Then you can use the existing
myPMS.addStream(inputStream) and you're done.

I need to think a bit more about multi-track support in
ProcessedMediaStream. I'm guessing you will want an input MediaStream to
support multiple MIDI tracks and a convenient way to access the data for
each track in a ProcessMediaEvent. Currently, for simplicity,
ProcessedMediaStream is defined to pre-mix together all enabled audio
tracks for a given input stream before processing, but in some cases you do
want to be able to process a stream's audio tracks separately. This could
be done by splitting tracks out into their own MediaStreams (WebRTC
MediaStreams have an API for that) and sending those as independent inputs,
but there are probably better alternatives. Needs thought.

"If we claim to be without sin, we deceive ourselves and the truth is not
in us. If we confess our sins, he is faithful and just and will forgive us
our sins and purify us from all unrighteousness. If we claim we have not
sinned, we make him out to be a liar and his word is not in us." [1 John
Received on Monday, 6 February 2012 20:40:54 UTC

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