Fixture definition.

[ben.suffolk]

Folks,

 

As you may be aware I am wanting to develop a lighting application for my PowerBook (Allowing for a range of interfaces, although initially working with my own USB DMX Interface). I don't want to rush into this and find I have problems during development because I have not designed it correctly.

 

I am currently looking at the how to define fixtures and I want to make sure I don't end up with a design that excludes the use of certain fixtures, or makes it difficult to use the application. Obviously I don't want to keep programming special cases just to make a new fixture work because I have missed something obvious at this early stage.

 

I only have experience of a small number of fixtures, but I'm sure that between the members of the blue room there is experience of every fixture ever developed B-) It would be great if you can comment on my thoughts about fixture definition, pointing out any omissions, or corrections that might be needed.

 

Its my assumption that any fixture can be defined by using a variable number of attributes. Each fixture can have any number of the following attributes (multiple attributes of the same type would be possible, for example a fixture with 2 gobo wheels would have the gobo attribute twice).

 

I have defined the following basic attribute types :-

 

Basic : The standard 8 bit value, additional snap values or settings may be used within this attribute.

 

16 Bit : A 16 bit number divided between two channels, the 8 LSBs are optional, allowing this attribute to work on an 8bit fixture.

 

Wheel : A basic wheel type has a definable number of set values that correspond to snap positions of the wheel (i.e. the location of the gobo, colour or effect). In addition they have a 'generate split values' option to automatically offer positions between each defined snap position. A wheel type may have an additional set of channels to modify the wheel behavior.

 

Colour Mix : Uses 3 channels to represent either RGB or CMY. In addition an option defines if the colour mix is additive, or subtractive. A standard colour interface will be used, with the attribute doing the relevant calculations needed based on the defined settings.

 

Using these types I am able to define the following specific attributes to define a fixture :-

 

1. Intensity : Basic

 

2. Shutter : Basic, additional settings :-

 

Open Value

Closed Value

Use shutter as Intensity (If enabled a shadow intensity attribute will exist in the fixture. Setting an intensity value will calculate the correct shutter position between the Open and Closed values. This option is for low end fixtures without Intensity channels)

 

3. Strobe : Basic, additional settings :-

 

Slow Value

Fast Value

 

Generally (always?, should this just be an option on the shutter attribute?) the shutter channel is used to set the strobing, in which case whichever attribute is last used will adjust the setting on the other attribute appropriately.

 

4. Gobo : Wheel, options :-

 

Rotation channel

Absolute position

Shake

 

5. Pan : 16 bit

 

6. Tilt : 16 bit

 

7. Colour : Wheel

 

9. Colour : Colour Mix

 

Effects such as rotating prisms, should be defined using an additional gobo attribute, appropriately named. I think all other attributes such as Focus, Zoom, Iris, colour temperature correction, automated barn doors etc can be defined using appropriately named basic channels.

 

In addition to the attributes a standard set of Macros can exist :-

 

1. Lamp On

 

2. Lamp Off

 

3. Reset Unit

 

User defined macros should be possible, although it should be noted these are fixture macro's and not stored fixture settings, which should be done through the application.

 

Regards

 

Ben

[Doug kelly]

Hi Ben

 

You may also want to include some of the control/timing channels that several lights have ie Pro 400's VL 2000 series to name just 2.

 

With the macros for lamping on it might be worth allowing for a staggered strike of multiple fixtures.

 

 

Doug

[Locksmith]

There is a fixture editor/designer program available from zero 88 here at the bottom of the page. It might give you some ideas.

[mefju]

 

 

Its my assumption that any fixture can be defined by using a variable number of attributes. Each fixture can have any number of the following attributes (multiple attributes of the same type would be possible, for example a fixture with 2 gobo wheels would have the gobo attribute twice). 

 

<{POST_SNAPBACK}>

 

There are some fixtures driven by DMX-value-change instead of DMX-value. Look at:

 

http://www.wahlberg.dk/video/dvd_philips.htm

 

This is a DMX-controlled DVD/CD player. As far as I understand manual, If you want to play song #5, you have to set CH1 to 5%, set CH2 =100%, CH1=100%, CH2=0%, CH2=100%.

 

I don't know it is popular but you asked about general model of fixture.

[Tomo]

That's how many fixtures are sent the "Home", "Lamp On", and "Lamp Off" commands, to make it harder to do by accident, so some extension of that macro idea ought to work.

 

