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: Mon, 10 Sep 2012 21:50:32 +0000
Message-Id: <E1TBBsG-0007ET-3P@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #29 from Florian Bomers <w3c_bugz@bome.com> 2012-09-10 21:50:31 UTC ---
(In reply to comment #26)
> Florian:
> I have to admit, I haven't heard of this before either. Could you elaborate
> this a bit? Is this some sort a memory allocation limit (I'd imagine the device
> has to be pretty old to not be able to handle its own system dump)? CPU limit
> (if so, I'd think that the device would just become unresponsive for a while)?

Mostly this was a series of smaller Sys Ex messages sent at full speed. This
applies to older MIDI-DIN devices as well as USB MIDI devices. One reason is
that they don't have a buffer large enough to hold the entire dump, so they
need to process it as it's coming in, which is too slow to keep up if the
incoming messages come without pauses. The other reason I'm seeing in quite a
few (and new) devices is that specific Sys Ex messages will make the device
unresponsive for a couple of milliseconds so it'll miss some following MIDI
bytes.

But every now and then I get a support request where one big sys ex causes
problems, and throttling helped.
Could be that the MIDI driver or the OS is messing things up, but because of
the problems with the shorter Sys Ex messages, I always assumed it to be a
problem on the receiver side.

> And how would one really counteract this, how do you know what size of chunks
> to send and how often? After all, based on your explanation it would appear
> that different devices have different limits? I also wonder how the devices
> handle the dump when it's complete if they can't handle it if it's sent as a
> whole...

Unless you're writing a general-purpose dump app, I don't see a problem. The
app will be targeted to a specific device, so the programmer can take care of
proper throttling/waiting.

I don't think we need to add API methods for that. My main point is that the
API should not discard MIDI data if it's incomplete. It's the user's
responsibility to send data that will make sense to the receiving end.

Ah, one other thing I've heard of (but not seen myself): MIDI streaming, a Sys
Ex is started but never finished with F7, for realtime streaming of arbitrary
(7-bit) data. FWIW.

-- 
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 Monday, 10 September 2012 21:50:33 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 10 September 2012 21:50:37 GMT