Noise on the virtual wire?

[LD]

I've been inspecting the raw bytes passed to onSend of a MidiReceiver, with external hardware synth/controller (Waldorf Quantum/Novation LaunchPad mini) and consistently find a strange pattern of "junk" bytes surrounding the expected data. I see that MidiFramer from the samples cuts that "junk", but I really want to know why it is there and where the data comes from as it has potential to collide with real MIDI data.

Examples (first non-zero bytes in the 1024 length ByteArray):

01903f434ad4c8b9f88600 = 903f43

01803f423ffcf3bff88600 = 803f42

01903d52cd6b52d6f88600 = 903d52

01803d427b3394ddf88600 = 803d42

01904b494e4e68c2f98600 = 904b49

Pulling one of those apart:

junk_____: 01__________c8b9f88600

expected: __903f434ad4__________

midiframer: 903f43

But even then, I'm not sure whether the `4ad4` should be treated with Running Status since there is junk on the wire. MidiFramer ignores those, why?

Thanks for any assistance :D

[LD]

Some analysis using a DAW follows. No clock messages (0xf8) being sent.

Sending a chord of 3 notes more often than not sees 2 calls to onSend, first contains 2 note ons (plus junk!) while 2nd contains 1 note on (and even more junk!). Sometimes 3 note ons will arrive in the same onSend though.

Now with clock messages being sent from the DAW. The only part of the following byte array that is accurate is the 0xf8 at index 1, the rest is absolute junk garbage that is problematic for processing. It looks like a note on for channel 10 is in there, maybe the drummer started without me knowing? There is no drummer, that note on is junk garbage and I do not know how to sensibly filter it out.

01f89c221eab76790200fa01d17caa767902

So far my algorithm to frame the midi does the following:

1) detect when bytearray goes "idle" with all 0x00 bytes. The last 7 bytes before that are definitely junk. @.@

2) ignore erroneous (junk) value bytes before receiving a MIDI Message MSB. @.@ That is always a 0x01 (but who knows?!)

3) do not honour running status, because it will probably act on junk! @.@

4) stop processing if running status is needed. @.@

5) stop processing if an erroneous (non-system-realtime) message contaminates the trailings of a legit MSB. @.@

6) stop processing if within the last 7 bytes of "definite junk".

The bytearray above that only contains a legitimate 0xf8 poses serious problems even with this standards-maming framing algorithm. I could potentially try to reject any detected messages that aren't on the same channel as the first detected message, again limiting the ability for standards to be achieved. If Android can only support a very limited set of features in the MIDI standard then it should be clear about that, the APIs should not be putting this junk out either.

The only reference I've seen in documentation to the junk is this: "The data that arrives is not validated or aligned in any particular way. It is raw MIDI data and can contain multiple messages or partial messages. It might contain System Real-Time messages, which can be interleaved inside other messages."

 from https://developer.android.com/reference/android/media/midi/package-summary

I would say that is not true, there is mostly absolute junk data in there.

Guidance and greater transparency would be much appreciated!

[LD]

I had ignored the offset and count information provided in onSend (and did that upstream when initially working with ktmidi). I guess this API is a symptom of its native roots, unfortunate it isn't clearer in documentation since it is a bit like having the sewerage and drinking water connected to the same tap.