MIDI Log: Receive Errors and Ommisions

Question

MIDI Target Manufacturer(s): TC-Helicon

Having set a control (Knob) to send a 'Preset Header Request' (F0) 00 01 38 00 6D 46 V (F7) where 'V' is the preset number (two byte word). I have been experimenting with how well the 'MIDI Log' handles the dialogue, I have set the number of ticks to 256, default value to 63(25% 0-63) and 'Snap To Default Value' to max of 16s. It is difficult to run a full cycle without receiving an error, which is a bit concerning for the following reasons:

<1> Maximum data throughput Tx+Rx is only 26,880 bits/16  = 1,680 bits per second.  # Basic MIDI Spec = 31,250 Max

<2> The error(s) are consistent and always consist of the same (location) 6 bytes from the middle of the packet.

<3> An example of an error is as follows:

Message In: Length=6: 32 00 00 08 20 00         # Bytes 25 to 30 of the expected 32 byte packet

This is not a valid MIDI command (top bit not set), yet it is not showing as an error, while I understand that this is only dialogue and no action is required, does this mean no validation ?

<4> As I ramp up the throughput we start to lose Rx Packets completely.

I have included a copy of the MIDI log which unfortunately is limited to 80 lines, which when you take into account the Tx Request and the short length wrap-around only gives us around 26 TX/RX cycles.

Request:    F0 00 01 38 00 6D 46 V F7    # 46 Request Preset Header (P)

Expected Response: F0 00 01 38 00 6D 20 PP PP 01 48 (15xAA Preset Name) (5xXX Tag+Step) F7   # 32 Bytes

Not sure if this is relevant but if MIDI Receive is set to on we seem to get more errors.

It might be worth mentioning the reason I started this in the first place, it was to extract the Preset Names in order to populate the ticks, I could then copy from the MIDI Log and then use Notepad++ to edit. Sorry if this has been a bit long winded but not easy to explain :-)

Lenny

Downloads: 277
VL3X_MDP_Preset_Name_Import.txt
Downloads: 277

Comments

Hey there, is there any chance you can run these tests through a Mac (Snoize MIDI Monitor) to see what's really going on? We're talking about receiving... sysex? I'm not understanding where the Snap to Default Value is happening... is this on another iOS device? Thanks.

---

I don' t have a Mac (iPad Mini 2), and unfortunately cannot run a midi monitor at the same time as MDP2. I created a 'Test Project' with a single control (Knob) set to sent Sysex message (Preset Header Request) to a TC-Helicon VoiceLive 3 Extreme, the control is set to a tick range of 0 to 255, and snap to value set to the maximum of 16 seconds, this is used to repeat the request automatically for further Preset Requests, I then adjust the default value (Snap to) to give me some more controlled tests:

Test A - MIDI Default Value 25% (0 to 63) Snap To Value 16 seconds      # 4 Requests Per Second
Test B - MIDI Default Value 50% (0 to 127) Snap To Value 16 seconds    # 8 Requests Per Second
Test C - MIDI Default Value 75% (0 to 191) Snap To Value 16 seconds    # 12 Requests Per Second
Test D - MIDI Default Value 100% (0 to 255) Snap To Value 16 seconds    # 16 Requests Per Second

The results in the last post where for 'Test B' and show both the requests and the responses, with the error appearing at preset 0x0068, I am fairly confident that the VL3X is sending the response packet, and in fact the log shows six bytes of it but misses the beginning and the end. The error(s) don't always appear in the same place (Not same preset number). The last preset on the MIDI log copy show preset '00 7F' 128 on the last two lines (Request + Response).

I'm not sure whether this is just a MIDI log issue (Message received but not displayed correctly) or a driver or buffer problem.

Lenny

---

I have just done some further testing, this time using a wired connection (USB<-->USB) this works as expected even on Test D without any errors, therefore this seems to be a Bluetooth problem, drivers maybe? It shouldn't be a capacity issue at these sort of speeds should it ?.

Lenny

---

Wow, that's very surprising. So: we don't actually have ANY code that differentiates between BT and other connections (though we could), and the entire system is agnostic as far as which connection type we're using. This is the first we've heard of issue with BT, and while I'm glad to see it's on Apple's side -- on one level -- I'm sad to see that we have no control over fixing it.

What are you using for USB -> USB? Also, can you try Wi-Fi?

Thanks!
Dan

---

Hi Dan,
I'm just using the standard Apple iPad connector (Camera?) for the iPad USB and micro USB straight into the VoiceLive3X, this works well without any errors even on Test D. The BT connection is from iPad std BT to Yamaha MD-BT01 BT to MIDI Adapter connect to MIDI sockets on the VoiceLive3X.

Wi-Fi not possible on the VL3X.

The thing I find strange is the error has structure, it is always 6 bytes and consists of bytes 25 to 30 of the missing (32 Byte) packet, and these bytes are always correct with no bit errors, we are just missing 24 bytes from the beginning and 2 bytes from the end.

Could it be something to do MIDI <--> Bluetooth packet conversion ? Drivers ?

What about validation ? does the MIDI log validate MIDI messages in any way, valid structure F0 -- F7 ?

Lenny

---

Just tried another test reducing the default snap value to 31 (12%) while leaving the snap to value at 16s, also decided to place the iPad next to the VL3X, the results where exactly the same, puzzling! :-)

Lenny

---

There are some serious issues with low-time values on those timers. Since 60fps is 17ms, that's the fastest any one snap will go (and it might be double that)...I've implemented a fast timer which will fix this, and it might show up in 2.9, but it looks like it'll get pushed forward. Thanks.

---

Would this not only effect Tx Packets ? (These are being sent ok) it's RX packets that contain the error(s). Still curious as to whether the MIDI log does any validation on incoming MIDI packets, I guess based on the result - 'a six byte non valid MIDI packet', that it doesn't.

Lenny