Leaderboard

@Veit0r when adjusting values you want the background of the field above the encoder wheel to be blue not black. Blue means the parameter is tagged. This is the information the console uses to know what to record - it records tagged values. If you click the field to make it have a black background you untag it. The console will then not record the change. Also in the case of reprogramming the default I turn off SmartTag. This is because I wanted to reprogram the RGB default values whilst I had the intensity at zero (and not tagged). SmartTag will only record intensity (at zero) if intensity is zero, it won’t record other tagged parameters (this is related to allowing Move On Dark to work). Hope that clarifies things and you can now have more success with your programming! https://www.zero88.com/manuals/zeros/controlling-fixtures/tagging

@Veit0r can you try this showfile please. I just reprogrammed the default for that fixture to R=G=B=0 (Process: Clear-Clear, select the fixture, make R=G=B=0, tap RECORD, turn off SmartTag, tap HOME, select Default). If I play on PhantomZerOS, whereas with your showfile I see the G and B flick to 255 in the DMX window when lowering the fader, this doesn't happen with the showfile attached below. raiseandlowerplayback13mk2.zos Regards, Kevin

(For background for other experienced users/contributors on here, I’ve tried to help out with this one on Reddit and it seems the issue still exists - any other ideas/what did I forget etc, thanks!). @Veit0r if you could save your showfile and upload it here we can try and debug on our own desks and try our best to understand what’s going on and get you a solution - as you showed on Reddit this can be seen in the output screen as DMX values actually going out to the fixture. Thanks for posting on here (and in the correct sub forum!) where we’ve a chance of reproducing the problem.

Note that setting default and home values in ZEROS (certainly on FLX) gets munged by "smart" settings which should be turned off when recording them. That has caught me out a couple of times.

@Phil Mckerracher @kgallen So, after testing this on both v7.14 and v8 I have shown that... You don't seem to be able to alter defaults on a Solution showfile - even when it is loaded on an FLX running the FLX-only v8 and been saved on that and reloaded. This seems so wrong that I fear it may be me and the way I am doing it. If it isn't then it probably warrants a call to support. You can achieve default colour black by making amended copies of fixture personalities. Fixtures with a default of white behave exactly as I would expect (i.e. the reverse of what you and I would like). They start with white and, as the playback is raised, they fade out the colours that are not needed. Fixtures with a default of black, on the other hand do what I expected and would like and also what I suspect you need. These start at black and fade up the colours needed. Where another playback is already up the (default white) fixtures, the behaviour of the both black- and white-default fixtures is to raise the "missing" colours and the lower the "unwanted" ones effectively replacing the original PB's colour with the new one. T would seem to be the required behaviour but contrasts with faders set up for colour mixing. If you want to mix playbacks then you should refer to the instructions for this in the manual. My recommendation for you achieve the look you require is to set a default of black fr LEDs in your showfile. While this does not seem to be possible through changing the fixture defaults you can do it by creating modified fixture personality files and replacing the library ones in the patch. However there is another way - one which use all the time. On an FLX I use a multi-function key (latched and with release disabled). I save all the default values I need for a show onto this. Not just default colour black but things like stair edge lights at 50% and default positions for moving heads. I engage this when I start the desk up and record the "default" values I need for that day's show on to it. These values would, of course, be restored whenever that show file is loaded. As you do not have MFKs you could use instead. You might find it helpful to disable raise-on-lower on this PB. Be careful about recording HTP levels on this as they will become the minimum level for those fixtures and you will not be able to go below it. For our stair lights this is, of course, exactly the behaviour I require. Hopefully, this, and the various bits I have sent you by DM wi help you to achieve the reults you require. Have fn!

Hmm, quite a mess. It shouldn't be this hard to turn a light on and off. I realise there are a LOT of variables involved and some interactions are unavoidable but I wish I could turn off the clever stuff and just get the basics working first. Reproducing it in simulation is definitely a step forward, though.

The default "snap" behaviour of colour is probably the designer's intended answer to this conundrum, especially in the situation where we're not starting from black and something else had control. But the snap looks awful and I really want to avoid that, and hence I would indeed normally configure fader-controls-colour. That's really what I want, it's just the default colour that's the issue. From a philosophical point of view, I should probably reconfigure all the LED fixtures so their default colour is black rather than white. Then if I bring up the intensity and nothing happens it's simply my fault for not telling the board what colour I want yet. Typically my very next step would be to adjust the colour anyway so it might not be too bad. I think I'll try that when I next get access (if I have time). My memory is that the board wouldn't accept that but I'd settle for a dim grey. From a practical point of view it's yet another thing that can stop a light coming on unexpectedly, and there are already enough of those. And other users of the board might object to such a change. I'll see how it goes.