Qu MIDI specs

Forums Forums Qu Forums Qu DAW integration Qu MIDI specs

This topic contains 18 replies, has 7 voices, and was last updated by Profile photo of Alex A&H Alex A&H 2 hours, 30 minutes ago.

Viewing 4 posts - 16 through 19 (of 19 total)
  • Author
    Posts
  • #85941
    Profile photo of Mike
    Mike
    Participant

    Alex,

    Thanks for the help. It will be a while before I get any answers – a power outage blew my UPS, motherboard, and boot disk, which contained the source code. Fortunately, 99% of the source code is in git in the cloud, but that last 1% was hard-fought work.

    The Qu-SB survived unscathed. So there’s that.

    #85943
    Profile photo of Alex A&H
    Alex A&H
    Keymaster

    Hi Mike,

    I’m sorry to hear that 🙁

    I hope it gets sorted for you soon!

    Alex

    #86612
    Profile photo of Mike
    Mike
    Participant

    Alex,

    Apologies for the lengthy delay on your firmware update request. A power outage took out most of my dev computer’s RAM, and unfortunately, the system drive which also had my code on it (most is committed to bitbucket). But unfortunately, the last bit of code not committed was the code that was parsing the sysex/nrpn data. So after a big delay and expense to recover my code, I’m back up and running. Update…

    I checked and verified that I was running v1.94.4557, so I updated to v1.95.4561, which on the website is the latest version. I don’t think the update made much of a difference. I dug deeper into the sysex/nrpn data coming back, and found a fairly consistent anomaly – in the middle of the nrpn dump, I would get this chunk of data, which of course is throwing off my parsing algorithms:

    0xd 0xa 0x20 0x65 0x74 0x73 0x20 0x4a 0x61 0x6e 0x20 0x20 0x38 0x20 0x32 0x30 0x31 0x33 0x2c 0x72 0x73 0x74 0x20 0x63 0x61 0x75 0x73 0x65 0x3a 0x31 0x2c 0x20
     CR  LF       e    t     s         J    a   n               8              2   0    1     ,    r    s   t          c    a    u    s    e    :    1   ,
    
    0x62 0x6f 0x6f 0x74 0x20 0x6d 0x6f 0x64 0x65 0x3a 0x28 0x33 0x2c 0x37 0x29 
     b     o    o    t         m    o    d    e    :    (    3   ,    7     )  
    
    0xd 0xa 0xd 0xa 0x6c 0x6f 0x61 0x64 0x20 
     CR  LF  CR  LF   l   o    a     d      
    
    0x30 0x78 0x34 0x30 0x31 0x30 0x30 0x30 0x30 0x30 0x2c 0x20 0x6c 0x65 0x6e 0x20 0x31 0x33 0x39 0x36
      0    x   4    0    1    0    0    0    0    0    ,          l    e    n         1    3    9    6

    I’m receiving only the hex values, but here I’m showing their ascii equivalents. Does this data make any sense to you? Ever had this happen before?

    Full disclosure, I’m coding this TCP driver on an Espruino WiFi microcontroller (http://www.espruino.com/WiFi), and of course I could be causing data loss/corruption on my end, but it’s just not obvious to me where the problem lies yet. Any thoughts on this are greatly appreciated. Thanks!

    #86621
    Profile photo of Alex A&H
    Alex A&H
    Keymaster

    Hi Mike,

    Please forward this in a ticket at support.allen-heath.com and I will take a look at what this is on my system.

    Thanks!
    Alex

Viewing 4 posts - 16 through 19 (of 19 total)

You must be logged in to reply to this topic.