https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764
--- Comment #22 from Jussi Kalliokoski <jussi.kalliokoski@gmail.com> 2012-09-09 10:28:33 UTC ---
(In reply to comment #21)
> For short messages, I agree. For Sys Ex, it is important to allow partial
> messages: many MIDI devices use big Sys Ex dumps (e.g. one single Sys Ex of
> 100KB), but cannot handle them if sent to them at full speed. Ideally, the MIDI
> bytes would need to be throttled for such devices, but sending in timed chunks
> of, say, 100 bytes will achieve the same. Or we add API methods to set the send
> speed...
Yes, this is a problem that needs to be thought about, thanks for bringing it
up. Ideally the underlying implementation would take care of this (so that you
could just send the complete message), but if so we need to specify how. It
also is a bit orthogonal with previous discussion about allowing the UA to dump
overflowing messages.
Maybe we need to specify the buffer handling in a way that implies that the
buffers need to be big enough to hold large SysEx message dumps like that.
After all, even 1MB at worst case isn't terribly much for one device given that
the benefit is that the developers generally don't need to worry about the
buffers getting overflown.
Ideas?
> > > the name suggests that it holds only one. Maybe adopt the CoreMIDI name
> > > "MIDIPacket" instead?
>
> fine with me, but "MIDIMessage" works the same to me.
>
> Regarding the "sugar" method (i.e. a method that takes MIDI bytes directly as
> parameters): IMHO, it is useful and convenient (especially with var args) and
> will save a few CPU cycles compared to sendMIDIMessage().
> But not having the sugar method and only provide sendMIDIMessage() will be OK
> for me, too -- I feel only a tiny bit of pain when allocating an array and an
> object for transmitting 3 bytes :)
Given that JS is a dynamic language, for most cases it's possible to optimize
that allocation away if it really turns out to be big enough a pain point to
justify that. -.-
Or the short signature can be added at a later date. But so far I haven't seen
any data supporting the case that this operation is so expensive that it
justifies complicating the API. Even for orders of magnitude larger performance
gains it's usually hard to justify adding a special method for speed-up. I
managed to get Number.prototype.clz() accepted for ES6 and even that required
me to prove valid real-world use cases that would very significantly benefit
from that method being a pain-point. XHR is now slowly getting support for
chunked processing of data (try responseType = "moz-chunked-arraybuffer"),
although it's an obvious pain point for any binary processing.
> > > A shorter send() function name also seems more correct for this reason.
>
> yes, as previously expressed, I like that, too.
--
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.