Davidmk

@kgallen @scottydog75 Well yes, but in a show situation, when you discover your hazer (or anything else) has been caught in cues, you can quickly set up an inhibit to get you through the performance.

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.

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.

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

Based on a non-scientific appraisal of forum comments, I think you'd make yourselves very popular with the community (but probably not with official support) if you found a way to extract the patch from a show file. Something that could be loaded in a spreadsheet would be good. (I have a feeling that there is a prohibition on reverse engineering the software though)

@Archie D @MD1125 You are out of my experience here. Nearest I've been was programming PDP11s 50yrs ago. No desire to return to that level of detail

@Archie D I'm not sure what the level of control @MD1125 described is for. It would be easier to get a long DMX cable and move the desk. I use OSC to get quick access to colours, positions, effects and other stuff when I'm busking. I record what I might want as cues in playbacks and send a go PB/cue by OSC from a screen next to the desk. I don't use it when programming the show file in the first place.

What do you actually want to achieve with this? Not in terms of what you would do if you were at the desk, more in terms of what it looks like on stage.

Sounds like you might have a corrupt show file. I've had these sorted out by support in the (pre Vari-Lite) past. Might be worth asking them if they can check it for you.

There is a sort of backspace key (<-) on the keypad that removes the last thing in the command line which you can use to remove things until it stops being red. A common hiccup is pressing one of the colour/beam/shape/position/effect keys which makes it think its going to get a pallette number next and then entering something that's not a pallette number. Done that a few times, never quite sure exactly where I went wrong.

The other reason I use this is that I set moving heads to default positions/beam. They are different for every show and a latched button/sub is so easy to change compared to messing with defaults. Anyway, well done, so glad to hear it!

😃 Seems like we are in a minority worrying about impedance (although relevant to op). A pragmatic view is that, if you have a tester that checks framing and has a flicker finder, a DMX source that passes those tests and a normal continuity/wiring tester, then any cable that passes continuity and doesn't introduce flicker or framing errors is a good cable until proved otherwise in practice.

Another point with XLR audio and DMX is the connection of the shield - it shouldn't be connected to the XLR shell, only the pin 1 in either. Doesn't help tell them apart but worth checking at the same time if measuring impedance.

Yeah but Google "what is a transmission line in digital contexts", ignore the AI and go for Wikepedia although you'll need a coffee, some biscuits and a comfy chair. I think I may be learning more than the original author here!

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.

Yep, that's it!

So,you had them on 5 channels. e.g. Say were your fixtures had addresses 10, 20, 30, 40, 50, 50, 40, 30, 20, 10 and you patched them to desk channels Ch 1 = DMX 10, Ch 2 = DMX 20 and so on to Ch 5 = 50 You then recorded cues and playbacks using these 5 channels. So they are now addressed as 10, 20, 30, 40, 50, 60, 70, 80, 90, 100 These will need to be reflected in the patch however there are two ways to do this You could patch them as Ch 1 = DMX 10, Ch 2 = DMX 20 and so on to Ch 5 = 50 then Ch 6 = 60, Ch 7 = 70 and so on up to Ch 10 = 100 If you do this then channels 1 to 5 will still appear in all the cues and playbacks but channels 6 to 10 will not and will have to be added to all relevant cues and playbacks. Alternatively, you should be able to patch two fixtures to each of the existing channels as Ch 1 = DMX 10 and DMX 100, Ch 2 = DMX 20 and DMX 90 and so on up to Ch5 = 50 and 60. This would mean the show would look exactly the same but you would still have to treat the fixtures as pairs. (I know you can do this on the full FLX but I can't find it in either the full FLX or the FLX S versions of the manual)

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

That is indeed an option, can't afford either a Mac or Cuelab myself though. I'll be taking a look at Miltiplay though and there is another Windows program but the name escapes me just now.

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.

So, OSC requires the desk to be networked with some device (& software) that can send OSC commands. The available commands are detailed in the manual at https://www.zero88.com/manuals/zeros/setup/triggers/osc. These let the external device/software trigger certain actions on the desk, for example playing a cue on a playback. The desk cannot send OSC and therfore cannot provide feedback to the sending device. Networking the desk and the sending device need not be complex. Connecting both to a normal domestic router would be sufficient but note that the router must NOT be connected to the Internet. Some routers can get a bit funny without an Internet connection What you use to send the OSC commands is up to you but a popular piece of software is TouchOSC by Hexler. There are two versions of this. The original version (Mk1) allows you to define a control surface with (among other things) buttons, sliders and rotary controls. This version is free but is not as flexible as the new version. The new version can be used like the original one but has more features including a scripting language with which you can achieve quite complex results but, for access to this you will need to get a licence. There is a very reasonable, one off, fee for the licence. I don't think OSC can receive inputs from game controllers but check this out for yourself on the Hexler website. TouchOSC can be run on Windows, Android, Linux, iOS and macOS. More information can be obtained from the Hexler website https://hexler.net/touchosc Other software is available, all you need is to be able to send OSC commands as defined in the ZeroOS manual but I have no first hand knowledge of what is available and its suitability. Hope this is helpful in getting you started.

@kgallen sort of agree, in theory. Less convinced in practice. Got to open it up to replace a fader - let you know what I find. Ian Knight, you are sorely missed.

@Archie D @kgallen Having acquired a Jester ML24 I've had this sort of problem. Not exactly the same but involving litvup but blank LCDs. It's like the ML end of the desk has hung. I've noticed that the 4pin XLR power connection isn't very positive and I think, maybe, the screen issue is connected to disturbances of the power cable. New 4pin XLRs on order but what do you think, will replacing the power connection help with my intermittent issue?

Yes, but all too often the cheapest old desks are missing their PSUs and it would have to be pretty bad to be cheaper than a PSU in any case.

I'm researching Jester MLs at the moment (I'm buying one). Looks to me like all the Frogs & Jesters used the same PSU (5537500 42w 4 pin XLR PSU). Haven't found a genuine Zero88 one in the UK yet but there's a french site saying they have stock. Some versions of replacement ones have an earthing difference that can result in "DMX flutter".