Control/Dimming Implementation of "Abstract Control Model"

[derekleffew]

Abstract control model, whaaat?

...I just started using the Jands Vista a couple weeks ago, and it has a really cool feature called the generic fixture model. ...

It is a cool feature, which Strand supports as well. Pioneered by Horizon Controls, see Horizon Controls - Abstract Control Model WhitePaper-2005-02-21-ACM.pdf . One wonders why other manufacturers haven't adopted a similar philosophy? Perhaps it's that, once the "DSL" position palette is made, no one cares if that is P/T at DMX 105/243 or 65°/-27°. Or that "Slow Rotate" means more to an operator than 2.7 rpm.

Being the guy that works with the Palette every day, I'm obviously partial to it over other desks. My thoughts...

The Universal Attribute Control is complete and not partial like many other desks. You have a show programmed with a Mac, move the show, now you have VLs, change it in patch and you are done. I did this on a Broadway tour a couple of years back and it worked very well. ...

...In the interest of fairness and educating us all, could someone from ETC comment on how Ion and Jr. handle these topics of real world terminology, abstract control model, and instrument swapping.

Hi everyone. Well, I'll speak to the Eos family of products and Sarah will weigh in on behalf of the Congo line. Regarding swapping out of fixtures, yes, that works very well. If the color data is stored in HS (which is the default mode when using the Color or Gel picker - and when working in native space the data can be easily converted to HS with the Color Format control), the HS values translate to any mixing color system. Similarly with pan/tilt, if the ranges of the original fixture are different from the new fixture, the data is converted appropriately for the applicable ranges of the substitute. Linear data and "framed data" such as scroller, color and gobo wheels are no problem. One area that we are looking to improve in the near term is the handling of device modes - right now those are translated as DMX values but will be stored as modes shortly. ...

 

[cpf]

Not sure what you're asking, so here goes:

Means you can tell all your fixtures to go to colour A### and point 27 degrees down while bobbing up and down 2 degrees and spinning back and forth 180° in sync to a piece of music you've got going, then if you change to a completely different fixture from a new manufacurer, the new ones will perform the exact same pattern. i.e. Instead of programming DMX values, you program real-world attributes and the board does the rest.

From a technical perspective, it relies on a large library of fixture definitions with all attributes and controls predefined and mapped out, so you select the fixture and enter the attributes and the board converts those for every fixture you've got patched, and sends out the appropriate DMX values. The major challenge is assembling an accurate and comprehensive library of fixtures: the feature only works if it works for every fixture the user has.

 

[SteveB]

re: Implementation of "Abstract Control Model"

One of the big questions I have always had about the so-called automated fixture swap feature is what to do about ML profiles and their vastly different set of gobo's, as well as the way that certain fixtures deal with animated effects, prisms, diffusion filters, etc... About the only time I see the automated feature being useful and easy, is when all the (profile) ML's are doing is positioning and color, or possibly using wash fixtures (VariLite 550, Martin MAC TW1, etc...). The minute you use some of the other functions, you end up re-programming, automation be ****ed. Certainly the gobo set on a Martin is different enough from a VariLite, High End, Elation or Robe, that there is no way the automated function can hope to cope. So yes, I'm glad it's a feature in the Ion, but I will likely never use it and it certainly was not a decision issue during purchase.

The issue of so called real values in positioning (Left 15 degrees, up 5 degrees, clockwise, ccw, etc..) is in line with something Tim Buchman, former Obsession console operator at NY City Center asked once, in reference to how others cope with console control when the operator can't see the stage, City Centers Obsession being located in an off-stage right room (if memory serves). They (he) was having trouble as to what console controls to manipulate to get the "US shutter" in, when he had no reference point for where the fixture was pointing in relation to it's home. I believe at the time they were doing a dance series using VariLite 1000's as re-focusable specials, thus the conundrum. Not sure if being able to control the actual fixture using degrees, CCW, etc.. would have helped. Certainly a birds eye view might have, at which point any desk would have worked equally well, IMO.

 

[derekleffew]

...They (he) was having trouble as to what console controls to manipulate to get the "US shutter" in, when he had no reference point for where the fixture was pointing in relation to it's home. ...

This was also mentioned by Rob Halliday during his talk at LDI: Given an overhead fixture hanging anywhere near midstage, the "US shutter" could be any of the four. In order to grab the correct one, the programmer must first figure out where the fixture is pointing, then orient himself to how the fixture numbers its shutters. Shouldn't there be an easier way? Why does the console "get in the way of the art"?

-----

Not sure what you're asking, so here goes: ...

The question was (or should have been):
How well (if at all) does lighting control console X use real-world values in its programming of automated lighting?
Followup: Besides the benefit of fixture substitution, what other advantages are there to a console using ACM?