Garth, I designed the Zildjian Gen-16 AE Cymbal system. The companion desktop utility app, the "DCP Access Tool" was written in RS and uses MBS plugins.
Here is the problem I encountered with PortMIDI sysex under MBS, as posted to this list in January 2011: "The problem is that there is no way of knowing how many sysex data bytes the RawMessage contains, and therefore there is no way of knowing how many leading zeroes to pad the hex string with. A RawMessage that converts to &h42 might be only one byte of sysex data but it might also be 42 00 00 00 or 42 00 00. The number of data bytes in each PortMidiEventMBS.RawMessage seems to vary pretty randomly – it can be anything from one to four, so I cannot choose a fixed number to pad to with zeroes. For a while I thought it was sufficient to simply pad to an even number of hex digits, and that works OK for some messages like handshakes, but now I'm receiving more lengthy filedumps and it's not working anymore and I don't see how to fix it without knowing the number of sysex bytes in each PortMidiEvent. Here's an example: Sysex data transmitted (data verified correct by MIDIMonitor utility): 00 40 00 42 00 00 00 01 00 (this is in the middle of a sysex filedump - I'm not showing the status bytes etc.) This is received as 3 PortMidiEventMBS structures. Here are the 3 received PortMidiEventMBS.RawMessage values after converting to hex using RealStudio's Hex() function which does not add leading zero characters: 4000 42 100 A string of hex bytes obviously needs to have an even number of digits so we pad the last one, giving us: 4000 42 0100 The hex bytes of a RawMessage have reversed time order, so after adjusting for that we have: 00 40 42 00 01 Which is wrong. Looking back at the original transmitted data we can surmise that the first PortMidiEventMBS actually carried three bytes and its RawMessage needed to be padded with leading zeroes to 00 40 00 The second PortMidiEventMBS carried two bytes and its RawMessage needed to be padded to 00 42 The third PortMidiEventMBS carried four bytes and its RawMessage needed to be padded to 00 00 01 00 Reversing the time order and concatenating these padded strings gives us the correct message of 00 40 00 42 00 00 00 01 00 The reason I suspect MBS and not PortMIDI is that the PortMIDI documentation (http://portmedia.sourceforge.net/portmidi/doxygen/structPmEvent.html#_details) clearly states: "A sysex message is encoded as a sequence of PmEvent structures, with each structure carrying 4 bytes of the message" If I could rely on each PortMidiEventMBS actually carrying 4 bytes then it would be very easy to pad the hex strings appropriately, but PortMidiMBS does not seem to implement a constant 4-byte pmEvent structure and I don't see how I can accurately reconstruct the sysex data without knowing how many bytes each PortMidiEventMBS carries." IIRC, Christian did not seem too interested in fixing MBS, I was working under an urgent deadline, and Mel Patrick (Hi Mel!) came to my rescue, sending me some sample code that got me started with WindowsMidi and Mac OSX midi classes. I would certainly be interested in an MBS-Midi sub-mailing list. I have learned a few things about Windows Midi that might be useful to others, especially if trying to do automatic device recognition, as my app does. As Mel says, under Mac OSX everything pretty much Just Works. Julia _______________________________________________ Mbsplugins_monkeybreadsoftware.info mailing list [email protected] https://ml01.ispgateway.de/mailman/listinfo/mbsplugins_monkeybreadsoftware.info
