Leaderboard

My post on the topic of OSC use with the Zero88 FLX S24 may be of interest. All free software and might give you a start in understanding the process.

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

@DMH @RJP To be fair, some good answers there and, if delivered, could help the situation but... How it looks is important. In the absence of a published plan and feedback on progress, its all we have. We used to have trust but that has to be earned so, come on Vari-lite, start looking better. You've bought the rights to good hardware and software with an established customer base - many of whom have been using Z88 products for years, decades even @pcollins666. An unpaid sales force that was more than happy to sing the praises of a company that looked after them, had a solid track record of supporting them and of steady innovation. What do you think those established customers are saying to your potential customers now? It's clear the full FLX had to be discontinued but there's no talk of a replacement. The in-person training has stopped. Cwmbran is no longer a service centre and there are none listed on the Vari-Lite Web site in the UK (the two "dealers" listed are a 2nd hand equipment seller and a hire company). Plus, to return to the origin of this thread, there is now a charge for fixing the (inevitable) gaps in the fixture library. These things are probably not Vari-Lite's fault but what is being done to address them? How could I, in all conscience, reccomend a Z88 product today?

As a Zero88 stalwart user and supporter for more than 30 years, I asked a few questions just about what we might expect in the way of support following Edward & Jon’s departures. I did receive a prompt reply in red below. It at least gives their intent and maybe a base for us to push from…. With my two good friends, Jon Hole & Edward Smith departing in quick succession, can you describe the changes to the support services that we are likely to see going forward. I understand how this must look but I would like to reassure you the software development team that are in the background are still very much here and as will has a dedicated support department. The support department is manned in the UK and US so we can offer better global coverage. Up to this point I’ve had personal FLX Support response to emails usually within one working day. We do still try to respond withing 24/48 hours to direct emails, however this will also depend on workload as we also cover on site visits. Instant phone call response for show critical issues. Are there still FLX console experts available to take technical enquiries? We have and have always had an out of hours emergency response number, this is available from the Vari-lite website. Please find below the link. https://www.vari-lite.com/global/support/technical-support Daily monitoring and responding to forum posts, usually within one working day. No spam posts. The forum appears already to be out of control. The forum has slipped behind as we have been dealing with direct customer support, we are currently working on a solution to this. Fixture Library addition requests created and emailed back usually within one working day. We are creating fixture files for customers but as the workload has increased we have had to increase the estimated turn around time to up to a possible 21 days. We understand this is a big difference and we do endeavour to do them ASAP which is usually between 1 and 3 days. If the file is urgent, we recommend the customer creates the file themselves as this is a very easy process within the ZerOS Software, please see the link below. https://www.zero88.com/manuals/zeros/patching/add-fixtures/fixture-creator Ongoing ZerOS development with bug fixes and new features. Are there still dedicated ZerOS software developers actively in post? As I mention above, the software develop team has not changed this has in fact increased with developers in the UK, US and New Zealand. A roadmap for ZerOS progression, shared with users. A monitored ‘What would you like to see in ZerOS’ poll. Regular beta testing releases with feedback being acknowledged and logged. Updates and improvements to training manuals and YouTube content following ZerOS releases. Thank you for your suggestions, I will forward them to the product management team. As you can see from the above, Zero88 provided a truly comprehensive service to its users, at no extra cost. I would like to hope that a similar service will continue to be provided from the company that has the iconic and industry respected name of Vari-Lite. Thank you for your questions and I hope you find our response reassuring. We are constantly looking at our processes and internal procedures to improve the customer experience.

The answer to that lies in this forum over the last few months. As a 30 year user/buyer myself, it’s spelled out in big fat letters. It’s the end of the line folks I’m afraid, they’re not interested. Jon managed to get in a last gasp with ZerOS 8 before he left. That will be the last, I’m sure of it. Zero88 and its beloved products and employees are no more.

