I am not a coder so I am unable to help with my request, but I would love if there was MSC support in the Generic MIDI Module. Again I am not a coder so if this is a large request I understand why it has not been implemented yet.
Nonetheless, I really enjoy the MIDI module and are grateful for all the great work that has gone into said module!
Well, I never implemented it mostly because it’s just sysex, which the module can already do, and TBH, nobody ever asked!
Added it in v2.2.0, so give it a try and let me know if it works for you! https://discourse.checkcheckonetwo.com/t/latest-v4-v5-modules
Good to know! I tried using Version 2.2.0 but it didn’t work for me. When I installed it on version 5.0.7 it doesn’t connect, shows the red triangle and says “Incompatible module version
Please check the logs for more information.” The logs don’t say anything though. Trying to revert Companion to Version 4.x.x lets the module get to the yellow triangle, but also has no logs and wont let me pick the midi interface.
Did I potentially install the module incorrectly? Thank you!
I downloaded the module and am getting no errors. The screenshot you sent doesn’t show any problems either.
If you’re still having trouble, please grab a screenshot of the error and export the log so I can have a look.
Here’s a screenshot of my connections page and the logs page. It won’t let me make the connection and just says “incompatible module version check the logs” but the logs show no info.
Cycling the connection shows the following error in the logs “26.10.29 17:25:20 Instance/ProcessManager: Module Api version is too new/old: “New-Midi” 2.2.1”
Unfortuently, same Module Api version error in logs, but I can do more playing around with it tomorrow to see if different versions of companion/computers will work.
Argh. I’m sure it would work with the latest companion beta, but I’ve downgraded the module so it should work with older versions of companion.
Please download 2.2.1 when you get a chance and try it.
I tried redownloading the module as it seems to be the same one as yesterday, but on a positive note updating companion to the beta version allows it to work.
Upon playing around with the module I noticed some interesting things, the command data hex string isn’t the full string. If I receive a 3 digit msc value I only see the 10s place digit. Thankfully you also provide the “MSCMessage” variable so I’m able to use an expression variable to parse it from there.
I have to do some testing with msc as it’s my first attempt at supporting it.
Do you know of a simple Mac app that generates MSc messages so I can fully test it?
Also, do you have an example of a message that isn’t showing the complete hex?
Ah upon diving a bit deeper I see what was going on, at least in this example the mscData also includes 0x00 0x31 which is null 1 for cue list 1. The online hex to string converter wasn’t very good and just showed it as “0.511” when I remove the 0x00 0x31 it shows up correctly as “0.51”.
(There was also some user error of the converter being set to convert from hex to ascii instead of hex to unicode which threw some weird errors.)
Selfishly I would love if the variables displayed as go instead of 1 for command, and then separated message and cue list but I’m not too familiar with the MSC message formatting and aren’t sure if there are other applications where its not the same formatting as EOS messages.
I’m not sure I understand. When I send a “go” command, I see this in the log: [000.00] Received: msc Message, device: 127 (0x7f), format: Lighting (General) (0x01), command: GO (0x01), data: 1 0x00 1 from "IAC Driver Bus 1"
Which does include the command “Go” in the log.
Is that what you want to see in a variable? Maybe let me know more about what you’d like to see.