W3C home > Mailing lists > Public > public-audio@w3.org > July to September 2012

Re: MIDI Tracks and Sequences

From: Chris Wilson <cwilso@google.com>
Date: Tue, 11 Sep 2012 16:14:00 -0700
Message-ID: <CAJK2wqUkE-NVZ0tgPin+CkbhQd2X4i6hGOY3ciRTxd5YGa3eLg@mail.gmail.com>
To: James Ingram <j.ingram@netcologne.de>
Cc: Jussi Kalliokoski <jussi.kalliokoski@gmail.com>, public-audio@w3.org
Hey James-

Actually, sendMIDIMessage takes MIDIMessages, which can have a timestamp -
it's not an "absolute" timestamp in the sense of being relative to the UNIX
epoch or anything, but you can in fact send an entire buffer of
MIDIMessages with their timestamps to be sent at the same time.

This doesn't address wanting to change tempo dynamically (or pausing), of
course; but you absolutely can do this.  I'm not sure it's what you'd want
in most cases (other than simple playback), but it is definitely there.

On Tue, Sep 11, 2012 at 2:00 AM, James Ingram <j.ingram@netcologne.de>wrote:

> Hi Chris, Jussi, all,
> Thanks, Chris, for this answer. I could certainly live with using a
> dedicated Javascript library which provided Tracks and Sequences. Probably,
> some libraries will be more suitable for some tasks than others, and its
> best to leave that flexibility outside the MIDI API.
> And I take your point that the current API needs to get locked down before
> we start talking about v2 (libraries).
> But I'm still wondering if the API is really complete as it stands. I'm
> currently wrestling with the problem of accurate timing, and am asking
> myself why this is such a hassle. If there was an accurate
>      MIDIOutput.sendAtAbsoluteTime(**midiIMessage, absoluteTime)
> then the underlying code could take advantage of existing timing
> facilities, and the API's user (me) could get on with solving other
> problems. I suspect that timing problems in particular would be best solved
> at a low level...
> best,
> James
> Am 11.09.2012 00:48, schrieb Chris Wilson:
>> Hey James -
>> A while ago, I poked at implementing Standard MIDI File reading in
>> Javascript (https://github.com/cwilso/**Standard-MIDI-File-reader<https://github.com/cwilso/Standard-MIDI-File-reader>),
>> and my conclusion was basically that it would be best provided as a library
>> and/or as baked into the standard <audio> player engine in the browser,
>> rather than centering the MIDI API on it.  There are a lot of challenges
>> with doing rewinding, for example, and seeking.  There is also a lot of
>> dynamic control hooking in to tempo changes, live information exposure of
>> events, etc., that any "serious" sequencer would probably want to have.
>>  Even in that relatively naive reader, there are a bunch of different types
>> of data - it has more exposure than the MIDI API does by itself.  Once
>> we've got the MIDI API locked down and implemented, I'll probably go back
>> and flesh out my SMF reader as a library for reading and playing SMFs, and
>> we can talk about if it's a useful v2 standard library.
>> -C
>> On Mon, Sep 10, 2012 at 5:06 AM, James Ingram <j.ingram@netcologne.de<mailto:
>> j.ingram@netcologne.de**>> wrote:
>>     Hi Jussi,
>>     I think support for Sequences would be useful (and easy to
>>     provide), even if we are not talking about file output.
>>     Loading sequences from files is very common in MIDI programs, and
>>     I see no reason why that should not be done on the web. So it
>>     would be nice to have a standard Sequence definition with which to
>>     work. I'm not saying that Sequences necessarily have to be loaded
>>     from SMFs, but if the Sequence definition existed, it could
>>     obviously be given a loadFromSMF(url) member function.
>>     Also, if we had a Sequence object, it would wrap the output
>>     device, and play(), stop(), rewind() etc. functions could be
>>     provided quite cheaply out of the box. That might make Web MIDI
>>     even more attractive. :-)
>>     But maybe I'm too close to the problem. Is there anyone else out
>>     there who needs to send a Sequence to the output device?
>>     best,
>>     James
>>      Hi James,
>>>     A side note: the current spec has the notion of MIDIEvent as a
>>>     DOM event that occurs when MIDIMessage(s) are received.
>>>     The toolkit you're referring to deals both with MIDI files (SMF)
>>>     and MIDI devices. Our API is designed to work with just devices,
>>>     and MIDI devices are just I/O, there's no notion of high level
>>>     concepts such as tracks (although there's channels, but that's
>>>     already in the spec) or sequences, unlike SMF does. It would seem
>>>     a bit weird to me to complicate the spec with such high-level
>>>     concepts as we don't even support reading / writing SMF files,
>>>     nor do I think we should as the intent of the device is
>>>     explicitly to allow communication with MIDI devices.
>>>     Cheers,
>>>     Jussi
>>>     On Mon, Sep 10, 2012 at 12:32 PM, James Ingram
>>>     <j.ingram@netcologne.de <mailto:j.ingram@netcologne.de**>> wrote:
>>>         Hi Chris, all,
>>>         Chris Wilson said (apropos Bug 18764)
>>>             I'd like to explicitly ask for MORE feedback from developers
>>>             using MIDI today on this issue.
>>>         I'm following the Bug 18764 debate very closely, but don't
>>>         have the in-depth knowledge of MIDI's finer points to
>>>         contribute much to the subject.  All I want as a future user
>>>         of this API is that it is going to be succinct, work as
>>>         efficiently as possible and be clearly documented. Whether
>>>         functions are overloaded or not is not really crucial. If I
>>>         want to use the Web MIDI API, then I'm going to have to learn
>>>         it one way or the other.
>>>         But I'd like to open another can of worms: :-)
>>>         The current version of the API [1] supports MIDIMessages and
>>>         MIDIEvents. Would it be possible for it to provide Sequence
>>>         and Track objects as well? I've written my own versions of
>>>         these for my current project (in Javascript), but think there
>>>         must be people out there who know much better how to write
>>>         them than I do. They are prime targets for optimization. We
>>>         should not all have to re-invent the wheel.
>>>         Interestingly, there are versions of these objects in Leslie
>>>         Sanford's popular C# MIDI Toolkit [2]., so he also seems to
>>>         have thought that they were worth providing.
>>>         Any thoughts?
>>>         Best,
>>>         James
>>>         [1]
>>>         https://dvcs.w3.org/hg/audio/**raw-file/tip/midi/**
>>> specification.html#callback-**navigatormidiaccesssuccesscall**
>>> back-parameters<https://dvcs.w3.org/hg/audio/raw-file/tip/midi/specification.html#callback-navigatormidiaccesssuccesscallback-parameters>
>>>         [2] http://www.codeproject.com/**Articles/6228/C-MIDI-Toolkit<http://www.codeproject.com/Articles/6228/C-MIDI-Toolkit>
>>     --     www.james-ingram-act-two.de  <http://www.james-ingram-act-**
>> two.de <http://www.james-ingram-act-two.de>>
> --
> www.james-ingram-act-two.de
Received on Tuesday, 11 September 2012 23:14:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:03:11 UTC