Ever since acquiring my Frog 2, I noticed that with the Dockhouse (Capture) Demo Presentation show file for ZerOS (available from Zero 88 here), it is of course a .zos file. The change from .isf to .zos for show files was made in ZerOS 7.9.8, a version of which is after 7.8.2.39 (the last supported software version for Frog 2) meaning Frog 2 only loads show files saved with the .isf extension. This means my fellow Frog 2 users won't be able to use the Capture Demo File for learning or having a play/experiment, so I have "converted" the .zos show file to .isf in order to be compatible with Frog 2. I imagine the audience for this won't be too large anymore since I feel Frog 2 popularity has died down significantly, but I'm posting this as a public resource in case it is of use to anybody who still uses a Frog 2 or a console on a version of ZerOS before 7.9.8. When loading in the show file, you'll be told it was from a Frog 2 and that some data won't be loaded. There shouldn't be any reason that some data won't be loaded with the way I've done this, but if you are loading this file onto a Frog 2, UDF 1 (User Defined Fader) will have a stored state on it. If loading this onto a different console type without UDFs (e.g. Solution), this should be transferred onto playback/submaster 1 (theoretically). It is also worth noting that this .isf show file is only within the limitations of Frog 2 - meaning the other higher universes found on the .zos version won't be seen or usable (Universe 5 & 6). The attached show file loads with the newer ZerOS skin if on Frog 2 - other consoles have that skin by default regardless, to provide a familiar user interface appearance to the other consoles people may have used with capture in comparison to the light grey and green classic theme on Frog 2. I have tested the .isf file with the Zero 88 provided Dockhouse 2022 file designed for the .zos version and it does work correctly. Anyway.. here's the show file, hope it is of use. Z88 Capture Dockhouse v7-8-2-39.isf

Good morning @Sol, Welcome to the Zero 88 Forum! @Davidmk and @kgallen have done an excellent explanation of how to go about solving this with a 'master' playback triggering and releasing other singular playbacks. I would have done it the same way. I'll admit, this is something that should be able to be done easier, but this is unfortunately currently the only way to do so. I've written some guidance below, expanding on the discussed elements in this post, to help you along with this. (Apologies for the colossal message, I have tried my best to cut it down). In the following steps, you'll be programming individual playbacks with one lighting state each for each 'step' of your chaser. As Kevin and David have mentioned, we can then trigger and release these individual playbacks with a master playback (not the regular type of Master Playback with the main GO button though, to avoid confusion) that just has control over these individual playbacks. It's worth noting that the 'master' playback you'll program will be a chase, with the individual playbacks (the 'steps' of the chase) will be one state on each playback. E.g. Playback 10 has fixture 1 and 5 at full white, then Playback 11 has fixture 2 and 4 at full white, with 1 and 5 at zero, then finally Playback 12 has fixture 3 at full white, with 1, 5, 2 and 4 at zero. This creates the singular steps for an effect that will chase in towards the middle. By programming these individual steps onto separate playbacks (the last few playbacks available on your desk are recommended to keep them out of the way), it allows us to individually trigger and release them. When releasing a playback, ZerOS completely wipes it out from the outputs, returning to the underlying data for that fixture (if any at all), allowing fixtures to switch back to your original rainbow gradient. For example, if I have Playback 1 as fixture 1 thru 5 at full white, whereas in Playback 2 fixture 3 is at red - I bring up Playback 1 (all white), then I bring up playback 2 (fix. 3 at red) while keeping 1 at the same place. Fixture 3 will turn red. If I bring down Playback 2 (fix. 3 at red) to zero, fixture 3 will return to the original data it has in Playback 1 (white) as Playback 1 is still raised. Steps for creating each individual playback (acting as each step for the overall chase) Step 1: Bring those fixtures up for the first / next step of your chaser you want to program. Step 2: Put them in the colour 'White' so their colour is tagged. This will differentiate the colour from the underlying rainbow playback. Step 3: Tap 'Record' -> Tap an empty playback's flash button. (I recommend the last few playbacks, and ensure to leave room to place them in order so you know which one does what) e.g. 3 steps I would have Playback 46, 47, 48 with 46 being step 1 and 48 being step 3 (last step). After you've programmed each individual playback (e.g. each step) Step 1: Think about where you want to put your 'master' playback that will start your custom chaser. Pick somewhere which has an empty playback to the right of it (explained later*) Step 2: Ensure nothing is being output from the desk again. Tap 'Record' -> Tap that playback's flash button of where you want the 'master' playback to be. Then do the same for the empty playback to the right. This will record an empty cue on each playback. *The way this will work is the left one of the two playbacks will be the playback to start the chaser, and the right of the two will be the flash button to stop / release it (the whole chaser). Step 3 (repeat as many times as needed): Record an empty cue for each individual playback ('step') you have programmed onto the 'master' playback (left of the two). On the second cue recorded, the desk will show a prompt. Tap 'Create Chase'. The second cue has now been recorded, with the playback converted to a chase. This prompt will not appear for future cues/steps recorded to that playback, as it will just add another step to the existing chase. Step 4: Go to the first cue in this playback (VIEW + Playback Flash Button to view these cues) and tap 'Add' in the 'Settings' column for that cue. Step 5: As David mentions, use Macros -> Trigger Cue Stacks (tap 'Add' next to it) -> Select your individual playback for the first step. Tap OK. Tap OK again. Step 6: For cue 2, you should tap 'Add' in the 'Settings' column again, Macros -> Trigger your second individual playback for the second step, but under 'Release Cue Stacks', put in the previous step (for this - the first individual playback). That's the base of it done for the first two cues. You'll now want to repeat that for each individual playback (acting as each step) you have programmed, ensuring that for cues past the first trigger, you release the previous, and trigger the next. Cue 1 should have the first trigger, and releasing the last playback so when the chase repeats, no steps overlay each other. In the single cue in the playback to the right (the one we will use to stop the chaser all-together that I talked about earlier) - do VIEW + Playback Flash Button -> 'Add' in 'Settings' column -> Macros -> Release Cue Stacks -> Add in all of your individual playbacks. This will release all playbacks when you hit the flash button, stopping them. You can also trigger both of these playbacks in your main cue stack, so you don't have to worry about moving the faders. Note that if your 'master' playback for this chaser effect is still raised or active, then it will just re-trigger these individual playbacks, so when stopping using the playback to the right, ensure the 'master' playback is down. You may notice something odd with the fade timings for each step. To fix this, enter each playback's view like you've done previously (using VIEW + Playback Flash Button) and edit the fade times in the columns to whatever you wish. The console will listen to these fade times when triggering and releasing each individual playback. To set up your 'master' playback for a Tap Tempo, hold SETUP and tap your 'master' playback's flash button -> CHASE tab -> Use Global BPM (tap to get it with a red line to indicate it is selected). Then define an empty playback as a Global Tap Tempo by holding SETUP again and tapping a flash button of an empty playback -> Fader Function -> Global Tap Tempo -> OK. Again, I apologise for the very very lengthy message, but I hope this is relatively okay to understand, please do let us know if you need more help as this is quite painful to do, and many thanks again to Kevin and David for the initial replies! Archie

