Latest ZerOS: simple playback fade?

[nbaldwin]

Since updating our LF96 to ZerOS (the number isn't in front of me but we've gone from old submasters to new Playbacks) we are still not able to program even the most simple functions such as intensity fade onto the playback faders. It works with our generics but won't work with either our Mac 250s/550s or our LED parcans (RGBA). I don't know if we are fundamentally not 'getting' how the new playback faders work or something is just wrong.

For example. If we home all of our Mac movers so that they are all in their home positions with full intensity, then pull down the intensity of them all to 0 and save that as a cue in playback 0, if we then (after Clearing) select the movers again, bring their intensity to max and then save this state onto a playback, we're expecting to be able to control the intensity of all of our movers with the playback fader. This does not happen. Even though you can see in the Output window that the intensity parameters have been tagged for saving (at 100), when you move the playback fader all that happens is that the 0 intensity stays at 0 but has a light grey box around it. I presume that's telling us something but we have no clue what. And more importantly, we don't know how to resolve that so that it does what we expect (fade the movers intensity between 0 and 100).

We've had this problem ever since updating (probably a year ago) and have literally stopped using Playbacks except for Chases, which do work fine.

Any hints, tips or pointers in the right direction would be a huge, huge help right now. We'd setup some parcan uplighters for a show this weekend hoping to put the RGB controls on playbacks for some quick way to make some colour variations on the fly but after a frustrating rehearsal last night when we just couldn't get it working (as described above) we gave up with playbacks. Again.

Thanks,

Neil

[Edward Z88]

Hi Neil,

Out of interest, why are you recording a cue with the fixtures at 0% on the Master Playback? If you home your fixtures, tap RECORD, and then tap a playback button, the lighting state will be stored. Double pressing CLEAR, and then raising the playback fader will raise the intensity of the fixtures. 

If this is not the behaviour you are getting, it sounds as if a setting has been altered. To check the settings for your playback, hold SETUP and tap the playback’s button, then choose Raise & Lower. This should be set to Trigger on Raise, meaning your lighting state will output when the fader is raised. If it is disabled, you’ll find you’ll need to press the playback’s button, before you can raise the fader. If this option is disabled without you changing the playback, the console defaults have been altered. To check these tap SETUP -> Defaults -> Playback Defaults -> Raise & Lower -> Trigger on Raise, and make sure it’s enabled. If it isn’t, when you enable this all future playback you record should behave correctly. 

8 hours ago, nbaldwin said:

the 0 intensity stays at 0 but has a light grey box around it. I presume that's telling us something but we have no clue what. 

This means the fixtures have moved on dark, ready for when they’re next used in the playback. For more information, see the article below...

http://support.zero88.com/1011707591

Hope this helps solve your issue. If you have any queries just let me know. 

Edward

[nbaldwin]

Thank Edward.

We followed your advice and still could not get it working. Scenario:

Saved a lighting state in playback 0 with all of our movers homed (100 intensity). The four floor LED parcans are set to 0 intensity in this cue.

Cleared the programmer.

Brought up the intensity of the 4 parcans to 100. Checked the output window to see only the 4 parcans were tagged. Saved this state onto a playback.

Cleared the programmer again.

Move the fader, nothing happens. Output window shows 0 for the parcan intensity and a grey box appears around the parameter. This is with the playback setup to trigger on raise, release on lower, move on dark turned off, fader mode set to HTP Master.

The only thing we could make happen was by setting the fader mode to either of the LTP modes. But instead of just fading the 4 parcans, the fader faded the intensity of the parcans and the entire rig of movers from 0 to 100 intensity. We abandoned it for the show as we were getting more frustrated than enlightened!

The only thing that I could possibly think of: does it depend on the operating mode of the desk? We almost always run in non-tracking mode.

Neil

 

[Edward Z88]

Hi Neil,

The tracking mode of the console won’t effect this. 

In the Master Playback’s Settings, is it set to HTP Master, and HTP Fader Function? These are the defaults which will allow it to be mixed with other playbacks.

If you’re still having difficulty, please email us your show file to support@zero88.com, and we’ll take a look to see if we can find the cause of the issue. 

All the best,

Edward

[nbaldwin]

Hi Edward,

We might be getting somewhere after your last reply. The Master playback wasn't set to HTP Master (i think it was setup LTP). Changing it has definitely had an effect though it doesn't seem to be entirely working.

