CueList Fader Steps Indexing

[sandinak]

We run a cue-d show where we have a cue-list with duration generally set to infinity, and have the operator press a "go" button, moving through the list and executing the scenes on the stage in time with music. I am using a second cue-list on this show that is driving Matrix's and keeps them flowing regardless of the first cuelist, for visual consistency.

RIght now I am using a loopback Universe, and sending the Next Cue via Scene that fires the corresponding DMX addr on the loopback U. I discovered the "Steps" option via the Side Fader, and its pretty cool allowing you to index WHICH cue'd item you want running; however it's not indexing via the ID number, but via a mathematical range based on (# of steps/256) . I can see where this is convenient for some uses; by allowing one to setup indexed scenes against that DMX address and select the item. The issue is if you add/remove an entry to the corresponding cue list .. the ranges will change and mess up the indexed scenes. I was wondering if there was a way to add an option this widget to index using the the ID# -> DMX Value vs a range.

Eg if I have U:Loop: Addr:1 as the fader, if I select

• 0 == No entry on th elist
• 1 == Index 1 on the list
• 14 == index 14 on the list
• any value over the last index # would just be the last indexed entry on the list.

This would make things much easier as I extend my second cuelist whilst building the show; I can generate the index scenes with some measure of confidence that what I think I am pointing at via the scene is indexed to the right place in the cue list.

[kproth]

Note - I've actually already implemented this, in a custom fork, for my personal usage.

*EXCEPT*, if a change is seen to a value of 0, I'm forcing that to mean "1" and selecting the first CueList step, rather than treating it as a "do nothing" input. Similar to if a change is seen to a value greater than the last step in the CueList, then it gets forced back into range and means to select the last CueList step... Would that be a problem in your case? [potentially, sending a fader value of 0 into the loopback universe already "does nothing"???].

I have not yet submitted a Pull Request to try and get it into the main upstream code set -- to be honest, I've been waiting for other users to try it and chime in if they think this is a useful addition first... But I have gotten a couple of users so far indicating they like it, so I am working on a bit more testing of my changes and will try sending them in when I'm ready.

I've previously posted about it:
here (viewtopic.php?p=69232#p69232)
and here (viewtopic.php?p=69298#p69298)
and most recently here (viewtopic.php?p=71047#p71047)

You can feel free to try my build from this past June; and if it would help to have a more up-to-date build let me know and I'd be happy to post a newer build with the same custom features.

Just note - if you try this, please realize it adds a new setting into the .qxw workspace file that would get lost if you opened it in the baseline version of qlc+ and then saved new changes. For one cuelist it would be easy enough to add that setting back again in the custom forked version.

[sandinak]

I would be interested .. I am on 4.12.7 right now .. and yea .. I understand how the file wouldn't keep the settings If you want to post when you get your update, i'd love to try it. Would change my world in more than a few ways in terms of sync between stage systems!

[kproth]

I re-built my customizations for v5 (on top of the latest 5.0.0-beta3 release) and for v4 (on top of the current v4.12.8 code).

They are both available from here if you want to give them a go:
https://github.com/kpr0th/qlcplus/relea ... 2023-12-31

[sandinak]

Heh .. went to test these this morning and realized .. your build is for Windows .. and I am a mac house. I've got a build env I've been trying to keep up.. will try to pull your tag and build here when I get done with this showfile. Thanks.