From the manual... Cue only means that tracking options will not be available within the Record and Update windows. Cues are programmed with a full capture of the stage output to ensure what you see on stage is exactly what is programmed, and exactly what will be played back when you replay the cue. I suspect this is the reason why you are saving the whole stage output. Try it with cue only off - this should get you the record options, selected fixtures might be useful.

Hi Scottydog75, Apologies for the delay in response. The software team are in the process of finishing the next beta build for ZerOS. This should be released for testing on the forum within the next couple of weeks. Kind Regards

Hello Oliver_74 You can use the Add as additional address function found in the Edit DMX Address window to pair your five fixtures. When you select the DMX address of the first fixture you want to pair, the curser will flash in the DMX address window which will be blank. Type in the address of the second fixture in the pair, select Add as additional address, then Enter. The Fixture schedule window will show two addresses for the channel fader of the first fixture. I only found this last week when I wanted to pair dimmer channels under one fader.

I can confirm that the Flx S48 console worked well using about 2000 channels with 2 Artnet node and 13 used universes

Hi all. The iOS apps are now back on the App Store in their original capacity and under the same links they were before. ZerOS Monitor -> https://apps.apple.com/gb/app/zeros-monitor/id1033159176 ZerOS Remote -> https://apps.apple.com/gb/app/zeros-remote/id367342433 (cc: @Charlie Newman @Philh @ATC Tech)

Thanks everyone for your help on this, after digging through a good few training webinars on YouTube, I came across the simplest answer - offset, specifically how the offset fans across fixtures. You can change this behaviour by holding setup and tapping effects. I set my shift click to be 'fan first' (Also experimented with the other fan options for different effects) then selected my fixtures, hit chase, held shift and span the encoder wheel to fan the offset of the effect until the chase matched up on all battens. Worked super nicely and certainly opens up some more interesting possibilities for programming Battens Chase LQ.mp4