I homed all of our movers and then saved that as a Master Playback cue.

I selected a row of the movers and set them to a figure-of-8 moving pattern. I then assigned this to a Playback and now raising the Playback fader does indeed start and stop the effect/movement of those programmed. All good so far!

I then wondered if I could combine that with another Playback but this time use it to change the colour of the selected movers. By itself, the Playback that controls the colour works but if I trigger the previous Playback (the one that makes the movers move), raising the Playback that sets the colours makes the movers go back to their home positions and stop moving (colour changes though).

I then tried another test by changing the position of some of the other movers and saving that as a Master cue. Now when I raise the Playback with the movement effect, the Playback works in terms of making those programmed movers move but it also sets the position of all the other movers meaning the positions etc. of all the fixtures must be stored in that one Playback? I hope that makes sense: in short, we don't seem to be able to combine two (or more) Playbacks, even though the only thing stored in each of them according to the tagged parameters is FX on one and Colour on the other (all with the same row of moving fixtures).

Neil

 

Edit: I tried saving to the Playbacks using "Snapshot" and "All Parameters" but the behaviour isn't any different. It's as though it always saves everything regardless of what mode you save in and what parameters are tagged.

Edit 2: I forgot to add that we are not on the very latest ZerOS. We're on 7.9.4.7

Edit 3: I just updated to 7.9.5 but the behaviour is the same.

[kgallen]

You’re recording too much. You need to not record the things you don’t want to change. So in your colour playback, don’t record position or beamshape. Likewise in your position playback don’t record colour or beamshape. Don’t use Snapshot, that records everything. 

In Record Options (hold Record button til the form comes up) turn off Snaphot and SmartTag and make sure only the attribute you want recording had the red stripe. 

[nbaldwin]

3 hours ago, kgallen said:

You’re recording too much. You need to not record the things you don’t want to change. So in your colour playback, don’t record position or beamshape. Likewise in your position playback don’t record colour or beamshape. Don’t use Snapshot, that records everything. 

In Record Options (hold Record button til the form comes up) turn off Snaphot and SmartTag and make sure only the attribute you want recording had the red stripe. 

Thanks. I'm away from the desk at the moment but I'm 99.9% sure that when I'm recording the FX/Colour to a Playback it shows the correct recording parameters. I'm always careful to look at what parameters have been tagged in the Output window before recording and it's always a single parameter type. I will investigate more tomorrow.

[nbaldwin]

17 hours ago, kgallen said:

You’re recording too much. You need to not record the things you don’t want to change. So in your colour playback, don’t record position or beamshape. Likewise in your position playback don’t record colour or beamshape. Don’t use Snapshot, that records everything. 

In Record Options (hold Record button til the form comes up) turn off Snaphot and SmartTag and make sure only the attribute you want recording had the red stripe. 

OK just checked.

When I set the movers position and press record, the default options are "'Tagged Parameters" and then "Intensity" and "Position" (these are marked red, the rest are marked blue). When I then set the movers colour and press record the save options are "Tagged Parameters" and "Colour" (marked red, the rest marked blue). This is what I would expect but the playback behaviour would suggest that all parameters are being recorded regardless of which are marked red.

[kgallen]

OK, interesting. I wonder if your example is an extension to a similar problem I've been having with recording palettes. What you report looks good. Zero88 chaps need to take a look at your situation too then...

 

[nbaldwin]

Thanks Kevin. Reading your post does make me think we share a similar problem i.e. parameters getting recording into cues (or elsewhere) when they shouldn't be (or shouldn't be expected to be).

I've got an even weirder discovery from this morning. I loaded quite an old show that I knew had working submasters (that work ontop of other cues). Once the OS had converted the old show (from back when submasters were submasters), the converted Playbacks actually work as expected (for example, I have several that just set the colour of all the movers to a single colour, red, blue, green etc. and these work fine without affecting position, effects etc.) but if I try to program the same Playback from scratch they don't work and instead seem to contain position/effects information too where I don't want it.

 

[kgallen]

Hmm bit of a smoking gun there it seems - existing data works as expected, but the latest version (at least 7.9.5) is not internally populating the database correctly from what the UI is telling us.

Especially keen to here back from Z88 now on what their take on this is.

[nbaldwin]

1 hour ago, kgallen said:

Especially keen to here back from Z88 now on what their take on this is.

