All Activity

Well, the Jester series was launched 20 years ago, so it wouldn't be a big surprise if they did some (in hindsight) strange things in the software... As a software developer myself, I read "this is a complex function" more as "we didn't anticipate it in our initial design" 😉 Because, lets be real: 16 bit dimming is no different from scaling any other 16 bit value (like eg. a position) during a fade; and you obviously know how to do it, if you offer that option for some parameters. But if you approach the design with an "I enter and display percentages, so why would I use a different number range" attitude, then you will (consciously or by accident) try to make the numbers adhere to that presumption — been there, done that, happens to every developer.

I’ve been having a look around the manuals/forum (without much success/clarity). This post seems to essentially confirm what you observed earlier - 16-bit dimming was added for ZerOS. I assumed, but not it seems, that my Fat Frog would support 16 bit dimming as I have fixtures defined as such. Seems I must be wrong as this thread was about Frog range. I would have thought however that Jester TL would do full 8-bit dimming rather than percentage, but again this seems maybe contrary to your earlier observations. This does bemuse me, because of course the processor is working in binary (and I very much doubt they went to the pain of using BCD!).

It was an excellent thought, but unfortunately the Virtual Dimmer also seems to have 8 bit resolution (or even %), so the 16 bit parameter is still only scaled to 256 (or 100) discrete values. When I do a 20 second fade from 0% to 1%, the light again just "switches on" near the end of the fade time (which again makes me think that the console actually operates on 0-100 internally, because if it were 0-255 I'd expect the "switch" to happen after about 20/256*100=7.8 seconds, with another step after about 15 seconds).

That actually sounds like an interesting Idea. Will try!

I’m not sure if this would help but might be worth a play, if Jester supports Virtual Dimmer. Define a beamshape or position (something that will support 16 bit parameters) onto the channels that the fixture uses for MSB:LSB intensity, then a define a Virtual Dimmer then scale that 16 bit parameter with Virtual Dimmer. I wonder if that might be a method to get you better control at the bottom end. Might not work as a scale on a 16 bit value but as you seem up for a few wacky trials, might be worth a play.

Yes, I checked with a simple 6ch controller. On the Jester, If I assign channel 2 to the dimmer, the spot also dims smoothly (but only to very low brightness, of course, as it only uses 0-255 instead of the full 0-65535 value range). The spot still has a very non-linear dimmer curve (ch2 @255 is probably already about 3-4% brightness) — but it's much better than instantly _jumping_ from 0 to 3%. For testing I also recreated a fixture with channels 1+2 (dimmer coarse+fine) configured as a 'position'. When I then program a cue list where the fixture pans from full left to full right (which is actually displayed as "0-0" to "255-255" — just as mentioned in the manual — instead of "0%" to "100%" like it was with the channel configured as 'dimmer') then the spot does dim smoothly too. This confirms my suspicion that the Jester consoles only support 8-bit dimmer channels (which also explains the warning in the Fixture Type Editor). 😞

I don't see the ETC Colorsource V Zoom PAR listed either here: https://vari-lite.s3.eu-west-1.amazonaws.com/software-firmware/ZerOS-Library-4.5-RigSync-Support.csv or here: https://vari-lite.s3.eu-west-1.amazonaws.com/software-firmware/ZerOS-Library-4.5-List-of-Fixtures.csv which must mean it's not in the library and one reason why RigSync has not been able to patch the fixture, and has thus made a "bad stab" at creating one. Probably the RDM data just identifies intensity and non-intensity (I don't know) so the console has put most things as a Beam parameter (we historically put arbitrary control channels under Beam(shape) when there wasn't a better attribute, i.e. not colour or position). What would I do... I'd write my own fixture profile, and I can do that for you (if you're not otherwise au-fait with the Fixture Tools) if you can point me at the pdf for the fixture and tell me which modes are your priority.