A JOS file is likely to be a showfile. A fixture personality file is an IFT file so it may be they way you're trying to load the IFT file? Found this from Ed on another forum... The <Update Library> option in Super User can be used to update the fixture library on the console. If you just wish to load in a fixture file, not a whole library, please see page 49 of the Jester TL manual for information on assigning fixtures… https://www.zero88.com/storage/downloads/5ebda1d3-7348-4727-ae31-fecedf299a46/Jester-TL-and-TLXtra-Manual-3.0.pdf#page=49

Hi Give the attached a go and let us know how it goes LeLight LED Moving.ift

@DMH@RJP The SPAM postings seem to be on the increase with over 40 in last 24 hours plus others highlighted but still on the forum. Please can some trusted forum members be promoted in a way to allow removal of these posts?

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.

Hear hear... Where's the downvote button when you need one ⬇️ I wonder how long until the FLX S is canned - I had slight optimism at the ZerOS 8 launch that it sounded like FLX S would be hanging around for a while (https://www.vari-lite.com/global/news/releases/zeros-8-0) - perhaps not much longer with the 'core' Z88 team all gone now. Still wonder if we'll ever hear from our new Vari-Lite admins on this forum? (it's not too late to introduce yourselves, we don't bite! Would be great to get some of your insights on the future of FLX to allay our concerns!) Signed - a loyal Z88 user

@Davidmk I suspect you are pretty much bang on with all you say. I don't think Vari-Lite are interested in the console business, or any of Zero88's products. I think Zero88 was just a tiny operation that came along with their bigger purchase of Signify (or whatever transient companies bought the stable that included Zero88 on the way). Zero88's Cwmbran manufacturing operation is (/was, if it still exists) pretty much over to subcontract electronics build. They'll make a few Zero88 product batches as and when demand requires it. I suspect that will dwindle and drop off as demand drops and the lack of successor products means the Zero88 brand disappears. This forum will be funded until someone high up in VL realises they are spending money on it and/or the traffic drops off to a level they think there is no need for it any more. We've probably missed the boat but it would be desirable to get the schematics, Bills-of-Materials and if possible software source code out of the remaining Z88 databases and into the "public" domain before VL type "rm -rf /*" on it all and forget it ever existed. The software source code might be tricky as it might contain sub-licensed IP such that it doesn't have a GPL type license, I don't know, this is not my area. I've not heard anything about any new products with the Z88 brand and there is no evidence to date on the beta forum of ZerOS development work post 8.0 (although JonH did suggest there was an ongoing development plan on his leaving speech). But I don't think there is "anyone" left from Z88 to do this. I think Simon, the key software guy, was probably a sub-contractor [I could be wrong], so will have moved on to other ventures to keep paying his mortgage. If he is about, he's been very quiet and hasn't posted on here at all to say "don't panic guys, we're still here (just)". Time will tell. But I'm not holding my breath.

If Vari-lite aren't interested in ZerOS, it would be good if they could put the source code in the public domain so it could be turned onto an open-source project.

I’ve got one of these. Make sure you are on a modern version of zeros and search for the showtec act fresnel 150 RGBAL. That is a library fixture. You can then edit it and rename to the act profile as it has an identical DMX patch. Let me know any problems. Link to the manual below if you’re not sure how to edit and rename fixture. The only thing you need to change though is the name. Also don’t use RDM or rigsync as that will complicate things. https://www.zero88.com/manuals/zeros/patching/add-fixtures/edit-export Brian

My thanks gents & @Archie, I echo David's appreciation of your comprehensive response. I set Ch1 to Beam as a "Mode" channel on the thumb wheel & it's working as you suggest with values 9-135 controlling intensity but with all colours firing, overriding any colour parameter. Panto opens next week and I don't need a strobe so I'll leave it as I described in the OP for now. If I need a strobe I can come back here to confirm the sub-parameters setup. Many thanks Simon.

@Archie D @Simonkbike Very thorough response as always Archie. If I've missed this in your post I apologise but I'd suggest ch1 should have a default value somewhere between 240 and 255. This is because my reading of the chart suggests this will be needed to make the virtual dimmer work.

