Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Tim Weaver]

I haven't watched the whole thing...yet (it's playing in the background as a type)...but can anyone confirm if this is the first true way to have a completely redundant QL/CL system? I could see applications for this with two consoles sitting in immediate proximity of each other (with shared inputs via analog split or dante) simply acting as a primary and backup.

I suppose you could. Basically Andrews program takes all the moves from your master console and sends it via midi commands to the receive console. If both of those desks were running the same inputs and outputs they could be be running redundant audio. The control messages don't care about audio. Both desks could be running audio through them.

The caveat is that the master desk won't show meters from the remote desk. But if it's running redundant audio the master desk will have its own meters jumping, but it will not coincide with what the remote desk is doing. Won't be a problem if they are sharing a stage box, but if the stage boxes are also redundant then you'll have to be careful about metering.

[brian maddox]

I haven't watched the whole thing...yet (it's playing in the background as a type)...but can anyone confirm if this is the first true way to have a completely redundant QL/CL system? I could see applications for this with two consoles sitting in immediate proximity of each other (with shared inputs via analog split or dante) simply acting as a primary and backup.

It was possible before this to use MIDI to have two CL5s mirror one another, but you were limited by the MIDI protocol wrt distance between consoles, etc. There was also no simple way to synchronize the two consoles together. This solution removes those limitations along with providing a way to add Editor functionality to either console. This makes having a redundant console for FOH located back stage wherever there might be space not just possible, but easy. It also allows for some very interesting solutions to COVID challenges.

The germ of the idea was "I want to do what I can do with MIDI between two consoles but do it over the internet". Andy has taken that idea and run with it, allowing significantly more functionality in the process. It really is a cool thing.

[Miguel Dahl]

This is correct. Screen changes on the local console do not change the screen on the remote console and vis versa. This is because screen changes do not generate messages that are sent outside the console. This is true whether you are changing screens with touch screen buttons, or if you're using UDKs to do the same thing.

This falls squarely under the "it's both a bug AND a feature" category. For remote training you'd probably rather have your local screen change the remote screen as well so that your student is seeing exactly what you are doing without needing to do any input on their own. But if you're doing a "two people controlling one console" thing, then this is exactly what you want so that both people can work independently on their own control screen.

I intend to use this tool for training and will likely just include in my workflow ways to have my students push the correct buttons to ensure that they are on the same screen as me and therefore creating muscle memory [as well as making sure they're tracking with me]. I may even just use custom UDK layers so I can just say "push UDK 7 and you should see" whatever I want them to see.

That's a good point. Instead of just having the popup-window you recall on end pop up on their screen, it seems like it's more value to actually have them go in and find the window you'll operating in.

[ProSoundWeb Community]