Fixture definition.

[ben.suffolk]

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?

<{POST_SNAPBACK}>

 

I'm keen to explore all the possibilities, but I suspect that there are things that people will suggest here that don't exist in other 3rd party generators. If however I'm wrong and they do exist then that would be a cool way to go forward.

 

I'm more interested in what's best as opposed to what's easiest though, there seems little point in putting hurdles in the way of the project if hey can be seen in advance (hence the questions here)

 

Ben

[computer]

one useful feature as well would be a "FLAG" feature so with movers or even generics you could push a button and it could flash on and off for a few seconds so you can see where it's pointing.... then return to how it was before.

[Potassium Neuf]

The 'Home' values in the Zero 88 fixture library are defined for each fixture parameter such that when a fixture is 'homed' the intensity goes to full, the colour goes to white, shutter is open, no gobos, no effects, no prisms etc and the position goes to 50% for pan and tilt (128 for 8 bit pan/tilt or 32768 for 16 bit pan/tilt).

[ben.suffolk]

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.

 

Doh, thats just such an easier way of explaining it isn't it, don't know why I didn't think of it like that.

 

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

 

No the reset macro was intended to send a reset to the moving heads that support it to realign them etc if needed. A Home macro is a good idea, and a simple one to implement as well. I also liked Computer's 'locate me' type idea, although I think thats more of a desk / software feature than a fixture definition, unless you need to define how the fixture will respond to a locate me command from the desk I guess.

 

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

 

So do I :-)

 

Ben

[computer]

are you developing this for the mac completely or will there be a windows version at all? I'm quite interested actually in this idea, it's quite clever.

 

Did you get my email though I sent you?

[PhilR]

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.

 

Basically, you've got it spot on. The ones I can think of offhand are the Xilver Droplet and the Chroma Q ColorBlock.

 

The main problem with them is because Hue on it's own defines the actual colour used, if you record @ 255 but treat it as a normal colour mixing fixture then as you raise a fader you'll go through the entire spectrum before returning back to the initial colour (Blue in the case of the ColorBlock). Basically, in an ideal world, you want to fade around a colour wheel - although that's a software issue. It's something that's caused me no end of problems in recent months!

 

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 helpful for some fixtures where the Dimmer is inverted for some reason (255 is blackout and 0 is full 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's worth noting that 99% of the time this'll be patching a dimmer separately from other attributes, but occasionally it can be something else. I've come across a Strand Moving Candenza which had both the dimmer and colour scroller patched at different addresses to the bulk of the fixture. Rainbow Scrollers (if I've got the right ones!) also do something similar and again can need three things patching.

 

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.

Doh, thats just such an easier way of explaining it isn't it, don't know why I didn't think of it like that.

 

Either works beautifully :P Just keep in mind the idea that you want to master the attributes rather than limit/reduce the maximum values.

 

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

No the reset macro was intended to send a reset to the moving heads that support it to realign them etc if needed. A Home macro is a good idea, and a simple one to implement as well. I also liked Computer's 'locate me' type idea, although I think thats more of a desk / software feature than a fixture definition, unless you need to define how the fixture will respond to a locate me command from the desk I guess.

Ultimately, the information'll be in the fixture file whether explicitly or implicitly. After all, even if the desk knows that a home value should be open, it still needs to know which of the values on the Gobo Channel actually is open somehow. For channels like Pan and Tilt you might be able to just say it'll be 50%, but on the other hand, Clay Paky Alpha fixtures have their home position at 60% pan (if you want the fixtures to line up nicely) - so the file might be best.

 

Edit to fix quotes <_<

[ben.suffolk]

are you developing this for the mac completely or will there be a windows version at all? I'm quite interested actually in this idea, it's quite clever.

<{POST_SNAPBACK}>

 

Personally I will only be developing this for the mac (having never developed anything for windows, and in fact only having an old win98 machine kicking around anyway would find it quite hard) , but once I have documented the format I am going to use, I will make it freely available for anybody. So that windows developers, or even board manufacturers would be able to use the concept and share fixtures definitions, which could only be a good thing.

 

I'm thinking along the lines of using XML for the actual definition files, which will make it very portable and easy to parse on many different platforms.

 

Ben

[Russ]

OK here's my take on this - I've mentioned to Ben already that it would be awfully nice to have an open standard for fixture definition files, so hopefully we might be able to at least make a start towards one here.

 

Instead of writing a load of blurb I've had a go at writing a format, an example is available here. A few comments:

 

I picked the x.Spot because it's got more functionality than you can shake a stick at. It's also cool. And I want one.

It's XML, that's mainly because XML is self-documenting so I don't have to write comments :P.

