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 Receive over Bluetooth/USB unreliable in MDP2 2.9.0 Build 170512 ? - MIDI Designer Q&A

MIDI Receive over Bluetooth/USB unreliable in MDP2 2.9.0 Build 170512 ?

0 votes
asked Jul 11 in Defect (Is this broken?) by lenny-savage (700 points)
edited Jul 12 by lenny-savage
MIDI Designer does "thinning" of incoming MIDI data except where the value is 127 or 0. However, your end value -- which is where the sender ends up when things calm down -- should match the end value in MD. Does this help explain what you're seeing?
No. If MDP receives a 'Program Change' I expect it to respond to it not ignore/lose it, it does this correctly only three times in a sample of 10 attempts. The VL3X sends a 'Program Change' (C0 73) which MDP either loses or ignores most of the time.

Thanks for your response. Are the values missing in the middle of a batch or at end of the batch? MIDI Designer throws out values on the same CC until it can catch up, and those values will also be missing from the log.
What batch? this is a single patch change and consists of 8 single events 7xCC 1xPC just how much catching up does it have to do? I suggest you read my complete post, otherwise what is the point of me taking time to document the problem if it's not being read before you reply. The 'MIDI Wrench' example (which works fine) even gives the time of the events in milliseconds which you may find useful.

I have a theory that might explain this strange behaviour:

If MDP is wrongly interpreting the PC (115) as a CC, the next MIDI instruction is a CC (115) if it then throws out the first in favor of the second (the latest) then we have lost our 'Program Change'. The reason it sometimes works ok is just a question of timing. The previous (114) and following (116) presets work fine, but they probably wouldn't if they had a CC (114) or CC (116) following the PC.

Hope This Helps

There's no reason that we couldn't spin up an alpha version where you could toggle this off at some point. Right now, we're tending to several fires, but once those are handled, we're glad to discuss.
OK, I have done some more tests which seem to confirm my theory, let me know if you would like me to provide the output. If there is any way I can help further let me know.