<div><div dir="auto">The mantra of protocol implementation is be strict in what you provide, lenient in what you require. One has to assume that running status might just go forever, since some controllers do that. It *is* possible to make a very good guess at what is note on/off data (it’ll have two-byte messages with corresponding first bytes and nonzero, then zero, in the second byte). But you can’t be 100% sure, and anyway you can’t know the channel. So probably the most “lenient” response is to ignore it until you get a status byte.</div></div><div dir="auto"><br></div><div dir="auto">The conceptual problem, which pervades all of MIDI, is that there is no concept of sender state, only sender events. The protocol is written with the assumption that the receiver will be—and is capable of—keeping track of every event in order to implement the controller state model on the receiver, which should reflect the cumulative effect of every event that has occurred since the controller started sending events. But this is not always possible, since connections aren’t perfect. So you get a cable with an intermittent fault, release a key at the wrong moment, and then it plays forever unless you’re lucky enough to have a controller that can send “all notes off.” The end user then probably assumes your device is buggy. The running status issue is a subset of this problem, so you can only pick what to do to mitigate it (timeout to send a full status), you can’t really solve it without abandoning the MIDI model altogether.</div><div dir="auto"><br></div><div dir="auto">The right way to solve this would be to have a bidirectional protocol, some sort of way for the receiver to detect when it’s been disconnected, and to have a way for the module to query the controller’s state. Nothing else will fix the problem, so unless there are some serious changes, we have to live with it.</div><div dir="auto"><br></div><div dir="auto">(Momentary nonlurk... ;-)</div><div dir="auto"><br></div><div dir="auto">-E</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 14, 2019 at 9:13 AM MTG <<a href="mailto:grant@musictechnologiesgroup.com">grant@musictechnologiesgroup.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">But how many actually implement it? The OP seems to have a device that's <br>
not following that concept (or maybe it's just a thought exercise). The <br>
MMA should have included that as a line item in that ASCII-art MIDI <br>
Implementation Chart.<br>
<br>
All of us that made a MIDI-Out device need to do our homework too it seems.<br>
<br>
GB<br>
<br>
On 11/14/2019 7:57 AM, Tom Wiltshire wrote:<br>
> <br>
> Oh, there we go! So Running Status is just not expected to run for too long. It’s more of a sprinter than a marathon runner?!<br>
> <br>
> That’s simple enough to do. Either run a timer and make sure to send a status byte every time the timer times out, or count outgoing bytes and send a status byte with every Xth message.<br>
> <br>
> I’m impressed that’s in the spec. They really did think of everything.<br>
> <br>
> Tom<br>
> <br>
> <br>
> _______________________________________________<br>
> Synth-diy mailing list<br>
> <a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
> <a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br>
> <br>
_______________________________________________<br>
Synth-diy mailing list<br>
<a href="mailto:Synth-diy@synth-diy.org" target="_blank">Synth-diy@synth-diy.org</a><br>
<a href="http://synth-diy.org/mailman/listinfo/synth-diy" rel="noreferrer" target="_blank">http://synth-diy.org/mailman/listinfo/synth-diy</a><br>
</blockquote></div></div>