[bgribble]

I use gcc/g++ 4.8.1 on Debian.

Did you commit your changes? Rev 1479 is what I get from SVN, and packDsiMidiData/unpackDsiMidiData still return a pointer to the local array “data”, which is on a part of the stack that gets popped when you return it. By the time you get to the “new LMemoryBlock” in CtrlrLuaUtils::[un]packDsiData, that part of the stack may already have been reused.

[bgribble]

For anybody following this — there are some issues with packing/unpacking the sysex data which are causing problems on Linux. The bug is there in Windows too but for whatever reason it only causes problems on Linux.

I have a patch locally which I’m going to clean up to submit for Atom’s review. With it applied, I can successfully request the Edit Buffer from the Mopho, it loads correctly in the panel, and editing works both directions. Whee!

[bgribble]

Looking at the SVN Mopho panel on Linux, built from svn r1477 source, I can “Request identity” and get the Mopho firmware rev (1.4) but “Request Edit Buffer” doesn’t get the current program data.

If I load the factory preset from Bank 1 / Program 1 (“RandomStepper”, which is ASCII 52 61 6e 64 6f 6d 53 74 65 70 70 65 72) the RAW log data displays:

MOPHO: mophoRequest RequestEditBuffer
MOPHO: 	edit buffer
 RAW:[f0 01 25 06 f7]
 RAW:[f0 01 25 03 00 3c 31 02 00 01 7f 18 00 33 39 00 01 01 01 00 00 02 0c 04 54 00 00 57 00 50 00 7f 01 7f 00 00 00 00 00 00 6a 00 40 40 00 00 00 00 7f 61 3d 52 00 04 1d 01 00 08 00 7f 00 01 01 08 00 7f 01 01 00 0b 00 1d 09 00 00 7f 00 00 00 00 00 00 00 00 12 05 02 0d 08 0a 0d 14 00 7f 01 14 7f 09 60 09 51 6c 12 2a 0a 23 09 7e 00 05 30 64 00 78 02 00 00 00 00 00 01 02 09 00 00 4d 12 2e 17 00 00 00 00 00 00 00 00 00 07 3c 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 52 61 6e 64 6f 00 6d 53 74 65 70 70 65 00 72 20 20 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00]
 RAW:[00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f7]
MOPHO: mophoProcess
MOPHO: 	edit buffer
MOPHO: 	response size:298
MOPHO: 	unpacked size:256

So you can see the program name embedded in the data, with the weird bit of the 00 embedded every few characters… but ctrlr shows junk for the name, and the controller values don’t get set to the patch values. If those 00 in the name are extras added by JUCE or ALSA, and they appear elsewhere in the dump as well, all the offsets would be wrong and that would explain this behavior.

[bgribble]

I tried patching juce_linux_midi.cpp to set the input pool size as described above. I have enough debugging to see that the code is being executed, yet the RAW midi logs still break up the “get edit buffer” response into a 256-byte block and a “leftover” block, so the pool size does not do what I thought.

It’s worth noting that the “Request identity” command also reports a timeout, and its sysex response is just 14 bytes including the sysex start/stop bytes, so multiple blocks is not necessarily the only problem here.

[bgribble]

I think you meant to say that ALSA splits SysEx messages into 256-byte chunks. That’s true.

I can’t verify this for sure, but the ALSA API call snd_seq_set_client_pool_input purports to set the input buffer size for the ALSA sequencer. If you google for uses of it, typical argument value is 1000, indicating that others have problems with a default of less than 1000. Could very well be the ticket…

Or, you could just reassemble the sysex from multiple blocks, looking for the end-marker byte to know you are finished. More “correct” but more work.

[bgribble]

I am really slobbering for this Mopho panel. After getting a taste with the old panel, the idea of being able to pick apart the presets and learn from them under Linux is just too exciting. Thanks for all the work!

[Author]

Posts