Home › Forums › Platform Specific › Linux › DSI Mopho issues
- This topic has 13 replies, 3 voices, and was last updated 8 years, 10 months ago by zeoka.
-
AuthorPosts
-
June 27, 2013 at 8:59 pm #10412
It looks like JUCE splits large sysex midi messages into blocks (anything larger then 256 bytes). This causes Ctrlr to get confused about what’s going on, until a fix inside JUCE is made this panel won’t do program dumps, unless
someone knows how to change the ALSA buffer input size via /proc or /sys (i couldn’t find any info), maybe at driver level while “modprobe” for the MIDI device, or maybe someone know what call to do when opening the MIDI device (JUCE uses snd_seq* calls to do MIDI)
June 28, 2013 at 5:55 pm #10432I 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.
June 28, 2013 at 8:55 pm #10438I 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.
June 28, 2013 at 9:18 pm #10439I reported this as a bug on the juce forums:
http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=11612Here the identity request is working fine, but i changed some stuff over the last days, if you’re building from source, try to update the svn and see if that helps at all.
I also added a Code::Blocks project for Linux in the Standalone directory, it’s helpful for debugging.
June 28, 2013 at 9:23 pm #10440I can add some code to join those pieces together but i’d have to make it platform specific and i really don’t want to do that.
But unless there is a fix in JUCE i’ll do that in Ctrlr.
June 28, 2013 at 10:11 pm #10442Ok so i made a small patch to the Ctrlr code enclode in some ifdef JUCE_LINUX code.
It should append the missed midi data and pass it to the panel.
I also added the DSI Mopho panel to the Panels directory in SVN (it has minor tweaks nothing fancy).
I didn’t update the linux builds, if anyone needs that (not building from source), let me know.
July 3, 2013 at 4:58 pm #10585Looking 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.
July 3, 2013 at 5:12 pm #10586It’s weird, that dump works (at least the name part) on windows,
can you paste this code in the Lua Console and see what results you get:
data = MemoryBlock ("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 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") console ("size: "..data:getSize()) unpacked = utils.unpackDsiData (data:getRange(4,293)) console ("unpacked size: "..unpacked:getSize()) console ("name: "..unpacked:getRange(184,16):toString())
I get something like (this is on Windows built with gcc-4.7 MINGW):
size: 298 unpacked size: 256 name: RandomStepper
- This reply was modified 10 years, 9 months ago by atom.
July 4, 2013 at 5:51 pm #10614For 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!
July 5, 2013 at 12:18 am #10621I changed those functions to return pointers to dynamicly allocated data, see if that fixes the issue.
Also i’d like to know what compiler you are using that it’s failing, i’d like to be able to re-create it so i can test some other calls that might be failing, and fix them.
July 5, 2013 at 3:27 pm #10632I 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.
July 5, 2013 at 4:04 pm #106351479 is correct but the new code is
return (new LMemoryBlock ((uint8 *)unpacked.data, unpacked.size));
that’s what i got and what i see on sf.net
May 31, 2015 at 11:11 am #48645June 2, 2015 at 12:33 pm #48884Hi i reactivate instead of create new one
i attempt to do custom method and i get trouble with memory blocks
for now i know why dsi does that but difficult to set modulatorsMIDIrec = function( midi) local MIDdta = midi:getLuaData() local PC = MIDdta:getByte(0) if PC == 192 then local pcVal = MIDdta:getByte(1) panel:setPropertyInt("panelMidiProgram",pcVal) PnlBkg:repaint() end if PC == 240 then if MIDdta:getByte(1) == 1 then if MIDdta:getByte(2) == 37 then if MIDdta:getByte(3) == 3 then local Edit = MemoryBlock(MIDdta:getRange(4,293)) local Read = MemoryBlock() for t = 0,288,8 do if t == 0 then w = 0 else w = (t/8)*7 t = t -1 end console("t"..t) console("w"..w) y = BigInteger(Edit:getByte(t)) for a = 1,7 do u = y:getBitRangeAsInt(a-1,1) f = BigInteger(Edit:getByte(t+a)) f:setBitRangeAsInt(7,1,u) Read:insert( MemoryBlock(f:getBitRangeAsInt(0,8)),1) end end console("read:"..Read:toHexString(1)) panel:setPropertyInt("panelMidiPauseOut",1) for t = 0,104 do-- panel:getModulatorWithProperty("vstIndex",t):setModulatorValue( Read:getByte(t),false,false,false) end for t = 120,183 do --panel:getModulatorWithProperty("vstIndex",t-15):setModulatorValue( Read:getByte(t),false,false,false) end panel:setPropertyInt("panelMidiPauseOut",0) end end end end
the console is writing :
t0 w0 t7 w7 t15 w14 t23 w21 t31 w28 t39 w35 t47 w42 t55 w49 t63 w56 t71 w63 t79 w70 t87 w77 t95 w84 t103 w91 t111 w98 t119 w105 t127 w112 t135 w119 t143 w126 t151 w133 t159 w140 t167 w147 t175 w154 t183 w161 t191 w168 t199 w175 t207 w182 t215 w189 t223 w196 t231 w203 t239 w210 t247 w217 t255 w224 t263 w231 t271 w238 t279 w245 t287 w252 read:
if i do : Read:insert( MemoryBlock(f:getBitRangeAsInt(0,8)),1,(a-1)+w)
then ctrlr crash and i must remove that in the XML panel file
also i tried : local Read = MemoryBlock(256,true or false )
tried to replace loop stuff by Read = utils.unpackDsiData (MIDdta:getRange(4,293))
and crashed too
SOLVED 😀 -
AuthorPosts
- The forum ‘Linux’ is closed to new topics and replies.