Fixture exchange maps range values as relative percentage?

[DC3]

Can anyone tell me what are the advantages of fixture exchange mapping range values as relative percentage rather than absolute and is there an option to change it? If the matching functions are defined as 0-100% ranges then it makes no difference but when the ranges are different the results from mapping by relative percentage are less desirable to me when compared to absolute value mapping.

Example:

With the source fixture having a zoom definition of:

Code: Select all

<Function ID="1" Name="Zoom" Display="'%.1f°',5.5~47.6" Dmx="0~255"/>


And the destination fixture having a zoom definition of:

Code: Select all

<Function ID="1" Name="Zoom" Display="'%.2f°',12.00~40.00" Dmx="0~65535"/>


If a cue or palette has a zoom value of 14.0° for the source fixture, after fixture exchange the value for the destination fixture will be 17.63°, I would expect the zoom value to have remained unchanged at 14.0°?

Another example where this produces undesirable results is with framing blades. The blades of some fixtures cover just half of the aperture when fully inserted these I define as having an available range of 0-50%, others have their blades fully cover the aperture, these I define as having an available range of 0-100%. If a source fixture has a 0-50% range and a value of 50% in a cue or palette, if exchanged with a fixture that has blades with an available range of 0-100% the 50% in the original programming gets changed to 100% on the destination fixture because 50% on the source fixture is 100% of the blades available range.

There are many parameters where I would expect and prefer the mapping to be absolute, if the matching functions have ranges defined using different units then perhaps relative percentage is a better choice but I can't think of any other situation where absolute mapping would not be the preferred method?

Although I would not expect the visual result of absolute mapping to be exact, it can often be close enough and in a time crunch there would be no need to tweak it any further. I can work around the issue but having an option for absolute mapping would be better.

[niclights]

Personally I would say there is no advantage and that the way it is currently working is fundamentally wrong, either a bug or a flawed design. It is undermining the exchange function and one of the (arguably main) advantages of using calibrated/real-world display ranges where available. You can edit the mapping and this will be reused when exchanging between the same fixtures in the future but otherwise I cannot think of any way to change it.

I agree that where the source and target units are different then there might be an argument to try and find the equivalent value but where the units are the same the display value should be used (or presumably nearest available if out of range). I'm not sure if it needs to try and be clever and see if the display units are the same type or just always try and match the value regardless. In most cases I feel the latter would work ok (ie, percent 0-100 <> percent 0-100 or degrees <> degrees). On the occasions where they don't (for example percent <> degrees or percent <> Hertz) perhaps closest is still good enough.

As an aside I don't think fractional display values are currently supported. I'm fairly sure that your example:

Code: Select all

<Function ID="1" Name="Zoom" Display="'%.1f°',5.5~47.6" Dmx="0~255"/>

won't work or will result in errors. Instead I believe it needs to be something like:

Code: Select all

<Function ID="1" Name="Zoom" Display="'%.1f°',5.0~47.0" Dmx="0~255"/>

This is limiting and I hope it can be improved in the future.

[DC3]

Thank you for your thoughts and comments niclights. I agree that currently the way it is working is fundamentally wrong. It is strange that there are features or areas of the console that I would expect to work in relative percentages but it is working in absolutes then there are features and areas where I would expect absolutes to be used and it is working in relative percentages.

Relative mapping for different units could be useful, for example a shutter dialled into to strobe at 7Hz will probably be strobing significantly faster than a shutter dialled into strobe at 7% but these types of situations may be too rare to consider.

Fixture exchange has lots of bugs and issues some direct others related to it. As standard the results of fixture exchange are okay but with some planning, preparation and massaging you can get some very good results out of it, results that in some cases better anything else out there that I am aware of.

As an aside I don't think fractional display values are currently supported. I'm fairly sure that your example:

Code: Select all

<Function ID="1" Name="Zoom" Display="'%.1f°',5.5~47.6" Dmx="0~255"/>

won't work or will result in errors. Instead I believe it needs to be something like:

Code: Select all

<Function ID="1" Name="Zoom" Display="'%.1f°',5.0~47.0" Dmx="0~255"/>

This is limiting and I hope it can be improved in the future.

The example was a copy paste from a working personality file. There are two issues that I am aware of when using fractional values in personality files, they are:

1. Fractional values cannot be defined in the personality builder application. You can define the values and save the file but personality builder rewrites the values in a way which effectively renders the file corrupt and subsequently will not re-load the file and the file will not be recognised as a valid personality file by Titan OS so is unusable.

2. Show files containing personality files with fractional values will only load in the same version of Titan OS that the personality file was added or patched into the show on. Attempting to load a show file that contains personality files with fractional values into a newer version of Titan OS will load with errors, it sees the personality file as corrupt for the same reasons as personality builder and will not be able to load those fixtures. Without the fixtures in the show, all programming related to those fixtures is lost.

For point 1, I do not use personality builder, all my personalty files are created solely using a standard text editor so this issue is does not affect me.

For point 2, This is a little more problematic and one that does affect me, but I have a workaround to deal with it without too much extra effort.