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

[Bug 18764] MIDI messages don't all have a channel, and status should be part of data.

From: <bugzilla@jessica.w3.org>
Date: Fri, 07 Sep 2012 09:33:17 +0000
Message-Id: <E1T9uw9-00047v-1L@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #13 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-07 09:33:16 UTC ---
(In reply to comment #12)
> thanks for taking the time to explain. 
> 
> It's not a big deal to me how I can send "long" messages (syntax is for
> illustration purposes only, excuse my poor knowledge of WebIDL?):
> 
> A) variadic
>    send(0xF0, 0x40, 0x00, 0x7F, 0x20, 0xF7);
> 
> B) array
>    send([0xF0, 0x40, 0x00, 0x7F, 0x20, 0xF7]);
> 
> C) MIDIMessage
>    send(new MIDIMessage(0, [0xF0, 0x40, 0x00, 0x7F, 0x20, 0xF7]));
> 
> I can live with all of the above, but A) does seem the most straight forward,
> and I don't think that pushing arguments on the stack is worse than creating an
> array and pushing the array pointer on the stack.
> 
> > Otherwise, the data will need to be inspected not only for length, 
> > but for partial messages as well, and we will need a lot more error
> > returns to explain to users how they've violated MIDI protocol.
> 
> For this argument, I don't see the difference of A) and C). And C) will be
> available in any case, I guess.
> 
> However, I really don't think that a MIDI API should verify or otherwise
> enforce that the byte stream sent via the API conforms to the MIDI protocol.
> It's nice to optimize the API for short messages, but there should be a way for
> the user to send what she wants, it IS a serial protocol! MIDI is used in so
> many areas that it wouldn't be good to unnecessarily restrict the type of
> messages that you can send. IMHO, the Windows MME and CoreMIDI do not set good
> examples there (although Windows, at least, allows you to send arbitrary data
> via midiOutLongMsg()). ALSA on Linux gives you full power with the RawMIDI
> interface.
> 
> Summary: the method signatures are not so important to me as long as the API
> does not enforce the MIDI protocol. Inspection of the data should be done only
> for optimization and for formatting the data for the underlying OS functions
> (e.g. CoreMIDI).
> 
> Sorry for the fuzz...

No need to be sorry, this is an open discussion.

I agree with you on this, the idea of my original API was to provide the
simplest possible API for making it possible to do anything MIDI and to enable
user libraries to abstract further when necessary, in a fashion suitable to
each project (if there's one thing I've learned during my time programming,
there is no one ultimate API that suits all).

I've actually even had to simplify further from that, as the channels/status
separation didn't make sense and the MIDIMessage interface was far too
complicated for what it represents.

I'm actually having second thoughts about the whole sendMessage short form as
well. The added value is starting to be quite miniscule, especially now that
the MIDIMessage interface is a dictionary.

The performance value is really a ridiculous discussion point as even at their
most crowded, MIDI devices hardly ever transfer more than 100 messages in a
second.

port.sendMessage(0x80, 0x70, 0x60)
port.sendMIDIMessage({
  data: Uint8Array([0x80, 0x70, 0x60])
})

-- 
Configure bugmail: https://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 7 September 2012 09:33:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 7 September 2012 09:33:25 GMT