There are two main entities - attributes and functions (aka macros). I think you can do everything with that.

 

There are two main issues with this system at the moment:

 

Firstly, there's no way for a console/program to work out what attribute is what. This is kind of intentional - I've over-generalised it. Sure, it could guess from the attribute types (where present), but that would be error-prone. Especially since, in this case, the xspot actually has 2 colour changers in it (one might assume that once you patch it into a console you'd want to use the CMY one by default). Related to this, there's no way to work out what sort of priority the attributes are in (e.g. maybe you'd want some of the attributes in a "fixture options" screen).

 

Secondly, there's a load of amusing things going on with channels changing their purpose depending on other channels, and I'm not quite sure how to about fixing that. Maybe "ignore it" is the best method.

 

The shutter channel on the xspot also changes into an "effects" channel when another channel is changed, but the effects on that are predominantly one-shot things like lightning, so they could be implemented as functions. On second thoughts, this sounds like a decent way to do it.

 

But it's more of a problem for stuff like gobo wheel spinning, where the "gobo index" channel changes into a "spin speed" channel depending on the setting of the "gobo mode" channel. Fun.

 

Comments?

 

edit:

 

I'm thinking along the lines of using XML for the actual definition files, which will make it very portable and easy to parse on many different platforms.

<{POST_SNAPBACK}>

 

Looks like we're thinking along the same lines <_<.

[ben.suffolk]

Secondly, there's a load of amusing things going on with channels changing their purpose depending on other channels, and I'm not quite sure how to about fixing that. Maybe "ignore it" is the best method.

 

Hmm, thats going to be quite an interesting issue to solve, but one that I think does need solving if possible, as opposed to ignoring it <_<

 

I'm thinking along the lines of using XML for the actual definition files, which will make it very portable and easy to parse on many different platforms.

<{POST_SNAPBACK}>

 

Looks like we're thinking along the same lines :unsure:.

 

Thats a good start to a join effort I feel :P

 

Some XML parsers are not great at keeping things in order, so for the macro definition it would be better to have numbered steps I think e.g (sorry the indentation does not work here) :-

 

<function name="Lamp On">

<step number="1">

<DMX channel="14" value="85"/>

</step>

<step number="2">

<wait time="1">

</step>

<step number="3">

<DMX channel="6" value="0"/>

</step>

</function>

 

Ben

[tuxlux]

Secondly, there's a load of amusing things going on with channels changing their purpose depending on other channels, and I'm not quite sure how to about fixing that. Maybe "ignore it" is the best method.

 

Hmm, thats going to be quite an interesting issue to solve, but one that I think does need solving if possible, as opposed to ignoring it ;)

 

As mentioned in the past I'm writing software for design/control -- my thoughts were to separate out to some extent "attributes" in the contol program and then worry how they mapped onto DMX channels at the final output stage. Then, its fairly easy at the mapping stage to use the changed attribute to select the state of a FSM (finite state machine) to determine what the output should be.

 

I'd also thought that most fixtures consisted of a selection of "common standard attributes" e.g. position, brightness, etc.... which could be handled specifically and then more rare ones, which were all basically a sliding scale, a set of discrete choices or a combination of both. Then if necessary it could be possible that a DMX channel could be split into 2 user controls.

 

I'm thinking along the lines of using XML for the actual definition files, which will make it very portable and easy to parse on many different platforms.

<{POST_SNAPBACK}>

 

Looks like we're thinking along the same lines ;).

 

Thats a good start to a join effort I feel :)

 

Some XML parsers are not great at keeping things in order, so for the macro definition it would be better to have numbered steps I think e.g (sorry the indentation does not work here) :-

 

<function name="Lamp On">

<step number="1">

<DMX channel="14" value="85"/>

</step>

<step number="2">

<wait time="1">

</step>

<step number="3">

<DMX channel="6" value="0"/>

</step>

</function>

 

Ben

<{POST_SNAPBACK}>

I think the above is probably a good start. For the functions, would it be useful to define things in terms of attributes too (rather than just raw DMX?) e.g.

<function name="Lamp On">

<step number="1">

<brightness scale="percent">100%</brightness>

</step>

<step number="2">

<DMX channel="6" value="0"/>

</step>

<step number="3">

<brightness scale="byte">127</brightness>

</step>

</function>

 

The above also doesn't look that difference from a definition of a scene/chase either does it? So whether it could be possible to extend the schema to cover all situations?

 

I'd also been thinking along lines of using xml, but also to describe all types of fixures and entire lighting rigs. I think it would be good if it was possible to come up with schemas to cover

 

the layout of a rig,

fixture attributes/properties,

a patch,

cues/chases,

 