This is a tricky one. Some years ago I attempted the same thing without much success. The problem is that you are fighting the principles of Last Takes Precedence. When you set the background rainbow that state is "last", if you then set another state (without removing the old one by lowering the background fader) that becomes "last" and remains in control as long as the fader is up. When you lower the new states fader (and as long as Release On Lower is on for that playback - this is the default) it releases that state and the background state becomes the "last" (unreleased) state. This rule applies to chases as well so, as each step executes, it sets a fixture to white and it remains white until the chase fader is lowered and the all steps in it are released. This means that the fixtures turn white and stay that way until they are all white. Normally each step in a chase (e.g. a red/white one) each step sets the new fixture to white and returns the previous (or all other) fixtures to red. But you can't do this because you want the colour from the old state and you don't know what that might be. Your issue then is how to release previous steps in the chase when the next step is executed. Things you can try... You can release things from a step, see Cue Settings -> Cue Macros in the manual https://www.zero88.com/manuals/zeros/cues-playbacks/cue-settings/cue-macros but I think this only works for playbacks not steps in them. Perhaps you could make a chase that triggers a different playback in each step? You could modify a Sparkle effect. You can only do this on an FLX so you'd have to set it up on Phantom ZerOS and then try running it on FLX S. See the manual at https://www.zero88.com/manuals/zeros/effects/waveforms. This is probably your best bet - unless someone else has a good idea. I'll be watching this thread as it's something I'd like to achieve but no longer have the will or time to spend on it.

Hi @Alexandre, apologies for the late reply but I thought it was worth sharing this. Thank you for providing your show file. You're correct, the crash behaviour is related to Move on Dark being used in Playback 7. Upon further investigation of your show file, cue 3 in Playback 7 contains the 'Smooth' effect (E5 to be precise) applied to fixtures 2-9 and 49-54. After messing around with Move on Dark and only enabling specific attributes (position, effect, etc.), it appears that Move on Dark is looking forward in the cue stack (from cue 1 & 2) and is attempting to apply an intensity effect (Smooth) to fixtures that are at an intensity of 0 in that cue (essentially - those fixtures have no intensity values to modify by the effect / have had no intensity instructions as their intensities are not set in that cue and the previous ones - tracking is enabled). Note that 'Smooth' is an intensity based effect, which is likely the reason for the crash behaviour from what I can see. Instead of disabling Move on Dark generally for the whole playback, in ZerOS we have the option to disable certain parts of it, ensuring you don't lose out on any advantages of using Move on Dark e.g. with colour and position in sacrifice of effects to prevent crashing. To do this, you'll need to turn off the effect attribute for Move on Dark for the specific cue(s) that are causing you problems with Move on Dark so the console ignores any effects that may cause issues for that cue specifically. You could alternatively go the simple route - disabling effects in Move on Dark for the whole playback instead of just individual cues, but that will result in (for example) position based effects not being taken into account by Move on Dark, meaning effects such as 'Circle' won't be applied in dark - you will see them apply from 0 effect size to their defined effect size for that cue over the defined fade time as the fixture's intensity is brought up. You can, however, resolve this*. Disabling Move on Dark for effects only on specific cues: In the 'Settings' column in the cue stack, tap 'Add' on the cue you wish to disable effects with Move on Dark Tap 'Don't Move Effect' so it has a red indicator as opposed to a blue one (red is 'activated/selected', blue is not) Tap 'OK' Effects with Move on Dark has now been disabled for just that cue. When launching into this cue, effects will now be applied on the press of GO into that cue. You can do this for every cue that is causing a problem. Disabling Move on Dark for effects only on the entire playback: Hold the 'Setup' key on your console's front panel and tap your playback's flash button On the internal touchscreen (or monitor if using a FLX S48), tap 'Move on Dark' Tap 'Don't Move Effect' so it has a red indicator as opposed to a blue one *By enabling 'Don't Move Effect' for the whole playback in the playback's settings, inside each specific cue's settings referred in my first set of bulletpoints, that option will now have changed to 'Move Effect' (only for cues within that playback). This allows you to tell the console to look ahead in the cue stack and move the effect-based things for a specific cue anyway, ignoring the playback's general settings for Move on Dark that all effect movements are disabled. An example of this is shown in the image below in the far left column of options: I hope this helps, and I hope your FLX S continues to serve you well. Kind regards Archie

