Jump to content
Vari-Lite Controls Support Forum

Show dmx value rather than %


keredyelesob

Recommended Posts

Hi is there a way to show parameters as the dmx value. Currently it only shows % for things like pan and tilt this is no good for me.

 

Also is there a way to show value instead of details for parameters with details.for instance I have a fixtue with a shutter parameter. The details show closed,open,strobe s>f,random strobe s>f. The encoder and fixtue output show the detail so i have no idea how fast i have set the strobe.

 

Is there an option to change desplay info dmx,% or detail?

Link to comment
Share on other sites

+1 for this request!

Intensity, RGB, CMY and a few other are nice in percent, but for the most parameters it would be better a) to see the exact value AND the detail description and B) to see the value as DMX value.

Furthermore, the encoder wheels are often not precise enough to catch a single DMX value (if neccessary, for example see the Virtual color wheel of Robin 300 LEDWash) and the resolution could be better.

Maybe there is an option for a fine setting in a future release?

Link to comment
Share on other sites

Have you tried turning the wheel slowly? It seems to be sensitive to the speed you turn it. Slow turns are fine and fast rotations are coarse. I've not tried it with a Robin 300 LEDWash, so maybe it's different?

 

As for DMX values, in all my years of plotting, I've never had the need to see the DMX values! I don't really understand why you'd want to... I don't care what the DMX value is, I only care about the end result. I wouldn't have anything against it being added if it's what other users want, but I have to say it would be waaaay down on my list of priorities!

Link to comment
Share on other sites

Furthermore, the encoder wheels are often not precise enough to catch a single DMX value (if neccessary, for example see the Virtual color wheel of Robin 300 LEDWash) and the resolution could be better.

 

If you take a look at the latest Zeros beta release for the FLX they have added a wheel behavior that allows for 'course' and 'fine' this is a lot more accurate than 'proportional' (the current method). Holding down setup and pressing one of the attribute keys will take you to these new options.

 

 

As for DMX values, in all my years of plotting, I've never had the need to see the DMX values! I don't really understand why you'd want to... I don't care what the DMX value is, I only care about the end result. I wouldn't have anything against it being added if it's what other users want, but I have to say it would be waaaay down on my list of priorities!

 

 

DMX values are fundamental to every modern lighting setup. % is fine for conventional fixtures on a dimmer, you do not need the accuracy for intensity. When you move to the world of intelligent lighting (moving lights, colour changers etc) then i am afraid DMX value is key. To put in laymen terms % will give you a resolution of 100 steps, using DMX values will give you 8bit resolution (255 steps), or in the case of most intelligent lights 16bit resolution (65,535 steps). When working with a large stage then the tiniest moment of a light can have a massive effect on stage, so to suddenly loose 65,435 steps is a big thing.

 

In addition if you cant see what value your desk should be outputting how do you trouble shoot DMX problems in the chain?

 

I would find working in blind mode even harder if i had to second guess what DMX signal the desk is about to send out to my lamps.

 

most (if not all) modern lighting desks have options to show DMX value including the other Zeros desks, % is just something left over from the analogue days.

Link to comment
Share on other sites

Why are you using % values for moving light attributes though? The whole point of using a desk such as an FLX or ETC Eos is to abstract the DMX values into information you can use more easily. I plotted a musical last week with several moving heads with a mixture of LED and conventional fixtures. Not once did I need to see the actual DMX values for anything.

 

I understand how DMX works and how the fixtures use DMX values to control the various features. But why would I care that DMX value of 1-2 is 2700k white and 4-5 is 3200k White, or that another address controls the shutter and 32-63 is strobe effect etc....? I just use the desk to say I want 3200k White and it interprets that to the DMX value for me. I don't need to care!

 

I don't understand how your assertion that you are losing "65,435 steps", you're not at all, they are still there, but the desk abstracts that for you to the encoder wheels. Why do you care that the DMX value of your pan is 134? All you need to care about is that the lamp is pointing where you want it!

 

