Approach to visualize DMX fixture color/panning/tilt/zoom data?

    May 15 2012 | 4:23 pm
    I'm building a basic DMX mixer in Max and I'm still fairly new at virtually all aspects of the project. It may be too ambitious, but I'd like a way to visualize what the lights will look like, even when not at the venue. My thought is to have Max draw a shape that represents the light angle, zoom and color. Even just color would be great -- how can I have a color swatch change the color of a shape on screen? Even an LED with a specific color would be good.
    Thanks in advance for any tips on how to approach this...

    • May 16 2012 | 2:50 am
      I'm thinking that the LCD object may be a good option. I can draw arcs and assign color, etc. Can I affect transparency in LCD? How would you depict tilt? I think I need 3D animation for this... still haven't touched Jitter yet. Maybe it is time.
    • May 16 2012 | 3:29 pm
      To save yourself a lot of bother you could just use this free version of an existing visualizer. There's a limited number of fixture types but I'm sure you can find something similar to what you actually need.
      To communicate with this software you need to output DMX via Art-Net, there's an external in my imp.dmx package for this.
      If you do want to build your own visualizer though, you'lk want to use OB3D and Jitter, as that can handle most of the difficult drawing calculations for you. A good approach would be to draw your beams as semi-transparent cones, with cone base width set by the beam angle and zoom, colour of the cone set by DMX colour values, etc. There's tools in the above package to assist with this.
    • May 16 2012 | 4:38 pm
      David, thanks. While I have your attention, I wonder if you could clarify something for me that is probably very straightforward to anyone with DMX experience:
      I am trying to plan for a project in which I have very limited access to the actual fixtures, but I want to figure out as much as I can ahead of time. I'll be using Robe LEDWash 600s. For Pan and Tilt, range for pan is 450 degrees, tilt is 300. What does that mean for the DMX values? What position would 0 be in either case? Does 127 for each mean a central position? Does it depend on how the fixtures were set up?
      Sorry for the aside, but I don't know who else to ask... =)
    • May 16 2012 | 5:13 pm
      For pan and tilt, DMX values always describe the full range of movement available. So in a fixture with 450 of pan, 0 will be -225 deg and 255 the will be plus 225 deg. Therefore you can always home the fixture by sending it 127. Also bear in mind that pan and tilt on most fixtures will be a 16-bit control (spread over two 8-bit DMX channels), so the effective resolution is actually 0 to 65535.
      On most lighting desks however, the actual DMX values will be abstracted during programming as they have no relevance to the user. Generally it's pointless to think in terms of numbers when programming fixture positions, as it's impossible to visualize that information in your head when dealing with large numbers of fixtures all in different physical positions.
      If you're trying to deal with this purely from Max rather than a lighting desk, the best strategy is to set up a preset saving system whereby you program all the positions you will use and give them index names/numbers. Each index should be able to store a different position value for each light, or store no information for a light in order to leave it unaffected. Then any time you want to move a light to a position, recall it using the index. The advantage here is that if you need to move a light, or your venue changes, you can reprogram all the index positions and the show will still work.
      This system on a lighting desk is called 'palletes', and it's basically how all touring shows work. Advanced desks have palletes for every single possible feature of a fixture.
    • May 16 2012 | 6:02 pm
      Great thread---David's advice is very informative.
      Adding to the preset discussion, depending on the kinds of motions you want, you could also have two levels of presets: the "light level" (store a few dozen of the common settings for each light), and the "master level" (which is a preset of presets, it calls specific light-level presets for each light, to get different combinations). It just depends on the setup and the needs.
      Also, you probably want to use an abstraction for each light (presets and drawing commands) so you can easily reuse for as many lights as you need. The abstraction can store the "light-level" presets, which can be set from your master level.
      You could also use [pattrstorage] instead of presets, which has some advantages like interpolation between its presets. That way you can get fades in your colors, levels, pan, tilt, etc. But maybe the DMX hardware implements this already?
    • May 16 2012 | 8:01 pm
      Great info guys. Thanks!
    • May 16 2012 | 10:38 pm
      @Seejayjames What you're talking about there is often referred to as a 'universal' preset (although all lighting desk manufacturers have their own terminology). For information like colour mixing, or gobo selection you would use a universal preset, because this information doesn't change with each fixture. Clever desks can even translate universal information between different fixture models (although not with perfect accuracy).
      Generally, DMX hardware doesn't behave very cleverly in terms of automatic fades and other advanced functionality. All you get is real-time control. Sometimes movement fades are included (with a channel to set from a number of preset fade times), but these are only included for doing very accurate timed position fades, which is only necesary when using large numbers of fixture over long throws.
    • May 21 2012 | 3:47 pm
      So I've been having quite a bit of trouble dealing with DMX data, mostly because I'm so new at both Max and DMX. I am having a hell of a time trying to conceptualize how to send the DMX values to my dmxusbpro. I started with simple messages stored in coll, Then I started in on a very convoluted approach in which I tried to set up "scenes" that represented various lighting sequences. This is not working very well at all. It's too confusing to keep track of the state of each light and where. I'm back to wanting to use coll or something similar.
      And then there is the imp.dmx package, which seems like the solution! But I'm still just wading in this field and barely understand the concept of a Jitter matrix. Can someone (David?) explain how imp.dmx works and why it is preferred? The Art-Net implementation seems like the way to go towards visualization... how should I get started with this? I want MIDI to trigger various actions in the lighting rig. The rig only has six fixtures.
      I know I'm in over my head, but this community has helped me at least delay my inevitable drowning! Thank you!
    • May 21 2012 | 5:14 pm
      Here's something to get you started. Also, check the imp.dmx help patches.
    • May 21 2012 | 8:59 pm
      You really wanna go the object-oriented way, like David 's suggesting.
      I did something like this to develop the spatial, interactive light and sound setup for a dance piece before having access to the actual hardware. We used COSM ( to make an animated 3d simulation of the system and composed the whole piece on that. Then when the gear came we interfaced it to the DMX (led-strips, blinders, moving heads) and sound (4.1) equipment and were good to go. Worked very well.
      Here's a short clip of the system in action:
    • May 22 2012 | 1:33 am
      "I want MIDI to trigger various actions in the lighting rig. The rig only has six fixtures."
      You might have a look at [mtr] as well, to record the MIDI in and be able to save sequences etc. You can use them as intermediate values in the chain and have the MIDI active or not. With intermediate values you can also just use keyboard and mouse for testing. So, hook up controllers and/or notes and parameter and trigger commands.
      This is really only part of the system, you can then use the intermediate boxes as storage for presets, and can draw from them to do your visualizations.
      You can use [seq] instead of [mtr] if it's definitely going to be MIDI control information, because it has more playback options. But [mtr] has the advantage of working with numbers directly, without a need for translating to and from MIDI, and you can control individual sumber streams (scale them, gate them, etc.) Fancier control like "turn off all color control but let everything else keep playing" is easy if you have gates for each parameter of each light, and master gates which control all 6 lights' specific parameters at once.
    • May 22 2012 | 2:37 pm
      This is wonderful advice, thanks guys. Yes, the plan is to move to imp.dmx ASAP, as soon as I get my proof-of-concept prototype completed. I've been getting fair results with very ugly programming, just to help get things rolling. I will post some of this when I'm at my development machine, just to give you guys a chuckle and beg for feedback.
      Control over individual parameters is certainly preferred, and I am doing that currently (even though my patch is inefficient and difficult to navigate.) My hope is that I can have MIDI trigger various "static" lighting events, like "turn on light 1 full zoom, blue, with no new pan or tilt data " and then use Max to throw a Pan/Tilt pair of values at the light to change position.