Hi kgallen Thanks for these thoughts. I suspect you are right about the RigSync details have been corrupted in some way. In looking at the fixture definition it looks perfectly normal, however if I click on the various channel numbers that should be colours it appears they have been identified as beam parameters. Do you know if it possible to update the fixture profile currently being used by the new ETC fixture to correct this? Or is it simply easier to start again and unpatch the existing lamps. Then either modify the existing corrupt profile or simply start again and create a profile from scratch as per the instructions. And then add the fixtures again. Would you disable RigSync and do this manually, or would rig sync now use the correct profile. It's a pity Z88 don't keep the library up to date as they used. It seems all the UK experts have left the company and everything is been run from the states.

Hi Do you know the fixture will actually dim to/from zero smoothly? I have lots of different LED fixtures and only the most expensive (some Philips/Selecon fixtures) even remotely dim ‘smoothly’ to/from zero, and even then not as good as tungsten. Try patching the two intensity channels onto two faders patched as dimmers and see if the LSB fader gives you a smooth fade to/from zero. Commercial manufacturers are never going to release the source code of their products. It’s their IP and they wouldn’t want the bad press or support burden of scores of amateur hacked branches of code being out in the wild. The Fixture Software giving a warning about intensity being a WORD is normal and is a useful confirmation.

Yes, I've tested it by programming a cue list too, the brightness has a noticeable "jump" when the spot fades in/out from/to black, which is consistent with only the "coarse" dimmer channel being used. For testing I also created the fixture with MSB/LSB reversed, there I would expect massive flickering while the fade is running (as then the "coarse" dimmer channel would cycle through all possible values) — this does not happen. I also noticed that the Fixture Type Editor prints a warning about channels being of WORD type (i.e. 16bit) when I save the file. When I have more time I will also cross-check what happens if I configure channels 1+2 as something else that has support for 16bit values, e.g. pan/tilt, and then "move" the fixture... The FLX is a much more recent console (about 10 years younger than the Jester series), and the software is completely different; so I don't think it makes sense to compare the behavior between them. I wish manufacturers would release the firmware source code of discontinued products, so that the community could more easily check & fix such issues...

Hi @alg A fixture listed in red in the Fixture Schedule means "not a library fixture" which usually means a fixture created by the user in the Fixture Tools (so I have a lot of fixtures listed in red as I write pretty much all of my own fixture definitions). But possibly it means a fixture created by the user on the on-console fixture create utility. Possibly, and more likely in your case, is the fixture identified by RigSync is not defined in the library and the console has put together a fixture definition based on the information it has obtained from the fixture using RDM (=RigSync). This information is possibly incomplete, erroneous or RigSync has interpreted it incorrectly. For whatever reason, the fixture has become patched with a profile that does not correctly define it. Can you unpatch them and patch them manually using a fixture profile from the on-console library? Or find a fixture definition for a similar ETC fixture? This may or may not be your long-term solution, but at this point it's really to help debug what's going on. I don't know if you have physical access to the fixtures to play with DMX addresses and modes.

I have today installed the above fixture on our installation controlled by a FLX S48. The units were successfully identified by Rigsync and appear in the fixture schedule as 6 channel devices which is their standard setting. However the devices are identified in Red in the fixture schedule, this appears to say that it is not in the standard fixture schedule. They can be identified using the identify feature but are not under desk control. I can see the intensity DMX signal using the monitor on the Z button. However the red/green/blue LED do not appear to be under control, nor thew strobe or fan. And the lamps do not come on. Any suggestions on what could be causing this?

Hi @invisible It sounds like you’ve defined the fixture correctly. Are you testing this by pushing a fader? You will probably find that the fader has 8 bit resolution. However if you programme a cue with a fade you should find that the console fades with 16 bit resolution. That is what happens on my FLX - 8 bit on the fader, 16 bit from a memory. Here’s a thread where we were talking about this (FLX-S in this case):

Hello, I'm trying to set up some Cameo Root Par 6 in 11ch mode on my Jester TLXtra. In this mode they support a 16 bit dimmer on channel 1 (MSB) and 2 (LSB); I created the fixture with the Fixture Type Editor, selected 16bit for the dimmer, and assigned the two channels accordingly. When I load this fixture into the console it seems to only use 8 bit though (very noticeable on LED spots, as there is a significant jump in brightness between 0 and 1%, which is exactly why there is a 16 bit dimmer in the first place). According to the manual: "16-bit parameters are displayed on the desk as two sets of values (eg 127-255) to indicate the level of both channels", but my desk only displays 1 value (0-100%) on the dimmer wheel. In fact it almost feels as if the dimmer doesn't even use the full 8-bit resolution but actually "%". What am I missing? regards, Stephan

