BUG - Thru Selection in certain Flexi states broken in 3.2.9

Are you saying that it looses the selection of channel 1 thru 4, and doesn't advance to channel 2? If that is the case, be sure to double check that those channels are actually patched. There was something similar someone brought up while working through some of the training videos, and it will exhibit unexpected "next" behavior when the next channel actually is not patched to a fixture.

Yes I am saying that it doesn't advance to channel 2. Yes, the channels are patched.

I've given a really clear replicator for the bug in this post. If you can't take the 30secs to try this out yourself and see it happen, please don't just stab in the dark and guess at a problem, it's really not a helpful response.

As I said, that was simply giving you a quick response because of something that sounded similar because I overlooked your statement about flexi.

But with that in mind, that appears to be expected behavior, if you look at the documentation for [Next]: (https://www.etcconnect.com/webdocs/Controls/EosFamilyOnlineHelp/en-us/Default.htm#07_Manual_Control/01_Selecting_Channels/Select_From_Keypad.htm?Highlight=next)

 "Note:  [Next] and [Last] work with the current flexichannel state. See Using Flexichannel 

As such, since presumably your channels that you selected via THRU were not manual, in use or active, that would be expected since the moment you set a value in channel 1, then the flexi updates to only the channels that are in that flexi state, and are then no longer accessible via next. 

Looking at the 2.9 user manual it says the same thing on page 174 at https://www.etcconnect.com/WorkArea/DownloadAsset.aspx?id=10737511480

However, if say you had manual data in channels 1 thru 4, and in flexi view manual, then it would work as I think you expect.

But than there is a much bigger Bug around here.
If the current Channels have no value at all, they should not be selectable in the current flexi-state.
At least not with a single [Thru]. [Thru][Thru] should always work.

If there is no Activ Channel in the Channel-selection the Single [Thru] will always work. And if there is at least one activ Channel in the selection, the behaviour is as expected of the Flexistate.

So maybe that is what the moderator is refering to (around since v2.6) ?

No, that's not a bug, of course you can select channels that are not in your current Flexi. The manual says: 

"[Thru] can be used to view only channels in the current flexi state (except for selected channels) as long as either the first or last channel in the [Thru] range is included in the current flexi state. To include channels not in the current flexi state, [Thru] [Thru] can be used."

The meaning of the text is not 100% clear for me, or rather the logic behind it is not comming to me 100% clear.
Even after translating it in my native Language.

But besides that, i get the main logic and the little reproducer from warrenl  is working as your quoted text says.

If warrenl  likes to have Ch 1-4 selected and likes to step trough a [Thru] [Thru]  is needed to make this special action possible.

IMO the quoted text doesn't mention Warren's specific case. The surprise seems to be that when using Next/Last the selection is re-evaluated rather than keeping the original selection with regards to its Thru/Flexi meaning.

IMO the quoted text doesn't mention Warren's specific case. The surprise seems to be that when using Next/Last the selection is re-evaluated rather than keeping the original selection with regards to its Thru/Flexi meaning.

I did some more testing both on 3.2.9 and 2.9.3 and found the following that might help narrow down the issue.

Configuration/State:

• Live Flexi Manual (no channels shown)
• Channels 1 through 5 patches, no manual data, at cue out.

Test 1:

• 1 thru 5 enter
• next at 5 (channel 1 at 50%)
• next (drops selection except for channel 1)

Test 2:

• 1 thru 5 enter
• next next next at 5 (channel 3 at 50%)
• next (works as expected, retains all 5 channels selected)

Test 3:

• 1 thru 5 enter
• next next next next next at 5 (channel 5 at 50%)
• next (different behavior between 3.2 and 2.9, but unexpected)

The biggest issue I see here is that the results are different based on which channel in the selection has a manual value set -- even first and last channel manual values result in different behaviors. 

I believe the "book answer" would be to use thru-thru in situations like this, which does work exactly as expected. 

However it would seem that the unexpected behavior of thru in flexi might be a bug.

Thanks for the deep dive on this guys.

We've always been able to make a selection outside of the flexi state with a single Thru, if the full range of channels being selected don't already exist within the Flexi. But, indeed, the 'surprise' is that the selection gets re-evaluated as you use it...I'm really quite confident that this has changed very recently (maybe only in 3.2.9?).

The issue is that the syntaxed selection is being forced out - which is actually quite dangerous when you take this example further. Because in an Active Flexi state, what is happening is that the selection gets dropped and it will then 'next' to the next 'active' channel!

EG - Flexi Active - in a random cue. I grab a selection of channels none of which are active - to flash through some practicals = 1 Thru 10 Enter - Next Shift Full - Next - suddenly my 'next' will bounce to another channel that's not in my original selection and flash that to full - potentially that's a smoke machine, or a strobe or a 10k pointing at someone, or who knows what and suddenly I'm flashing it full - it's definitely the desk doing something that I haven't asked it to do, and that's not okay. 

To be clear, I'm not asking for the thru and thru thru selection process to change, I fully understand how that works. It is that this has changed from how it's been working for many years, and now the software is doing something outside of what I'm asking it to do. If I specifically put a thru range in my selection, that should be all that it is dealing with.