The real problem with 'change in value' fixtures are strobes - many strobes fire when the value goes above 50%, and then again when it drops below 50%, but do nothing when the value is unchanged.

A personality for this could be rather difficult to write, depending on how generic you want the strobing function.

 

Another extreme is things like media servers, such as the Catalyst.

These have ridiculous numbers of parameters, and while some of them (eg clip number = gobo wheel, frame number/speed = gobo rotation) are easy, others (eg keystoning/trapezoidal adjustment) are kind of odd - in the Catalyst this is defined as four corner positions - these could be approached as being another set of position data, but I don't know of a lighting desk that can cope with the idea of fixtures having more than one position at once!

 

Personally I think that the Catalyst should be defined as several different fixtures, which must be patched contiguously in the right order. You'll only ever do this once, so it shouldn't be a major hassle if the subfixtures are numbered.

[PhilR]

Think about HSI fixtures as well as RGB/CMY - I've seen a few appearing recently, and they need to be dealt with differently in terms of fades. It's the most obvious thing I can think of off the top of my head.

 

I've got quite a bit of experience with this, so if I come across any other things to think about in the near future I'll let you know.

[Potassium Neuf]

Even though many fixtures have CMY colour mixing they do not all work the same way ... on some the three channels have to be at 0,0,0 to produce white, on others they have to be set to 255,255,255.

 

Also many fixtures have combined dimmer/strobe/shutter channels which work as a normal dimmer chanel up to 50 % and then various strobe speeds between 50 and 100%.

[jfitzpat]

Another extreme is things like media servers, such as the Catalyst.

These have ridiculous numbers of parameters, and while some of them (eg clip number = gobo wheel, frame number/speed = gobo rotation) are easy, others (eg keystoning/trapezoidal adjustment) are kind of odd - in the Catalyst this is defined as four corner positions - these could be approached as being another set of position data, but I don't know of a lighting desk that can cope with the idea of fixtures having more than one position at once!

 

Personally I think that the Catalyst should be defined as several different fixtures, which must be patched contiguously in the right order.  You'll only ever do this once, so it shouldn't be a major hassle if the subfixtures are numbered.

<{POST_SNAPBACK}>

 

The Catalyst is an extreme example, but it brings up two different 'models'. One popular approach is to map all fixtures to common denominators. Another approach is to just offer generic controls and bring out the features, whatever they may be. On a physical console, the former is pretty logical, since you probably already have dedicated knobs and switches. On a computer, where all knobs and switches are vitual, other models can at least be considered.

 

Variations of the alternate model not only give you ready access to things like 'lamp assisted lightning effect...', without having to have a stack of manuals or cheat sheets, they let the controller handle those 'modes', or features, intelligently. IE, fading between settings does not inadvertantly send the fixture through 10 other, visually unappealling modes.

 

FWIW, with the Catalyst, I prefer one 'fixture' per Catalyst 'layer'. I do use a position control for each of the 4 keystone corners. Since my position controls each inherit individual effects, or movement generation, I get do do some pretty neat laser 'lumia' type looks with just the simple colored rectangle modes.

 

But, from a 'one day gig just get some looks done' perspective, management of things like the X, Y, and Z channels, as well as naming all the settings on the mode and effect channels is what I find most helpful. The only hardcopy I keep around is the thumbnails for the image/media library on the Catalyst. Not having to remember which portion of two channels (which work together as a 16 bit value) controls axis position and which portion is rotation in a given direction, along with things like having color mapping and play modes spelled out in plain English is a big time saver to me. If you've never seen the act before and you are winging it, being able to go from one Catalyst look to another without a lot of unexpected mode hopping is a big help as well.

 

That's not to say the 'bring out all features in readable, predictable, form' does not have cons. If you don't force fixtures to some form of lowest common denominator, some global operations and make/model substitution features get pretty difficult.

 

-jjf

[Mystic]

looking at some clear text fixture definition files 'such as avolite's) can also definitively help you. they have some interesting concepts (LTP fading or not, etc..). If you can afford it, having some little macro/scripting inside the definition can help a lot sometimes (to do palettes, lamp on/off, etc..)

 

ps: I use a mac and I am into programming, if I can help you, just tell me :P

[peternewman]