An inhibit doesn't set the intensity level it limits what the maximum intensity can be so you can still have playbacks that set something less than 100% and they will still work as expected. e.g. You create two playbacks one of them (a) sets a fixture to 50%, the other (b) sets another fixture to 100% then you create an inhibit playback (i) with both fixtures at 100% (it doesn't have to be 100% but it usually is). With (i) at full, (a) and (b) work normally - 50% and 100%. With (i) at 50%, (a) will be at 25% and (b) at 50% With (i) at 0%, both (a) and (b) will be at 0% One thing to notice is that after you have created (i) you need to take it to 100% once to make it effective - if you just leave it at 0% it doesn't inhibit at all. A spin off of this is that, if the fader isn't quite making it to 100% (because it needs cleaning for example) you can never make it work. I generally find it is easier to delete and re-create inhibits than to try updating them if you need to add or remove fixtures. It's quite a powerful option but you have to get your head around it. Incidentally, there's also parking but I'm not sure if you can do that on S series. Or you could change the fixture defaults, this would put the ambients on unless you had a playback to set them off but the GM or an inhibit that included them would still put them out.

Yes it a direct quote from the vari-lite reply to our Lighting designer/operator who reported the problem at the beginning of July and got the reply yesterday.

@Phil Kiernan are these your words of from Vari-lite? ie is this the firmest suggestion yet there will be at least one more ZerOS release?

Thanks that answers a second question: what inhibit is for😁 l’ve been using the FlxS since 2018? and never found out I’ll give it a try.. but, if I get that right, there’s no way to include a on the fly programmed playback to that group during the show, because all playback faders have to be at 100% when setting a fader as inhibit fader? Thank you 🙂

We've been having the same problem. Sent the file to Vari-Lite and we have eventually got this reply. 'The crash in ZerOS 8.0.0.8 is referencing a palette that doesn't exist. This will be fixed in the next software release, for now I would try to avoid doing it. (Specifically, typing POSITION 26 ENTER.)'

Is it possible that this was caused (even though you downgraded to a previous version than 8.0.0) by the show file being an 8.0.0 show file (e.g. you created the show file while on v8.0.0) instead of a show file of the version you downgraded to? I'm not entirely sure but could it possibly be the case?

Make sure you are using record (not update) and have disabled SmartTag. See manual here.

I've just replied about this in another post. I tried updating the colour default so i didn't have to select a colour each time to see it but instead it assigned a random clour and now wont change it. Updating colours seems to be fine though.

Not by themselves but I tried to alter the default colour on some LED washes and it just refused. Also tried to unblock cues by both the update method and the global method in set up and neither worked so lots of my MID didn't work and had to do loads of point cues. Just really fed up with the desk now.

Well that was an interesting week. I down graded to 7.14 as this was the last one with the library that had some of my kit but it was still freezing. Programmed a show with ~250 cues and only 4 movers and it froze again 10 mins before doors only this time it never recovered and even after a reboot it is frozen. Put my spare in and it loaded the show ok after a reboot to recognise the artnet node. Probably going to look at the ION route.

No and yes. Normally the dedicated grand master controls all the intensity channels. However, in the last few versions of ZerOS the grand master can be programmed the same as any other fader so it is possible to re-program it as an inhibit fader for just the fixtures you want to include. Of course the S series do not have a dedicated GM fader so I guess you are referring to an MFF set to grand master so, for you, the solution is to NOT set it as grand master. Instead, select all the fixtures except your ambience ones, set them to full and record that on the MFF you wish to use as the GM. Then hold down setup and press the fader's button and select Inhibit on the playback settings menu. Note that using inhibit means the playback button will not be Blackout and there is isn't a way to replicate this.