Yeah, same

I'm I right in thinking they're away at some show at the moment?

[kgallen]

5 hours ago, nbaldwin said:

Am I right in thinking they're away at some show at the moment?

I don't believe so. ABTT was the other week. I think they're just hiding this week. Edward is maybe busy at Uni.

[Edward Z88]

Hi Kevin,

I have completed my degree, however Jon and I are both out of the office at the moment so our replies have been a little delayed.

Many thanks for the information and investigation into this. I will take a look at this issue further when I have a physical console in front of me.

All the best,

Edward

 

[kgallen]

12 minutes ago, Edward- Z88 said:

I have completed my degree, however Jon and I are both out of the office at the moment so our replies have been a little delayed.

Congratulations! I hope you achieved what you were aiming for!

Kevin

[nbaldwin]

Just to add a bit more detail. I thought I'd see what a CSV dump of my Playback looked like. I'm not saying I can make total sense of it but from importing it into Excel there is definitely a value for every parameter of every fixture written in there, despite the fact that the single cue should only contain Position and Effects settings for 5 of our movers.

[nbaldwin]

Just checking back in to see if there's been any updates to the thread.

[SimonH]

26 minutes ago, nbaldwin said:

Just checking back in to see if there's been any updates to the thread.

I think they’re all on holiday, at least they were last week. 

[kgallen]

4 minutes ago, SimonH said:

holiday

Your word - "holiday"...

Ummm, I'm not familiar with that concept 😞 - and judging by the amount of activity on the forum recently, that seems to be a common theme for many! 😆

[SimonH]

2 hours ago, kgallen said:

Your word - "holiday"...

Ummm, I'm not familiar with that concept 😞 - and judging by the amount of activity on the forum recently, that seems to be a common theme for many! 😆

I had to look it up as my spell check didn't recognise it hahaha

[nbaldwin]

I think there is something more fundamental going on with saving any type of cues. This week I started programming a new show from scratch. I started off by just working on some position setups and saving them as temporary cues as I progressed (probably my own quirky way of working). For example, I'd position a couple of sections of movers then when I was happy I'd save the Cue (snapshot). Then I'd Clear and work on positioning other sections of movers and then save a new Cue (not snapshot). So what I'd assume would happen is if I playback the first Cue and then the second Cue, all of the movers I programmed would be in position. Strangely, and frustratingly, this wasn't happening reliably. Some movers that had been programmed in the second Cue would remain in their home positions. I literally repeated this over and over and the behavior was the same: inconsistency in what was being saved into the Cue.

I then resorted to manually forcing a Snapshot save for each saved Cue and that was working. Not ideal but at least I was making progress. Then I started 'updating' some of the saved Cues by continuing programming then forcing an overwrite (the actual Update button I've never really trusted). Oddly this method also started showing signs of programmed fixtures not recalling correctly even though they previously did before I'd overwritten them. Finally I found the only reliable method of saving updated Cues was to force Snapshot and save as an entirely new Cue.

There's definitely something weird going on. The thing is I can't understand why I'm only really noticing this behavior now after updating to 7.9.4 about 12 months ago. Possibly this is because old shows (we mainly reuse shows and modify) seem to 'convert' OK but creating stuff from scratch (which doesn't happen often) is when all the problems start. Apologies for the long text, trying to add as much detail in the hope that it triggers something.

[Edward Z88]

Hello,

On 6/28/2019 at 7:17 AM, nbaldwin said:

Apologies for the long text, trying to add as much detail in the hope that it triggers something.

No problem at all, many thanks for the information.

On 6/28/2019 at 7:17 AM, nbaldwin said:

There's definitely something weird going on. The thing is I can't understand why I'm only really noticing this behavior now after updating to 7.9.4 about 12 months ago. Possibly this is because old shows (we mainly reuse shows and modify) seem to 'convert' OK but creating stuff from scratch (which doesn't happen often) is when all the problems start.

From your description, I am not sure why those movers aren't being stored into cue 2. Please could you send us a copy of this show file to support@zero88.com, along with a description of what fixtures you wish to recorded, and we'll take a look to see what is going on.

Edward

[nbaldwin]

Apologies Edward, I was on holiday for the summer. Will pick this up again once I have the chance.

Neil

[Edward Z88]

Hi Neil,

No problem - just send us a copy of your show file when you get a chance and we'll take a look.

Edward