Rev 1193 MidiMessage Issue

Home Forums General News and releases Rev 1193 MidiMessage Issue

Viewing 18 posts - 1 through 18 (of 18 total)
  • Author
    Posts
  • #5245
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    There seems to be a problem with midiMessage:getData():getRange

    The data I get with with midiMessage:getData() is “f0 41 10 6a 12 03 00 00 00 42 72 61…” (Correct)

    But if I use midiMessage:getData():getRange(00,77)

    The message I get is “b0 c9 cd 03 3e 00 00 00 5b 31 38 3a…” (Wrong)

    It should be the same data

    #5246
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    I see what happens, look at the sequence:

    >>> console(“”..PatchCommonSyx:getRange(0,1):toHexString(1))
    f0 f0
    >>> console(“”..PatchCommonSyx:getRange(0,2):toHexString(1))
    b0 2e f0 41
    >>> console(“”..PatchCommonSyx:getRange(0,3):toHexString(1))
    a0 07 22 f0 41 10
    >>> console(“”..PatchCommonSyx:getRange(0,4):toHexString(1))
    50 17 45 04 f0 41 10 6a

    The bold data is correct, but for each correct byte, another byte is added at the beginning of the message

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

    Here is my method:

    myMethod = function(mod, value)
    	midi = CtrlrMidiMessage({0xf0,0x41,0x10,0x6a,0x12,0x03,0x00,0x00,0x00,0x42,0x72,0x61})
    	console ("---------- snip")
    	console(midi:getData():getRange(0,1):toHexString(1))
    	console(midi:getData():getRange(0,2):toHexString(1))
    	console(midi:getData():getRange(0,3):toHexString(1))
    	console(midi:getData():getRange(0,4):toHexString(1))
    	console ("---------- snip")
    end
    

    and the output from LUA

    LUA>> ---------- snip
    LUA>> f0
    LUA>> f0 41
    LUA>> f0 41 10
    LUA>> f0 41 10 6a
    LUA>> ---------- snip
    

    Looks ok to me i’d need a complete example.

    #5256
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    Your example in an empty panel
    ---------- snip
    f0 f0
    48 db f0 41
    38 dc bd f0 41 10
    c8 14 4b 06 f0 41 10 6a
    ---------- snip

    #5257
    Llamatron
    Participant
    • Topics: 7
    • Replies: 27
    • Total: 34

    I got a similar issue, it’s what’s causing my sysex dump problem I mentionned in another thread. After

    programData = midiMessage:getLuaData():getRange(5,51)

    where midiMessage is a 57 bytes long midi message, programData displayed with

    console (programData:toHexString(1))

    is aproximately twice as big and got some seemingly random numbers as the exact same sysex data results in different numbers.

    #5259
    msepsis
    Participant
    • Topics: 219
    • Replies: 732
    • Total: 951
    • ★★★

    I’ve had to stick with 1184 here as with anything later than that my program names are displaying as numbers 0-9 with the method I had gone with (value 32-127 combobox per letter) to display program names on my panel.

    I haven’t had the bandwidth these past few days to narrow the cause down but maybe it’s related. I’m sure theres a better way these days to display a program name in ctrlr anyway.

    Then again probably some of the stuff I haven’t been able to get working (that should!@$) in 1184 could be due to something wrong in 1184 🙂

     

    If anybody has any tips on the combobox displaying 0-9 instead of the ascii characters I have assigned in the combo contents (32-127) let me know, otherwise I’ll try narrowing that down later possibly all completely unrelated to the aforementioned midiMessage reports but since we’re talkin 1193 here thought I’d add my 1 1/2 cents.

     

    ahhh.. another friday night of nice quiet coding 🙂

    Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

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

    I can’t think of a reason why this is happening. Is this the 64 or 32 bit build of Ctrlr ?

    #5261
    dasfaker
    Keymaster
    • Topics: 80
    • Replies: 793
    • Total: 873
    • ★★★

    XP 32 here

    #5262
    Hecticcc
    Participant
    • Topics: 25
    • Replies: 160
    • Total: 185
    • ★★

    I can confirm the ascii bug,  all characters that have values coming from an incoming hex-message are acting up. Instead of all characters i sometimes see one character being displayed, and stepping up and down the values produces different characters for the same values.

    Internally updated messages (ie value comes from a modulator, not midi-in) work correctly.

     

    I also get strange behaviour from a script that works in 1183, it looks like ctrlr makes an internal midiloop with a 3-byte message, and the timestamp is a negative value …

     

    *edit*

     

    win 7 ultimate 32bit bare install

    • This reply was modified 9 years, 5 months ago by Hecticcc.
    • This reply was modified 9 years, 5 months ago by Hecticcc.
    #5265
    msepsis
    Participant
    • Topics: 219
    • Replies: 732
    • Total: 951
    • ★★★

    32 bit winXP here. If I get a chance today to look at what was going on through midi monitor vs what should be going on I’ll follow up. definitely something screwey and it was noticeable immediately after receiving the first dump from the synth to the panel – however the waveforms from wavetables were drawing perfectly fine to a uiCustomComponent ..

    when i get a chance i’ll follow up with more detail.

    Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

    #5271
    Llamatron
    Participant
    • Topics: 7
    • Replies: 27
    • Total: 34

    64bits Windows 7 here, and I confirm the bug is in getRange as removing it results in the values being where they’re expected

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

    I’ll work on that issue ASAP, possibly tomorrow or friday. I’m at home for christmas and without access to any decent computer to code. I’m aware of the problem and will try to fix it. Please be patient.

    #5287
    msepsis
    Participant
    • Topics: 219
    • Replies: 732
    • Total: 951
    • ★★★

    Thanks atom, take your time man. I’ve got plenty to work on and 1184 is working for me… mostly.

    On that note i’ve already reported the details in a PM to atom along with some example panels, but be careful when saving to .panel files in 1184. I’m not completely sure how the heck it happened but one of my panels lost ALL of it’s Lua scripts after saving incremental .panel files from ctrlr 1184. I was experimenting with some things so maybe I pushed it too far but everything was working just fine while in ctrlr, until i crashed and went to open any of the panels I had saved during that 3 hour session – none of them contained any Lua. The most recent file i had saved that worked ok was a bpanelz file, so take that for what its worth.. For me, I’m just saving to bpanelz not .panel) and closing/restarting ctrlr after making any progress I want to ensure does not get nuked.

    It wasn’t the end of the world (was just experimenting, bug testing and making minor tweaks) but want to save anybody else the trouble if it’s something that can be reproducible.

    Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

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

    I still can’t reproduce this, i tested it with program dumps from my DSI MOPHO. Anyway can someone paste the entire data path, that is from the creation of the data object until the data you are fetching is wrong. When is the MemoryBlock object created (if ever), how it’s created, or is it just data from an incomming MIDI message in the method that’s called on every incomming midi for the panel.

    I’m also uploading another build just to make sure that everything is built correctly it has a number 1194. It’s possible i screwed up something during buildtime. Please let me know.

    • This reply was modified 9 years, 5 months ago by atom.
    #5291
    msepsis
    Participant
    • Topics: 219
    • Replies: 732
    • Total: 951
    • ★★★

    I’ll try to follow up with what you’re asking for later this eve when I’m next to synths. How many bytes does the DSI morpho’ program dump contain?

    For me, it seemed the first 100 or so modulators by index were correct on the panel after the first program dump (from the synth to the panel), the rest were fubared.. each additional program dump seems to “get worse”, by the fourth or fifth dump to the panel every modulator was WAY off.

    • This reply was modified 9 years, 5 months ago by msepsis.

    Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

    #5295
    msepsis
    Participant
    • Topics: 219
    • Replies: 732
    • Total: 951
    • ★★★

    Wow. Yeah, for me, here the issue is resolved. And then some.

    Atom. I no longer need to re-request the first 256 byte dump after 30 seconds idle time. Whatever that hitch that’s been there since like rev 600 is gone.

    • This reply was modified 9 years, 5 months ago by msepsis.

    Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

    #5297
    msepsis
    Participant
    • Topics: 219
    • Replies: 732
    • Total: 951
    • ★★★

    Apparently not able to edit my earlier posts at the moment(weird), so… that old 30 second idle bug is still there contrary to what I seemed to find initially. I must have only waited 29 seconds to change patches or something.

    Regardless, the good news is this version is fully usable for me, any ascii character bug is gone, program and other data dumps from the synth are coming in properly and my custom components are no longer drawing star maps… which is a good thing, although that did look cool as hell.

    • This reply was modified 9 years, 5 months ago by msepsis.

    Monstrum Media | Music, Sound & Software Design, Chicago / San Francisco listen

    #5300
    Llamatron
    Participant
    • Topics: 7
    • Replies: 27
    • Total: 34

    I confirm that my getRange bug seems gone

Viewing 18 posts - 1 through 18 (of 18 total)
  • The forum ‘News and releases’ is closed to new topics and replies.
There is currently 0 users and 35 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