An obvious one that has so far been missed out is something like a scroller or DMX controlled effect for a lantern (e.g. effects wheel or gobo rotator) or the various yoke and mirror attachments, where the fixture needs to have two addresses, one for the dimmer and one for the attachment.

 

16 Bit : A 16 bit number divided between two channels, the 8 LSBs are optional, allowing this attribute to work on an 8bit fixture.

<{POST_SNAPBACK}>

This probably won't work quite as you expected, as usually the fine channels are directly after the coarse ones, so you couldn't use the same profile for a fixture in two modes, unless the profile itself defines the patching of the control surfaces to the DMX channels.

 

You could go to the extreme end of the scale, and define lots of extra things to allow the software to swap moving heads for example, like the Vista can. It would probably also be wise to have a number of general undefined fields, for that bizarre new fixture that comes along in the future.

 

HTH

 

PN

[peter]

With colour mixing, you'll need to make provision for special cases. An example of this is the High End Studio Beam, which has two colours on some of its wheels, in some modes. It might be worth thinking about patching a 'fixture' then telling the desk which modes the fixture is set in - eg patch a Mac 500, then select Mode 4.

 

Also consider how you would handle fixtures which can do continuous rotation on Pan and Tilt (Panabeam) and another handy feature would be a 'virtual dimmer' for RGB fixtures.

 

If you want an example of a complicated library to work on, look at the PRG Virtuoso EX1 Media Server. It takes 256 channels and is hard addressed to DMX 1.

 

With regards output standards, it might be worth syndicating the DMX output as ArtNet or Pathport via Ethernet.

 

Something else to consider would be whether you want to allow the use of the Hippotizer network system which allows thumbnails of the media clips to be displayed onto the desk. This is transmitted via ethernet between desk and server. The Maxxedia also does this.

 

And one more thing... what about specifying RGB values for the fixed colours on a colour wheel. That way, the desk can pick the closest match even if the fixture doesn't have colour mixing.

 

 

Hope some of the above helps

 

 

 

Peter

 

 

Edit: It might also be worth adding the ability to set Open and Close values on the Gobo wheel, and if the fixture has a Shutter channel, allowing multiple occurances of Open and Closed. This will help you when using Move Whilst Dark.

[ben.suffolk]

Thanks for all the comments so far, a big help already. I will update my spec.

 

With the macros for lamping on it might be worth allowing for a staggered strike of multiple fixtures.

I am thinking that will be a part of the lighting application as opposed to the fixture definition, I don't think fixtures need to know anything about other ones that might exist on the rig. I do recognise that its pretty important though, if all the lamps strike at the same time in a lot of fixtures you could easily end up over your power budget. (I'll be asking for lots more suggestions at some point in the future for the application its self)

 

That's how many fixtures are sent the "Home", "Lamp On", and "Lamp Off" commands, to make it harder to do by accident, so some extension of that macro idea ought to work.

Yes I think making sure user defined macros can be built easily, maybe taking parameters as well, such as tack number for a play macro.

 

The real problem with 'change in value' fixtures are strobes - many strobes fire when the value goes above 50%, and then again when it drops below 50%, but do nothing when the value is unchanged.

I have to admit, when talking about strobing I was thinking of fixtures strobing the shutter as opposed to DMX strobes, so yes thats something to think about. I guess there are 2 possible approaches, 1 the fixture definition has the intelligence to generate the strobe pulses based on a flash rate value, or the desk / software generates them. I suspect the latter is better as you may want a number of strobes firing at the same rate, or in sequence. You could of course allow for both possibilities.

 

Think about HSI fixtures as well as RGB/CMY

I take it this is what I would think of in the graphics world as Hue, Saturation and Black/Value/Intensity. can you give me an example of a fixture like this so I can have a look at its documentation, you also mentioned about the fade being different on this type of fixture. Can you elaborate a little for me on that please.

 

Even though many fixtures have CMY colour mixing they do not all work the same way ... on some the three channels have to be at 0,0,0 to produce white, on others they have to be set to 255,255,255.

Ok so some sort of channel reverse option needs to be included, possible worded as 'black is high'.

 

Also many fixtures have combined dimmer/strobe/shutter channels which work as a normal dimmer chanel up to 50 % and then various strobe speeds between 50 and 100%.

I was thinking in those cases you would still define the intensity attribute, and the strobe attribute, but on the same channel, then when you start using the strobe, it overrides the intensity.

 

