Possible bug with 17.4.2 related to colour fade on Playbacks

[delicolor]

We just noticed a change of behaviour with 17.4.2 on our FLX that impacted somewhat on a show at the weekend. We have been running the software since December but most of the shows are with passive states on the four multi-function keys so a bit of busking by the Boss at the weekend raised the issue. (I had done my usual functional regression testing of course).

We don't use the stack- we busk the shows on the playbacks as our venue is an Organ heritage centre and it is rare that visiting Organists give us an accurate set list. (Or even the resident Organists for that matter!)

We have a bank of ten playbacks that control four Elumen8 MP75 RGBW fresnels, used to light the console sides. Each fader has the four lanterns at 100% with various colour groupings. For historical reasons going back to Frog days the volunteers worked out that you only needed one fader up and pressing the button on any of the 9 other faders would give a smooth fade to the new colour state. It didn't matter if the state was already LTP triggered with the blue box on the monitor, you still got the smooth colour transition. It left the board in a bit of a mess LTP-wise but didn't impact the lights between simple shows.

However, the Boss was surprised to see that sometimes pressing a button resulted in a snap colour change and it was unpredictable (to him) whether it would snap or fade. Yesterday I quickly realised that if a playback had already been triggered previously, selecting it again whilst still highlighted caused the colour snap.

Rolling back to 17.4 showed it was the software rather than the showfile. The release notes for 17.4.1 mention ZOS-8696 which is related to playback trigger & release so that is the likely culprit. I don't know if it is a bug or an unintended consequence but would appreciate a workaround if possible. (I never worked out if the ZOS reference body text was accessible to users).

I can provide a showfile on request but in the meantime I will create a simple show on Phantom to duplicate it at home.

[Edward Z88]

Hi @delicolor

1 hour ago, delicolor said:

We have a bank of ten playbacks that control four Elumen8 MP75 RGBW fresnels, used to light the console sides. Each fader has the four lanterns at 100% with various colour groupings. For historical reasons going back to Frog days the volunteers worked out that you only needed one fader up and pressing the button on any of the 9 other faders would give a smooth fade to the new colour state.

To achieve this behaviour, these playbacks would need their buttons configured to "Go (Fade)" behaviour, rather than the default flash behaviour.

1 hour ago, delicolor said:

sometimes pressing a button resulted in a snap colour change and it was unpredictable (to him) whether it would snap or fade. Yesterday I quickly realised that if a playback had already been triggered previously, selecting it again whilst still highlighted caused the colour snap.

With the playback buttons configured as Go buttons, I am unable to replicate this behaviour. Even if a playback has already been triggered, the playback's GO button can still be used to go into the cue again, and therefore fade the fixtures to the recorded values.

Please ensure that Fader Controls Colour is not enabled on these playbacks. If it is, the cue colour fade times of these playbacks will be ignored upon pressing their GO buttons.

1 hour ago, delicolor said:

Rolling back to 17.4 showed it was the software rather than the showfile.

This is very interesting to hear that you saw different behaviour in ZerOS 7.14. This behaviour should not have changed between ZerOS 7.14 and ZerOS 7.14.2. Please email a copy of the show file to support@zero88.com, to allow us to investigate further.

1 hour ago, delicolor said:

The release notes for 17.4.1 mention ZOS-8696 which is related to playback trigger & release so that is the likely culprit. I don't know if it is a bug or an unintended consequence but would appreciate a workaround if possible. (I never worked out if the ZOS reference body text was accessible to users).

ZOS-8696 is specifically related to triggering/releasing playbacks from a cue macro. This is not related to triggering/releasing playbacks manually using playback buttons.

Our "ZOS" system is not public, but we do provide reference numbers for tracking purposes.

1 hour ago, delicolor said:

I can provide a showfile on request but in the meantime I will create a simple show on Phantom to duplicate it at home.

That would be great if you could. Thanks very much.

[delicolor]

Hi Edward, thanks for your fast response. I have duplicated the different behaviour on Phantom Zeros, I had 17.4 installed and the expected actions took place, I then upgraded to 17.4.2, the snap colour changes were taking place as described, as observed on the DMX output. I'll send the showfile over before doing default testing in case it is an interaction of another setting.

[delicolor]

I've sent the file. I created a new file from factory reset Phantom 17.4.2 with one MP75, recording three cues on playbacks with primary colours & setting buttons to Go(fade). Frustratingly it is working perfectly normally!

There is presumably something a bit more obscure going on and hopefully you can get to the bottom of it. Having worked in software support a long time ago I remember that actually duplicating the issue is often half the battle...

[Edward Z88]

1 hour ago, delicolor said:

I've sent the file. I created a new file from factory reset Phantom 17.4.2 with one MP75, recording three cues on playbacks with primary colours & setting buttons to Go(fade). Frustratingly it is working perfectly normally!

There is presumably something a bit more obscure going on and hopefully you can get to the bottom of it. Having worked in software support a long time ago I remember that actually duplicating the issue is often half the battle...

Thanks very much for emailing your show file. For reference, this has been logged as ZOS-11991.