Davidmk

I was more concerned that this could cause problems if it was engaged. If it was me I'd be trying to take it out of the equation, possibly by choosing a mode where it is disabled. Now this might be a clue. It is absolutely critical that the profile and mode exactly matches the fixture and mode it is in. Otherwise you could getting on fine, add UV to you colour mix and be totally surprised when the fixture starts strobing - or something equally weird. On the other hand... This might mean the issue is not the DMX signal leaving the desk or the profile/mode you have patched at all - a dodgy DMX cable or connector could be to blame. If it isn't that then we are back to the patch being wrong. if you haven't already, then check the fixtures labels carefully to see if it has any model information you can use to find the right manual. If you still have the Strand desk, it might be worth powering that up and checking what these fixtures were patched as, particularly, how many channels they used. If it has a display of DMX outputs you might be able to work out which channel equates to which parameter as well. Here's another trick you might use if you are not sure about the profile. Save your show first, you'll need to put it back after. Clear everything (see clear options in the manual). Turn RDM off. Take one of your fixtures and find it's DMX address, connect it directly to the back of the desk with a short DMX cable, put a terminator in and connect power. Patch some dimmers (more than you think your fixture has channels - at a guess 30 would be more than enough) starting at the address of your test fixture. Make sure the desk is in channel mode. What you should have now is a fader for each of the fixtures channels so, by pushing the faders up, you can see what each channel does and whether it matches one of the modes in your manual. It's a bit tedious and with some parameters (that DMX delay for example) it might be hard to discern the change but it should give you some idea. Remember that the dimmer channel and at least one colour channel need to be up for there to be any visual output so you might have to try various combinations of faders until you get something you can see. If your fixture has any 16bit controls then they will be controlled by a pair of adjacent faders with one having a big effect and the other a small one. Obviously the excess channels should do nothing but the last channel that does something visible might not be the last in that mode so be careful about that. Hopefully you will be able to find a manual where one mode matches the channels you've found and any you couldn't work out are explained. You can then reload your saved show and patch that profile/mode and try that. Apologies if any of the above seems to be stating the obvious - clearly I don't know your level of experience so I've aimed pretty low PS Very early in my career I used Strand equipment, of course it was still resistance dimmers then and I was gobsmacked by the Mini-2 when it came out. I discovered the Z88 Sirius later so, while I still have nostalgia for the old (Strand) days, I wouldn't want to go back to them. I mean, nostalgia's alright but it's not what it was

Gosh yes, meant to say that as well, thanks for the reminder @kgallen I've been looking for information on the fixtures. Two points... Are there multiple models of this fixture? I've found one with a suffix of "g2" and one without. If this is the case, what are these fixtures patched as? The g2 manual I've been looking at mentions a feature called "DMX Delay". Something to do with creating chases when the desk doesn't have the facility to do it. Could this be involved somehow?

I confess I've never had this issue with a desk although I have had less than perfect control due to issues with fixtures, dmx splitters, termination and the fixtures themselves. However your logic (that the fixtures don't cope with the signal they are getting) does have merit. I expect someone from Z88 will be along in a bit but, in the meantime, perhaps I could refer you to this bit of the manual which says... "You can also change the Transmission between Continuous or Delta. Continuous transmission will result in DMX data being sent at a steady refresh rate, and is the default option. FLX consoles transmit at 33Hz, and FLX S consoles transmit at 29Hz. Changing the Transmission to Delta, will result in the console sending DMX "updates". This means DMX frames will be sent whenever there are level changes on the console. If you are controlling a fixture that doesn't seem to be responding correctly, change the Transmission to see if the fixture prefers the change in frame rate. If it does, your fixture is not truly DMX." Another thing to check is that the DMX addresses do not overlap. If these fixtures have a number of modes then remember to allow for this and make sure they are patched in the correct mode as well. (The desk should not let you patch them overlapped but if it thinks they have less channels than they actually have it could happen.) Can you expand on this? For example, if you try to change their state do they just remain the same or do they just go off or do they, perhaps start doing things you don't expect? Also, if you set up a state and leave it, does the problem still happen or does it happen only when you tell them to do something different?

I may have it off by default, can't remember. I'll look at that as well. As I said it's been working the way I want for ages but I'd like to understand it better.

Well that's definitely not what I want so perhaps I need to check this out. What I'm trying to do is have a playback that is just colours and control intensity on faders. The colour cues are triggered, out of sequence, using midi. I've been doing this successfully for months but I was making changes to the cues and adding effects to the stack. Another thing to check out. I'm in the theatre for the next 3 days so I can use a real rig instead of Capture. Thanks for the input though.