Same happens to me, but not for hazer, but for houselights. I would very much like that "exclusive playback" feature.

I have long been asking for Exclusive Playbacks for the very same reason. This is what Edward Smith sent me back in March 2023: Exclusive Playback" faders are currently assigned to ZerOS 8 on our roadmap. Please note that this could move if our priorities change. If a playback is configured as exclusive, this would prevent it from being recorded into cues, even if recording with SmartTag.

If you are operating with tracking options set to "Cue Only" or you have "Snapshot" enabled when you record then you have effectively told the desk to record everything. See manual here and here. In the Record Options, "SmartTag" enabled could record the hazer - if you changed one or more of its values in the programmer. For full control of what gets recorded you need SmartTag off. You can then select "Tagged Fixtures" which will record every fixture that has been changed or "Selected Fixtures" wich only records the currently selected Fixtures. See manual here. Cue Only, Snapshot & SmartTag all let the desk decide what to record, turning all of them off makes you decide but then you need to be sure you have included everything you want. Tagged Fixtures will generally get that right, with Selected Fixtures there is a risk that you will select a fixture, change it, de-select it, select another and change it then record - in this case only the 2nd fixture gets recorded. Essentially, the desk will do what you tell it but you need to understand what you've told it. There are videos in the linked manual references, these might help. To remove your hazer (or anything else) from a cue, select it, press Home then Update and select Remove. Hope that helps.

@SimonH One of those occasions where I am glad to be wrong 😀

It had been set to flash, rather than Go(Fade). I will set back after current show is finished. We have been running the show on one of the sub-masters which works fine. Thanks for the hint.

I finally got a chance to try this yesterday and it worked! (A latched submaster with colours set to zero on affected fixtures.) Oddly, a few MFKs initially didn't work with it (either not coming up at all or affecting other lights they hadn't affected before) and I could find no difference at all between the ones that worked and the ones that didn't. But re-recording the ones that didn't work fixed them so I was happy.

So now you are into something of a grey area - I fully expect this response to attract comment. It especially needs comment from a sound tech as I'm hazy about that side of things. You can often get away with audio cables for DMX but no-one in their right mind would recommend that because you might not get away with it and you can bet the problems would only be apparent mid show and not at fit-up. The easiest way to tell the difference is to see if it is printed on the cable . 150ohms is not the resistance of the cable it is the impedance. Cables do have a resistance but it is dependant on length and is only important if the cable is meant to carry a current (as in mains cables where it is very important and is part of PAT testing). As far as I can tell from researching it, DMX cables should have an impedance of 150ohm as you said). 110ohm is allowed but not recommended. I'm guessing, but I suspect anything below 110ohm is likely to cause problems. The standard for audio is 110ohm but there is a wide range in use - 60ohm to 150ohm is quoted. Apperently, the main thing for audio is that the source and cable should be low impedance and the sink should be high (e.g. 10,000ohms). I Googled "what is the correct impedance for balanced audio cables" and read the AI response to get this information. This would suggest that a "standard" impedance audio cable would be acceptable for DMX but the really low (below 110ohm) cables would not. You can measure the impedance of cables with the right equipment but you can't use the resistance range of a multimeter. Google "how to measure the impedance of a dmx cable" for ways to do it. Your physics lab techs might be of help in this area. Ultimately it is better to keep your audio and DMX cables apart and mark them with something obvious so you can put them away properly. (That's a big ask in a school I know.) There is a reason why the standard for DMX is 5pin XLRs even though it only needs 3pins and 3pin XLRs are cheaper.

Is it CSC you are thinking of That would be it! Thank-you.