I use a computer every day, it uses binary to work. I don't care that the binary value of the letter "a" is "01100001". I just let the operating system deal with that and I just get on with writing the forum post. I have that same attitude to programming shows, as long as I have my fixture addressed correctly and in the correct mode, the lighting desk takes care of the rest.

Link to comment
Share on other sites

How do you trouble shoot problems in the chain if you don't know what the desk should be outputting?

How do you work in blind mode if you need to set an exact parameter that has no pallet recorded, (your example 32-63 is strobe effect, I want my strobe to be 2 thirds fast, how do I get it if I can’t see the value)?

using % on encoders that control 16bit parameters is making them so sensitive that you can’t physical make a 1 bit step this can make the difference between lighting into the wings or an actor. You can’t effectively even make a 2-6bit step, yes it may be possible eventually, but I would spend more time messing with encoders than just getting the job done. I expect this is partly the problem jw-lighting is having however I don't want to speak on their behalf.


Your computer analogy is a little farfetched but for clarity I am a computer programmer and i do use bindery on a daily basis working with bitwise. I use binary because I work with computers, likewise if you have trained to be a lighting engineer you would work with, and know about DMX.


Moving on now, your argument is getting a little silly and is muddying the original question/request. It is irrelevant as to why someone would use DMX over %, a good lighting desk should be able to cater for both. i think it should be left there and let other people comment allowing Zero 88 to make a decision on whether to show DMX values (as they have done on their other desks) or not.
Link to comment
Share on other sites

  • 2 months later...

I know I'm bringing up an old post here, but just a quick update on this. We believe a good user interface isn't one that requires the user to understand DMX values and translate that data into "real life" values.

 

DMX is just the data transportation we use to control intensities, and more recently it has been shoehorned into controlling fixtures. Realistically, if we could start from scratch, DMX in it's current form wouldn't be the protocol we would use to control moving lights and LEDs. Each parameter of a moving light, LED, smoke machine etc requires a different unit of measurement, not just a value between 0 and 255. So for example, Intensity should use a percentage, Pan and Tilt should use degrees, Gobo rotation should use RPM (rotations per minute) etc etc.

 

This is what we're (slowly) moving towards across ZerOS - and you'll see big movements into that next year.

 

However... like it or not, DMX *is* the system we all use to control fixtures (even when using Art-Net / sACN, these are actually just packaging DMX values in a slightly different way). We understand that seeing these values can be helpful for more advanced users when debugging systems etc. For this reason, we'll look at adding back in the DXM Window, probably within "System Info" (available under the "Z" button).

Jon Hole
Global Product Manager, Systems and Control

Link to comment
Share on other sites

Each parameter of a moving light, LED, smoke machine etc requires a different unit of measurement, not just a value between 0 and 255. So for example, Intensity should use a percentage, Pan and Tilt should use degrees, Gobo rotation should use RPM (rotations per minute) etc etc.

 

This is what we're (slowly) moving towards across ZerOS - and you'll see big movements into that next year.

 

Great news, so are you planning (at some point) to show a "real life" value eg degrees, RPM ect in addition to detail,

 

for instance a moving light has a gobo wheel with 4 gobos, the gobo parameter has the following values

 

1-25 Open

26-50 Gobo1

51-75 Gobo2

76-100 Gobo3

101-125 Gobo4

126-150 Gobo1 Shake slow-Fast (will the desk show a speed (% maybe 0-100))

151-175 Gobo2 Shake slow-Fast (will the desk show a speed (% maybe 0-100))

176-200 Gobo3 Shake slow-Fast (will the desk show a speed (% maybe 0-100))

201-225 Gobo4 Shake slow-Fast (will the desk show a speed (% maybe 0-100))

225-255 Open

 

Glad to see DMX overview will be back so helpfull when checking fixtures and networks. :)

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.