Hmm, yes except I didn't turn them on in the programmer. I have sub masters for the intensities. I just assumed that the rainbow effect was colour and intensity and that was where the purple intensity value came from. I'll have to look later. Not important, just curious.

Just so happens I had purple intensity values myself this evening. I don't normally use cue stacks, much less blocking cues, but it happens that I had added a rainbow effect to a stack of cues and the purple values came up when it was running so, I'm guessing, that an effect cue operates like a blocking cue. Am I right?

And I said... Because, as I see it, the current arrangement (of using old format fixtures) is OK as a stopgap but not sustainable.

Custom layouts duly voted for. Thank you.

This is a really good thing, gives you a centralised place to see what the community wish list is - it should help you to please more of the people more of the time (all the people all the time being impossible of course). Added my top 6, got some possible candidates for another two but not sure which to choose. Something that isn't there (and it should already be in ZerOS) is the ability to view faders on pages other than the one currently selected on the main desk. If you have wing(s) you should at least be able to view the pages selected on them. If, like me, you are triggering playbacks on pages that are not selected then being able to view those pages would be very helpful. Needs to be in the monitor app as well as on the main monitor (since you can't have multiple monitors). There are some look & feel improvements suggested. I'd quite like some simple ones like having a full screen channel list (without faders/cues) and/or a custom screen where you can pick one to four existing displays. This would need to work in the monitor app to be useful though. Another thing that isn't there is MIDI over USB. I know other people have asked about that - so many MIDI devices are USB now the old DIN socket is looking a bit old school and having to buy, power and plug up an interface is a bit tedious. Some improvements to the use of MIDI notes have been aired in other topics as well. I've voted for "OSC triggering & reporting" as an alternative to better MIDI but it'd need to be good and let me trigger and even fade playbacks for example. I've voted for "CSV import/improved export". Not because I want to use it to share files with other (obviously inferior ) manufacturer's desks but if you could export and import a full showfile then the possibility exists that you could edit it in Excel and load it back. I'd want to do that for a number of reasons but they might be less pressing if "partial file load" let me load playbacks/cues/palettes from another show file (as long as it had the same patch) and if "ability to update multi cells simultaneously" was pretty universal and as easy to use as a spreadsheet so I've voted for them as well. Editing in Excel carries risks that you end up with an unusable show file but I'd live with that as long as it didn't brick the desk (which it shouldn't). I've also voted for "rig plan layout" as I've had this on things I've used before, its even better if it mimics some of the fixture attributes (like colour & intensity) but, even without that its much easier to pick the right fixtures from a plan than from the channel list. My memory and eyesight aren't improving with age so I'm forever peering at the screen and scrolling it to find the fixtures I want so I've put a vote in for that. You'd need to implement some sort of rig plan (even if it wasn't visible) to be able to do "stage sizing" (which I've also voted for) - this would be a busker's dream if it works well enough but I expect it will be difficult to make it work right all of the time - especially in a touring environment. I'll forgive you if you chicken out of this one but not if you deliver something below par. I've also picked up "fixture editor within ZerOS" - frankly I don't care if it's within ZerOS. Any updated fixture editor that works with the new format that is less clunky than the current one would do (as long as it works on Windows or Android - I'm not a fan of Apple products).

There's my first lesson. I was under the impression that programmer time only applied to fade in but not to clear. Definitely going to give that a try. The video I'll have to review later, I've got a dog reminding me that it's walkies time. Thanks for the input though, prompt and helpful as always.

There are two things I do though. One is using blind mode to create a new cue before I need it, another is to use the programmer to make a new cue live, record it and make it live then clear the programmer. I can then fade out the new cue which I can then delete or keep and re-use.

Strong statement, you are clearly annoyed by this issue. So, are you using the programmer to add these bits on the fly? As I said, I avoid that. It's easy to override or add to existing live cues this way but hard to then get rid of that override - not least because clearing the programmer doesn't have a fade time. If you don't clear the programmer then stuff just builds up in it. I'm aware that there might be ways to remove things but TBH I try to avoid being in that situation in the first place. You could research this or perhaps Edward could advise us both.

So you are operating in a world not unlike my own but you imply you have cue stacks rather than single cue playbacks. I do use a bit of a mixture like that myself even though we have RGB, RGBW, RGBAW & RGBAWU fixtures. What I don't do is use the programmer to busk. Never had the issue you describe though.

Oh. Tricky. It depends on what was specified. Not being a zero 88 employee I'm not privy to that however it does appear to be designed to mix RGB only and my feeling is that doing more than that is a minefield. You see the trouble is you have RGBWAU fixtures but there are so many other variations. Even when it's just RGB you get different shades of colour on different fixtures for the same DMX values (hence me saying it is a quick & dirty solution). So, it is only a bug if it doesn't do what it says on the tin but within the limitations of the spec. As to what is being tagged/recorded then yes, it may be a bug, but that may be with the fixture definition or with the desk software.

