Jester TLXtra and 16 bit dimmer channels

[invisible]

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

[kgallen]

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):

 

[invisible]

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

[kgallen]

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. 

[invisible]

13 hours ago, kgallen said:

Do you know the fixture will actually dim to/from zero smoothly?

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). 😞 

[kgallen]

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.

 

[invisible]

18 minutes ago, kgallen said:

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.

 

That actually sounds like an interesting Idea. Will try!

[invisible]

31 minutes ago, invisible said:

That actually sounds like an interesting Idea. Will try!

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

[kgallen]

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!).

[invisible]

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.