[Bug 18759] boolean returns from MIDIOutput methods are inappropriately synchronous

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18759

Jussi Kalliokoski <jussi.kalliokoski@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #5 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-06 06:38:32 UTC ---
(In reply to comment #3)
> 1. Do we want to make it explicit in the text that the operation may be
> "enqueues a MIDI message", rather than "send"?  (I.e. that the send may not
> have completed.)

Yes.

> 2. The callback is probably most useful for the sendMIDIMessage form (since
> sysex may take a while) - although I do have one scenario that I wanted it for:
>  I have a Novation Launchpad
> (http://us.novationmusic.com/midi-controllers-digital-dj/launchpad), which is
> an 8x8 array of LED-lit buttons, plus 16 additional buttons; it is only USB
> 1.1, so can only accept a maximum of 
> 400 messages per second. Because there are 80 LED addresses, it takes 200
> milliseconds to update a Launchpad completely.  Obviously, it's kinda cool to
> animate it - I've written a Conway's Game of Life implementation
> (https://github.com/cwilso/conway/tree/MIDIBridge/WMAS) that interfaces with
> the Launchpad - but you don't know when the messages have finished writing, so
> it's hard to update appropriately.  I don't just drive the animation as fast as
> it will go - you press a button to advance - but if I did, I might end up
> overrunning the buffers if I tried to push it faster than 5 updates a second. 
> (Probably far less, of course.)

Sweet! And yes, it's actually an important use case (lighting systems).

> Both OSX and Windows have callbacks to implement this, but the OSX one is ONLY
> for Sysex Send calls, so it would be better to have this only on
> sendMIDIMessage if we add it.

But sendMessage can send SysEx messages too. Still, I agree, no need to
complicate sendMessage with a callback.

We'll also have to clarify the enqueueing behavior. Do we want the
implementations to drop messages that couldn't be sent to the port at the
expected time? Or do we want the implementations to make sure that no messages
are dropped?

The latter is not necessarily easy to execute and it has some drawbacks:
 * For one, keeping the buffers too busy will become a significant memory leak
over time.
 * Keeping the buffers busy will also keep increasing latency.
 * What happens when there is nothing to write to (e.g. there is cable attached
to a MIDI port)?

-- 
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 Thursday, 6 September 2012 06:38:36 UTC