Talk to other MIDI Designer users about MIDI Designer, iOS MIDI and related topics. Or share layouts, pages, and ideas.

Also check out the Facebook Group.

Of course, if you want to send us an email, feel free.

MIDI Designer
Design your perfect MIDI controller for iPad, iPhone and iPod touch.
MIDI Log: Receive Errors and Ommisions - MIDI Designer Q&A

MIDI Log: Receive Errors and Ommisions

0 votes
asked Apr 19, 2017 in User Support, Resolved by lenny-savage (700 points)
recategorized Apr 21, 2017 by MIDI Designer Team
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.

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 ?.

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?

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 ?

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! :-)

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.