ltjost
commented
3 years ago Most generically it should be developed so that Next and Prior Cues could be triggered for any interface...perhaps making a whole "cue" structure ... maybe name a cue sequence and then trigger next or prior "name" cue. In that way it would be well generalized through the entire tool. Every command could be tied to one or more Cue names... however, for my specific need, OSC would suffice. I could see "Execute Next LIGHT1 Cue" where the button for a Cue would have one or more CUE Names associated with it. That, however, would be a more complex undertaking, though it would be more versatile.
Julusian
Bitfocus Companion could be used to define as well as execute OSC commands as Cues without use of SCS or x32Tc. A button would be created for each "cue" set of OSC instructions. Two navigation buttons would be created. A user could press a specific button to jump to a specific cue...and then use the Prior and Next command buttons to move forward or backward in the cue set (each cue being defined as a botton). The OSC execution by Companion is super fast compared to x32tc and SCS tools and renders those tools unnecessary for sound mixer cue execution. For example, I now use a Behringer x32 and either use x32tc or SCS to develop and run cues...but I use excel and some javascript to build the SCS commands (see scs.workwebs.com). I could write a similar tool to generate the OSC commands in Companion XML or create them manually or just edit the Companion XML and then just run shows very effectively all from within Companion....with less complexity and fewer tools making this a less risky proposition. If the module could keep state info regarding which "cue" was last executed and which is first, then execute next and prior cue commands could operate to turn streamdesk and this emulator into an actual cue manager and navigation tool.