Module failing to send Midi out messages for certain actions.

[JoshDarnIt-All]

*** Means: Non-functional. No feedback in Debug/Log. Looks like there is no Outgoing Message.

Assign Channel to FX send - 
 Assign Channel to Group - 
 Assign Channel to Mix - 
 Assign FX return to FX send - 
 Assign FX return to Group - 
 Assign Group to FX Send - 
 Assign Group to MTX - 
 Assign Group to Mix - 
 Assign Mix to MTX - ***


Using Debug/Log I am not seeing any output from any of these actions. Will update the list as I find more.

[jswalden]

I sort of stumbled on this by happenstance, and I know what it is, and I probably have a fix -- once I can get back to a mixer to test it.

[jswalden]

This is fixed in f0f3df739750c558dffe2e97912b5bf3984cb35a. It seems all the multiple-selection options (corresponding to exactly the actions you list) were defined as

const opt = {
    type: 'dropdown',
    multiple: true,
    // ...
}

rather than

const opt = {
    type: 'multidropdown',
    // ...
}

and so the option value would be a single value rather than an array of them, with result that a for (let i = 0; i < mix.length; i++) loop to send a bunch of MIDI commands to perform the requested assignments would never execute because 0 < undefined would be false.

I can't figure out why these were all misencoded this way. I grunged through @companion-module/base type definitions multiple years back (and before Companion 3.0) and couldn't find a time when multiple-selection options were defined in this other format. It doesn't really matter, but do you happen to know anything about when this older pattern ended, @josephdadams? These actions must have worked at some point.

[josephdadams]

I really do not know. It is possible it never worked. I am not an SQ user - I just gave my best attempt to convert it to v3 for compatibility. I had a hard time understanding what all was going on!

[JoshDarnIt-All]

I have been testing most actions on version 3.3.1. I have 3 main notes that should give a jumping off point.

1. Any action involving what would be a midi message has no affect on the console, there is also no record of any midi message being sent out via the companion Log. Examples of these message types: Assign Channel to FX send - 
 Assign Channel to Group - 
 Assign Channel to Mix - 
 Assign FX return to FX send - 
 Assign FX return to Group - 
 Assign Group to FX Send - 
 Assign Group to MTX - 
 Assign Group to Mix - 
 Assign Mix to MTX - ***
 Etc.

2. Any message involving Levels is not affecting console as well. I have run into this error in the logs for every "Level" based action from the module: "24.08.08 10:52:20 Instance/Wrapper/SQMostRecent: Child is not running, unable to send message: {"direction":"call","name":"variablesChanged","payload":"{\"variablesIds\":[\"internal:time_hms\",\"internal:time_s\",\"internal:time_unix\",\"internal:time_hms_12\"]}"}"

I am unsure what "Child is not running" means.

3. All Midi Feedback from Console to Module seems to be funtional. Companion displays fader levels (though it is off by about 15db) and I can see current scene and whatnot. Feedback seems to be happy.

Hopefully this helps!

Had some personal stuff with a new baby and touring work going on, but back at home base and ready to test as needed to get this module functional!

[JoshDarnIt-All]

Mute commads are functional.

[JoshDarnIt-All]

As soon as we run a command with a level which results in the "Child is not Running" warning we lose all control of the module to the console and lose all feedback from the console to the Module.

Sorry for the choppy updates.

[josephdadams]

"Child is not running" means the module crashed. Sometimes you can see helpful info if you open the ">_" tab next to the SQ module in Connections, it opens what looks like a terminal output. However, sometimes it is not helpful, especially if it's just a long string of red obfuscated/minified code...

[josephdadams]

(All modules in Companion v3.x run as child processes independent of the main Companion process. In the prior versions, if a module crashed, it would often take down the whole Companion process with it since everything was shared.)

[JoshDarnIt-All]

@josephdadams @jswalden I decided to jump back to 2.4.2 to verify that these actions all worked. Every listed action is functional, and the Log is showing these outgoing Midi messages.

Something about 3.3.1 is blocking these outgoing messages.

Here is my log from my testing in 2.4.2 below.

[jswalden]

@JoshDarnIt-All I gotta be honest, the code of the module in the last released version -- present in Companion 3.0/3.1/3.2/3.3/etc. until such point as another release happens -- is such spaghetti that is so completely different from what I've massaged it into on trunk that I am totally uninterested in divining any minuscule signal might be present in its logging. :sweat_smile:

Every so often, I have had to fix a bug in code that was so byzantine that the only way I could do it, was to pull a little bit here, a little bit there, and only gradually massage it into submission. Sometimes it would be so bad that I couldn't even say at what point in the series of changes, the original bug was actually fixed. Or, if I could figure it out through some herculean effort, it would be a gross misuse of time to do so.

This module emphatically is in that state, in the last released version, given how much cleaner/clearer the code on tip is now.

Right now I'm down to roughly 300 lines of un-massaged code remaining in the module. (To a fair approximation I can count code that I've converted to TypeScript as "good", and code that's still JavaScript as "bad".) I really should just spin up a prerelease, that you can load as a developer module overriding the builtin one, and then let you test with that.