Mike Suggested a simple fixture definition, but I am keen to go with a somewhat more fuller definition. This is something that I started working on some time ago, but have not worked on recently.
I started work on a wizard app to create the definition, but it needs a bit more work yet, esp around the gobo definition, and storing of the images in the file. If anyone fancies picking this up let me know. Although I suspect its fairly high priority once we start moving onto anything other than the the basics we are working on at the moment.
I started of with these initial assumptions.
For the moment I have started to work again on the fixtures and how they work within the framework. We can create some fixture definition XML by hand for the moment until we get chance to work again on the wizard app, or somebody else picks it up.
In the real world a fixture is simple a block of DMX channels. You set the fixtures address and it uses x channels up from this to for this block. In theory you might want to have multiple blocks of addresses (in the case of a set of scrollers for instance you have a block of channels for the dimmers, and a block of channels for the colours).
DMX Component
In the implementation I have defined a fixture as containing a number of base addressees. Each base address contains a number of channels. These 2 objects are used to represent the blocks of channels as described above.
The XML used to define a base address and its associated channels is:
<base name="baseAddress name">
<channel name="channel name" offset="0"/>
<channel name="channel name" offset="1"/>
</base>
|
Attributes
However in reality block of addresses gives us no real benefit, so a fixture is really a collection of unique attributes that define the behavior of the fixture. Each attribute is connected to one or more of the channels in order to send the relevant control to the fixture. (Note at this point don't confuse the fixture channels used as the definition with actual channels - wait until the fixture have been through Fixture Patching for any real channels to get involved).
The XML used to define an attribute is based on a common definition that is extended for each attribute type. The base XML is:
<attribute name="name" type="type">
<depends>
<range base="name" offset="x" .../>
</depend>
</attribute >
|
The depends element is optional, and is only used is an attribute requires a specific setting on another attribute to function.
There are 2 different types of attribute that all other attributes can be derived from. Both types of attribute need to be able to define and use ranges of values within a given channel. There are several types of range :
- Block - All values within the range have the same meaning.
- Proportional - The values within the range for a scale from zero to full.
- Single - There is only one single value in the range.
The XML used to define a range is :
<range base="name" offset="x" type="block|proportional|single"
start="x" end="x" [startName="name"] [endName="name"]/>
|
Proportional Attributes
The first attribute type is a proportional attribute. That is one where a value changes along a scale, for instance the intensity of a lamp, at one end of the scale it is off and at the other end it is full brightness. The sort of attributes that can be derived from this are intensity, movement, colour mixing etc.
Palette Attributes
The other type of attribute is one where there are blocks of values, and selecting a value within that block does something specific to the fixture. These I have called palette attributes, because you pick an entry from a palette. The type of attributes to be derived from a palette are generally found on wheels, like a gobo wheel, or a colour wheel.
The XML used to define a palette is:
<palette name="name">
<entry name="name">
<range base="name" offset="x" .../>
...
<data ..../>
</entry>
...
</palette>
|
A palette entry can optionally have a data element associated with it, this allows for instance a colour or a gobo image to be stored in the palette. At the moment only a colour data type exists, It is defined as:
<data type="color" red="0.5" green="1" blue="0"/>
|
It may be that in some cases an attribute needs to have a combination of both, for instance a gobo attribute may well have a palette element to select the gobo, and a proportional element to set the speed the gobo can spin.
Defined Attributes
So far I have the following attributes defined :
Also check out the API Documentation for these attributes.
There are still quite a few more than need doing, but this at least gives us enough to work on the other features like
Also I need to define how the Fixture Patching works, and how once patched we actually send data to the physical fixture.
Fixture XML
The overall fixture definition is a wrapper for the base addresses and the attributes. Its defines as:
<fixture name="name" manufacturer="manufacturers name">
<comment>
A comment about the fixture, this element is optional
</comment>
<base name="baseAddress name">
...
</base>
<attribute name="name" type="type">
...
</attribute>
</fixture >
|
The comment element is optional, and you can have as many base and attribute elements as you require. Whilst this is all that has currently been built, I would expect to be able to include palettes and macros in the definition as well.
