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: Sun, 09 Sep 2012 22:12:27 +0000
Message-Id: <E1TApjv-00049e-VU@jessica.w3.org>
To: public-audio@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=18764

--- Comment #23 from Florian Bomers <w3c_bugz@bome.com> 2012-09-09 22:12:27 UTC ---
(In reply to comment #22)
> 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?

we should to distinguish 2 problems here:

1) buffer overflow on sending side. I propose to handle this with a "false"
return value of the send() function. The buffer should not get too big (except
for scheduled messages) to prevent accidental bursts.

2) buffer overflow on the receiving side. This is what I meant: many hardware
devices are not capable to receive/process incoming MIDI data when it comes at
full MIDI speed. For the sender, it is impossible to tell that the receiver
cannot keep up. It's up to the specific application to throttle as needed for a
specific hardware device, e.g. by a setting for the user. It can be implemented
by having an API method for throttling, or by sending only small chunks of the
big Sys Ex messages with delays in between.

-- 
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 Sunday, 9 September 2012 22:12:29 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Sunday, 9 September 2012 22:12:29 GMT