Leaderboard

Smart tag... Great at what it's meant for (recording cues in a stack for playback "on the button") confusing and a nuisance under other circumstances, especially for setting up a desk for busking (IMHO). Tracking similar. Default values, again great at making sure something happens when you raise intensity but default colour of white seems to throw a lot of people. Personally, I set R=G=B=0 as default for all RGB fixtures as a matter of course (and then get confused when I raise intensity and get full on black before remembering that was what I asked for 😁). Whilst having a mini rant... social media may not be the best place to look for help @kgallen and I and a few others watch this forum regularly and there's a lot of expertise here.

Hi @SoleJan Blue UP to the sky, green DOWN to the grass. (Blue means that channel intensity went up, green it went down.) White, it's a blocking value, purple it's tracked. Red from the programmer (highest priority), yellow for some other controller. Red background is Parked. Grey background (for a short time) is moving on dark. They're all here: https://www.zero88.com/manuals/zeros/desktops-windows/output-window#colours

When you turn SmartTag off you are taking complete control of what parameters are tagged and thus recorded. In this case I’m selecting the fixture, modifying the colour attributes (which tags them - makes the background ‘blue’), then when I RECORD I turn off SmartTag which says ‘hey console I’m in charge I just want you to record the colour attributes I changed and nothing else, just do as I say and nothing more’. In the example of reprogramming defaults I agree it’s nothing to do with e.g. move on dark (this is just one example of where SmartTag usually helps the programmer), just by turning it off I’m in explicit control of what is recorded (and also In this case intensity was zero so SmartTag would have caused my colour parameters changes to be ignored). Note that the colour attribute is by default set as ‘not separate’ (changeable in Setup). This means that if you adjust one colour parameter e.g. red, all of the colour parameters are tagged as it’s assumed that you want to create a certain colour and this requires all colour emitters to be recorded to recreate that. If you really only wanted to record the red emitter you would need to manually untag the blue, green, amber, colour wheel etc parameters (to make their background ‘black’) so they weren’t recorded. When played back, only the red emitter would be controlled, the blue, green etc would stay as they were. This is very powerful but can also be very confusing for inexperienced/basic users. Note that beamshape parameters default to ‘separate’ as it’s assumed that if you were changing e.g. the zoom you didn’t also want to record e.g. the gobo. Some advanced programmers have SmartTag turned off permanently as they always want explicit control of what is recorded via tagging, especially if they are setting up a range of ‘partial looks’ on playbacks/submasters that they’ll use to busk with. If you’re programming a theatre stack then for many ‘normal’ users (myself included) SmartTag is usually on. Note also when looking at your showfile I did it in PhantomZerOS which I started in FLX mode (not FLX S mode as your actual hardware). This gives me access to some more features, like the Source screen. This allowed me to see (but we already ‘knew’) that your fixture was controlled by ‘Default’ as the fader was lowered. I selected the fixture so I could see the parameters details, then on the Source screen I saw the colour parameters change to ‘D’ (and also saw the flick of B=G=255 in the DMX window) as I lowered the fader. Aha! Default is white (as we expected) and causing that flick in colour as you first reported. Reprogramming the default to R=G=B=0 was easy after that. Happy programming - let us know how you get on and any other questions and we’ll try to help.

@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.

@kgallen I don't have much experience with multi pixel fixtures but would this work? Select each pixel that should.come on together and record a group. Repeat until all the required pixels are in a group. Select the groups not the pixels. Run the effect by groups rather individually. Failing that... If the effect can work on a single fixture then giving them the same address will make them behave the same but rule out treating them individually. Heaven knows what it would do to RDM though. You can patch multiple fixtures, on different addresses to the same channel. Again that stops you treating them separately in this show but they can still be patched separately in another show Or build an actual chase recording each step separately.

@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.