Forums › Forums › Qu Forums › Qu DAW integration › Qu MIDI specs
Tagged: MIDI, MIDI protocol, Qu
- This topic has 20 replies, 8 voices, and was last updated 10 months, 4 weeks ago by AudioMarsh.
-
AuthorPosts
-
2019/08/20 at 12:40 am #85941MikeParticipant
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.
2019/08/20 at 10:47 am #85943Alex A&HKeymasterHi Mike,
I’m sorry to hear that 🙁
I hope it gets sorted for you soon!
Alex
2019/09/21 at 4:00 pm #86612MikeParticipantAlex,
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 (https://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!
2019/09/22 at 9:07 pm #86621Alex A&HKeymasterHi 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!
Alex2019/09/24 at 11:19 pm #86641MikeParticipantAlex,
I can do that, but first I’ve found some issues with my buffer handling that I need to address first. I’d like to convince myself that I have no bugs on my end before I lodge an issue.
Mike
2023/12/27 at 12:06 pm #117846AudioMarshParticipantHi there, sorry if the answer to my question is buried in the technical stuff above. I have a qu-24, and I’m trying to control Pro Tools. Whenever I collapse folder tracks, the physical faders that were assigned to the now hidden tracks are reassigned to different tracks. This makes it really difficult to label the qu and get used to what channels/groups I’ll find on what faders… I’ve tried to experiment with MIDI Thru instead of the HUI protocol but I didn’t get very far! (there seems no generic midi protocol option in the peripherals dialogue!) Any pointers on where I might be failing would be greatly appreciated! TIA 🙂
-
AuthorPosts
- You must be logged in to reply to this topic.