I'd be very interested if people could agree at least a basic rough format (since xml can always be extended)

[jfitzpat]

Secondly, there's a load of amusing things going on with channels changing their purpose depending on other channels, and I'm not quite sure how to about fixing that. Maybe "ignore it" is the best method.

 

Hmm, thats going to be quite an interesting issue to solve, but one that I think does need solving if possible, as opposed to ignoring it :)

 

 

It's not directly applicable, but you might want to look at how we handled this with our 'Mode Control'. Basically, we kept it to two cases. Case 1, one channel is used for multiple functions. A good case of this would be a shutter channel. Often you will see open/close, strobe (with speed), ramp open-snap shut, random, etc., all on the same channel.

 

Depending on 'mode', the relavant portion of the control range is represented appropriately (open/closed, speed, etc.)

 

Case 2, one channel impacts the effect of one or more others. Fixtures with a color mode, or gobo modes are a good example of this. For example, in some gobo modes, two channels work as a 16 bit value for index and a third channel may control gobo selection. In another mode, the MSB of index becomes a control over speed...

 

Again, depending on 'mode', the related channels are displayed and range limited appropriately.

 

We also use mode to impact how groups of settings fade and sum. For example, if you crossfade between a feature on the top range of a channel to a feature on the bottom range of the channel, you do not go through the other features on the channel that may lay inbetween. Similarly, when you use settings additively, the summing does not inadvertantly push the fixture out of mode (ex. When you sum ramp-open with ramp-open, the cues will work additively to the extent that ramp-open speed will increase, but will clip at max for that range - that is, you won't inadvertantly cross over into ramp-closed).

 

Again, it is not completely applicable, since it sounds like you want to map fixtures to common controls, but conveying mode in your fixture definitions might still make sense so your controller can be intelligent about fading, etc.

 

-jjf

[tuxlux]

and further slightly separate thoughts (since the above is getting crowded) -- I'd been working on a common "connection system" to do for lighting what JACK does for sound -- you have various output drivers (e.g. custom/DMX4Linux/ethernet/etc) and various input drivers (e.g. a wing etc) and everything can be routed into everything else.

 

e.g. a beat detector in xmms/winamp could step through a chase, whose output could be dimmed with a fader on a wing, or the type of chase set on another fader, while the colour could be set in another gui control application, and the results visualised by a visualiser etc....

 

And as mentioned above xml for representing the physical design for a show

lighting design representation xml

 

Comments on any of the above?

[Russ]

Comments on any of the above?

<{POST_SNAPBACK}>

 

Yes, Yes, Yes. That's exactly what I was thinking.

 

Also, that's quite a nice domain name, considering I just registered http://openlx.info.

 

We should probably move this off to a mailing list there, until then feel free to use the wiki which I just set up.

[ben.suffolk]

I'd been working on a common "connection system" to do for lighting what JACK does for sound

 

Have a look at PIOS, a mac bit of software that is a DMX patching system

 

Ben

[Russ]

In lieu of me setting up a mailing list, which I shall do shortly, here's some more discussion:

 

The above also doesn't look that difference from a definition of a scene/chase either does it? So whether it could be possible to extend the schema to cover all situations?

<{POST_SNAPBACK}>

 

The issue with that is that you need some functions to output exact DMX values, as part of a command. In that case it makes much more sense to me to put the exact values in there. Having a function such as that defined as a chase seems semantically wrong to me.

 

My initial draft of the definition had <colour>, <brightness>, etc tags, instead of the attribute tags, but I decided it would be better to generalise those further. I can see what you're trying to do with the JACK-style thing, but in that case I wonder if you'd need two fixture-definition files: one on the output stage to map attributes to real DMX values, and one at the controller stage to do stuff like set up the UI for various attributes (such as modes). That starts screaming overcomplexity to me, but it would be interesting to discuss.

 

Again, it is not completely applicable, since it sounds like you want to map fixtures to common controls, but conveying mode in your fixture definitions might still make sense so your controller can be intelligent about fading, etc.

<{POST_SNAPBACK}>

 

I see what you're saying there, maybe if you had a <mode> tag you could do something like:

 

<mode id="gobospeed">

...attribute definitions for gobo spin speed mode...

</mode>

<mode id="goboindex">

...attribute definitions for indexed gobo mode...

</mode>

 

<attribute>

<name>Gobo Mode Selection</name>

<select>

<item min="0" max="32"><setmode mode="goboindex" /></index>

<item min="33" max=64"><setmode mode="gobospeed" /></index>

</select>

</attribute>

 

Which sounds somewhat sensible. Obviously implementation starts to get slightly tricky then, but I think a construct such as can do more than any console currently on the market can (correct me if I'm wrong).