An obvious one that has so far been missed out is something like a scroller or DMX controlled effect for a lantern (e.g. effects wheel or gobo rotator) or the various yoke and mirror attachments, where the fixture needs to have two addresses, one for the dimmer and one for the attachment.

A good point, so thats actually quite easy to allow a fixture to have a number of start addresses, and the each attribute can be relative to one of the start addresses.

 

It would probably also be wise to have a number of general undefined fields, for that bizarre new fixture that comes along in the future.

I wasn't thinking of having a fixed number of attributes in a fixture, more like a pool of possible attributes and then each fixture definition is made up like pick and mix, e.g. 1 intensity, 2 gobo, 1 CMY colour, 1 pan, 1 tilt sort of thing. That way any future fixture that may come out with new features is easy as you just use a few more of the 'basic' attribute types. Again along this line the 16 bit values would be the same, if you only choose to use them as 8bit then the 8LSBs will not get included the address range.

 

and another handy feature would be a 'virtual dimmer' for RGB fixtures.

I'm liking the idea of a virtual dimmer, thats a nice idea. I'll have to check out the math, but I guess its not just as simple as reducing all the values. One assumes the ration between them has to stay the same so if you have a lot of 100% red and 50% blue, when red is at 50% blue needs to be at 25%. Does that sound right?

 

Edit: It might also be worth adding the ability to set Open and Close values on the Gobo wheel, and if the fixture has a Shutter channel, allowing multiple occurances of Open and Closed.  This will help you when using Move Whilst Dark.

Something that maybe I should know, but why would I want multiple occurrences of open and closed on the shutter? Why is one not enough?

 

Sorry this is a long post, but I thought it much better than lots of small ones. I'm sure there is still a lot of things that I need to know, so keep the ideas and suggestions coming as you think of them.

 

Regards

 

Ben

[computer]

I'm liking the idea of a virtual dimmer, thats a nice idea. I'll have to check out the math, but I guess its not just as simple as reducing all the values. One assumes the ration between them has to stay the same so if you have a lot of 100% red and 50% blue, when red is at 50% blue needs to be at 25%. Does that sound right?

I assume it would work in a similar way to a submaster/grand master.

 

Also, would it not be easier to just use an already available 3rd party generator and (with their permission) use their fixture files as well?

[Mystic]

Thanks for all the comments so far, a big help already. I will update my spec.

 

Even though many fixtures have CMY colour mixing they do not all work the same way ... on some the three channels have to be at 0,0,0 to produce white, on others they have to be set to 255,255,255.

Ok so some sort of channel reverse option needs to be included, possible worded as 'black is high'.

<{POST_SNAPBACK}>

 

How about a little scripting language like this (we have a ill-designed fixture that does dimmer from opened (0) to closed (127) on channel 1, then strobe on that channel and some strobe effects on the same channel) :

 

dimmer = channel[1][127->0]
strobe = channel[1][128->192]
strobe_pulse = channel[1][193->255]

 

Adding some mathematical functions could also be a good solution, to correct a non-linear dimmer curve, etc... but it may also be a bit complicated in the end :P

 

 

Another idea : put the maximum pan and tilt speed (or any parameter change speed, as for scrollers) of the fixture in the personnality file, so the control won't ask a MAC500 to do a full pan swing in 0.2 seconds and then come back.

[Bottle]

In addition to the attributes a standard set of Macros can exist :-

 

1. Lamp On

 

2. Lamp Off

 

3. Reset Unit

 

<{POST_SNAPBACK}>

Ben

 

Had a couple of thoughts about this, for example having a Home macro that would set ML Pan and Tilt attributes to a central position, set the gobo wheel and/or Shutter to Open, and the colour wheel to White etc. I might have the wrong end of the stick, if this is what you intended the Reset Unit macro to perform <_<

 

Each fixture attribute has a Home value associated with it that is called when the Home macro is invoked, e.g. Pan/Tilt set to 128, gobo/shutter set to 25, colour set to 0 etc (hope you get the general idea)

 

Makes plotting a whole lot easier if you can actually see where the heads are all pointing!

 

This function is available on the Zero88 range of ML desks (AFAIK - I only have a Diablo, but the Fixture Library is the same for all the desks :P )

 

Anyway, HTH, and look forward to the end result.....

 

Ian S