DSI Mopho issues

Home Forums Platform Specific Linux DSI Mopho issues

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #10412
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    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)

    #10432
    bgribble
    Participant
    • Topics: 0
    • Replies: 6
    • Total: 6

    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.

    #10438
    bgribble
    Participant
    • Topics: 0
    • Replies: 6
    • Total: 6

    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.

    #10439
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    I reported this as a bug on the juce forums:
    http://www.rawmaterialsoftware.com/viewtopic.php?f=5&t=11612

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

    #10440
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

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

    #10442
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

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

    #10585
    bgribble
    Participant
    • Topics: 0
    • Replies: 6
    • Total: 6

    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.

    #10586
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    It’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 9 years, 1 month ago by atom.
    #10614
    bgribble
    Participant
    • Topics: 0
    • Replies: 6
    • Total: 6

    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!

    #10621
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

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

    #10632
    bgribble
    Participant
    • Topics: 0
    • Replies: 6
    • Total: 6

    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.

    #10635
    atom
    Keymaster
    • Topics: 159
    • Replies: 2945
    • Total: 3104
    • ★★★★★

    1479 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

    #48645
    zeoka
    Participant
    • Topics: 73
    • Replies: 466
    • Total: 539
    • ★★★

    Hi
    There is an issue with my brain not the mopho :
    i can’t figure how to compact them
    for me the dump data should have a 00 every 7 bytes but no. why ?
    edit
    ookkk that was bit not byte

    • This reply was modified 7 years, 2 months ago by zeoka.
    Attachments:
    You must be logged in to view attached files.
    #48884
    zeoka
    Participant
    • Topics: 73
    • Replies: 466
    • Total: 539
    • ★★★

    Hi 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 modulators

    MIDIrec = 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 😀

Viewing 14 posts - 1 through 14 (of 14 total)
  • The forum ‘Linux’ is closed to new topics and replies.
There is currently 0 users and 47 guests online
No users are currently active
Forum Statistics
Threads: 2,495, Posts: 17,374, Members: 77,605
Most users ever online was 12 on January 22, 2019 3:47 pm
Ctrlr