Actually that isn't a bad plan - I do that but for reasons other than the ones bothering you. The auto generated pallettes have to be generalised so don't give the same shade of a colour across the four different types of LED in our rig so I always use my own pallettes. Creating your own pallettes and always using them in your programming you can adapt the colours used in your show quickly and easily. Here I am thinking of when you need to replace fixtures with different types when you use a venue's own fixtures or you can't use the ones you originally programmed for but it also makes life easier when you decide that the shade of orange you chose really doesn't go as well with the the set as you originally thought. The auto pallettes and the colour picker, IMHO, are no more than a quick and dirty way to do things. Great for when you don't have time for subtleties or for beginners but if you have time making your own always wins.

Ultimately Zero 88 have to develop features that keep them competitive and I expect that is the main justification for the development budget. Other factors may include controlling support costs (by fixing bugs, improving usability and even, sometimes, adding new features). I'm sure it's true that having a lot of satisfied users helps new and repeat sales so things that make users happy are good as well. Keeping existing users well supported with good service and new features is part of that and, for the record, I am a very happy user. However, other than boosting or maintaining sales of new desks, new features do not generate income directly so I'm sure there's some process of costing and justifying each new feature. Zero 88 do not expect you to buy a new desk every year or two to get new features which is what some manufacturers resort to and they keep supplying the new features as long as the hardware can support it - even when it is no longer manufactured. Yes, there are features I'd love to have and I'd love to have them tomorrow but I bought my desk on the basis that I'd used Zero 88 before and I knew it would be easy to understand, well supported, easy to get fixed, well priced and would do what I wanted even if it might be a bit clunky in some less used features. Believe me, I've used more expensive desks that are clunky in all areas and that is not something I've ever found on Zero 88.

We get the version current at the time included in the cost for sure, we are morally entitled to bug fixes for that version but new features? Who is paying for them?

I'm right on the fence in this. As a user I'd like to know what is planned and when for but I also know I'd get over excited about features that are important to me, impatient if they were a long way down the time line and frustrated if they were late or cancelled. As an ex software developer I appreciate that it isn't that simple. Some features will be easier and better if other features are implemented first. Some might turn out to need a ground up re-structure to do properly without compromising future maintainability. Yet others may compromise performance. Features that look to be straightforward can end up being dismissed or delayed because of the above or other reasons. We should all remember that we get software updates for free. Lots of developers expect you to pay for feature releases and eventually stop supporting obsolete versions. I suspect it would hurt Zero 88 sales if they adopted this model but we users have to remember that development is not free and so things may not always move on as fast as we'd like and may prefer a direction that maintains or improves Zero 88 competitiveness in relation to other manufacturers. Perhaps there could be a compromise... Maintaining a public Wish List (in the forum perhaps) shouldn't be too hard and it could provide some feedback on desirability from the users and feasibility from the developers. That way Zero 88 would get low cost market research and we would have some input and be able to manage our expectations.

I'd refer you back to my post of 22nd November 2019. For forest, you could put a green in one corner, yellow in another and maybe white in the other two but play with it until you get what you want. Have fun!

You might find this useful... https://zero88.com/manuals/zeros/cues-playbacks/playing-back-cues/rgb-colour-mixing-on-playbacks

Still haven't got this working, not sure why. I think I need to check the addresses on the fixtures and my assignment of them to channels. It's complicated because some are paired with the same address while others have unique addresses but paired on the same channel. (It's to do with keeping the rig down to one universe but it's not how I'd do it.) I think I'm in for the long term so anyone hoping to do this themselves best not hold their breath 😕

I should have started there shouldn't I? Especially after directing others to "RTFM" 🙂 My next gig's get in is later than usual so I could arrive early and give myself a couple of hours playtime before having to start work in earnest. Let's see what I can find out.

So, yesterday's gig was busier than expected and I didn't get a lot of time to spend on this but I did try it. First up, I used macros to trigger the playbacks - as in I recorded a macro for each playback and then called those from my chase steps. I have a feeling that wasn't what Edward meant but lack of time stopped me from using the playback trigger instead. With macros, the results were mixed. It does work if the Tap Tempo is slow but I think latency is a problem because, if you speed it up, it seems to miss steps out. Snag is that, when it is running fast, it is difficult to be sure about that and I can't see the actual fixtures from the desk (I have to go down a floor and out into the auditorium) so I can't increase the speed gradually and look for a breakdown point. Back in theatre next Friday, I'll give it another go then. Watch this space.

The actual line in the manual is "All consoles can store a total of 10,000 cues across the playbacks."