OSC is really useful from my perspective for when you just want to run your show off one main control centre, but not having lights + sound (and possibly projection) all programmed in on a singular machine. If that one machine goes down, you've lost all lights, all sound and all projection. Whereas, if you run lights separately with the computer controlling sound and projection, while a lighting console is controlling LX separately, if the main computer goes down then you still have light on stage and can control that independently. Something like this can be done with OSC via QLab (with Network Messages) however QLab does require a license for this, or using something like Multiplay (another sound + projection cue-based tool) as @Neil Macmillan has used, is another option that is free to use (but still very very good!). So, if you are looking for a cue-based solution and you use a Mac, QLab is probably the best option (you could have a "magic sheet" as @Davidmk has, using Cue Carts within QLab). These "cue carts" can fire Network Messages over OSC to trigger certain cues on the LX console, like a soundboard but for lights. However, if you use Windows, Multiplay is also a good option (not sure about cue carts on it though). If you're on a Mac and instead of using QLab, you want to use Multiplay, you could run it via Wine but this won't run natively on your Mac and I'm not sure if OSC would work with how Wine handles things, but it could be worth a try. Unfortunately QLab on Windows isn't an option as it is developed primarily on the Apple platform, and so relies on Apple infrastructure for features such as AppleScript integration. QLab Network Message Cues - https://qlab.app/docs/v5/networking/network-cues/ QLab Cue Carts - https://qlab.app/docs/v4/general/cue-carts/ If you do use Multiplay, I very much point you to Neil's video! (I used it myself when having a play with OSC over Multiplay to my Phantom ZerOS setup, so thank you very much Neil for making that video). Best of luck with what you want to do with OSC.

Good stuff. In my world it's mostly busking so I'm using TouchOSC to give me a "magic sheet" where I can select colours, positions, effects, whatever by touching a button. The buttons fire specific cues in cue stacks. For example, I might have a stack with cues to set colour (and only colour) on some wash lights. Each cue has a 2s fade time. The buttons each trigger one of these cues and, because it is a cue stacks, I get the fade and the old colour gets faded out. I also have a button that releases the stack so, for example, I can release the effects stack when I'm done with it.

Don't worry, with the page you provided me with the 'common' subdomain, there are workarounds 😉 https://backstage.zero88.com/a-z Thank you very much.

I'll have a look when I get home (I fear I may have deleted my bookmark), but that's a good shout

Only if I’m doing work on a board out of the system - in circuit, CMOS chips aren’t quite as vulnerable. I’m assuming you’re not running your feet on a nylon carpet first! But if you have a wrist band then might as well use it.

This is why we’re here! Keep asking/sharing and we’ll do our best. If you can help out another user - either directly by asking a question of your own which is answered, or more directly, then even better. That’s how this forum works, especially now the Vari-lite support is minimal.

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!

@kgallen Correct, although I suspect the processor board isn't custom, more likely an off the shelf unit that has become uneconomical because other customers have moved on. I figured that... The problem with producing FLX is the availability of the processor/screen combination. ZerOS has been shown to run on Rasberry Pi, not only that but an old model of RP. Newer RPs have more muscle than old ones. So it is possible, probable even, that a RP 5 has the capability to run as an FLX The problem with that is interfacing the hardware bits the FLX has and the S doesn't. I speculate that the various peripheral boards inside an FLX actually talk to the processor via USB. We know the fader wing does so its possible the internal faders do as well plus it is the sort of interface an off the shelf board might use. Even back in the day, Zero 88 wouldn't want to develop a whole new protocol so, even if it isn't USB, it will be something for which an RP hat might already be available. So, assuming the hardware interfaces are USB, or something that someone in the community could sort out with widely available circuitry (OK, that might not be possible), then, with access to the source code, you have to identify how it 'knows' what hardware it is running on and all the places it uses that information. For that, you need a software specialist. I'm rusty, and it would probably be in a language I'm not familiar with but I reckon I could give that a go and I'd bet I'm not alone. I don't know the background of everyone in this and the Facebook forums but, given that about half the LX techs I know have backgrounds in IT and/or telecommunications the expertise is out there. The flaw in this is that Vari-Lite have paid for the ZerOS intellectual property and are highly unlikely to give it away for free. Plus they wouldn't want all the support calls which would result from the unofficial versions that would spring up as a result. The other thing is why has there been no announcement of a Pi based FLX S+ to replace the full FLX? Is it that it is much harder than I have assumed or that they bought Zero 88 for the other products?

As far as I’m aware you can select the fixture and then edit with the on-console editor. https://www.zero88.com/manuals/zeros/patching/add-fixtures/edit-export

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.

hey denks for the answer. its a pity, that there are no plans for it anymore. good evening