Fixture Identity (ANSI E1.20)

ANSI E1.20 – 2010, Entertainment Technology – RDM – Remote Device Management over DMX512 Networks is now public
(attached a copy).
at page 120-121 (Appendix C) are listed Slot informations.
they've listed some category (Intensity/Movement/Color/Image/Beam/Control) and some functions.

here's my question:
according to your understanding of the paper and to your moving head practice, is it a 'safe assumption'/'good start' to use these category/functions for the incoming fixture part of :Light?

++
nicolas

Hello,

Je n'ai pas la force de répondre en anglais ce samedi matin…

Ça me semble un bon départ, les choses à bien différencier sont les types de valeurs avec les types de paramètres (séparer le "FINE" et "COARSE" [type de valeur] du "PAN" [paramètre]) (CF Table C-1).

Le nombre de paramètres évoluera mais, la liste (Table C-2) comprend les paramètres les plus fréquemment usités.

Bon week-end.
Willy.

@willy,
merci de ta participation à ce sujet, ça va être un bon morceau....

donc pour résumer, à chaque paramètres de C-2 on doit pouvoir associer un type de valeur de la table C-1.
l'example du Pan est le plus simple où on peut assigner un type Fine (le ST_PRIMARY à savoir le paramètre lui-même étant le Coarse)
après, tous les types n'ont pas de corrélation immédiate avec tous les paramètres, le type ST_SEC_ROTATION par example n'a pas lieu d'être pour le paramètre Movement->Pan.

après la sortie de la 3.0.15 (la semaine prochaine), je pense pouvoir rapidement vous proposer une beta avec les fonctions de création de bibliothèque pour les moving heads....

++

Keep in mind that some slots may have multiple types .

For instance, my moving heads have a channel (slot) that , from 0-100, controls intensity , from 101-180, it's strobe, ...

On of the most important functions, when working with moving heads and scanners, is that the Grand Master only changes the levels on 'intensity'-channels (slots). That goes for 'blackout' as will. And for 'solo' on the SubMasters. You don't want the heads/mirrors/ to move.

Best regards,
Noël

@nico

C'est ça, à noter qu'il existe certains asservis qui ont un type de paramètre en "ULTRA" (Plus fin que "FINE").
J'essaye dès que je rentre sur Lyon de commencer une collecte de doc d'asservis (Je devrais pouvoir chopper les doc des VL (1000 et 2000), Martin Viper, Robin Robe (WashLed, MMX, 600E)).

Sommairement un fixture file ressemblerait à ça :
- Fixture
-- Model
-- Manufacturer
-- Mode
- Channels
-- 1
--- Function: Position/Pan
--- Role: Coarse
-- 2
--- Function: Position/Pan
--- Role: Fine
-- 20
--- Function: Control
--- Role: Control
---- 1-10 Reset
---- 11-20 Lamp On
---- 21-30 Lamp Off

++
Ben.

@Noel,
does the word 'Slot' is widely spread and a common word (instead of channel)?
does 'Slot' is a dmx address or a channel address ?

@Ben,
j'ai l'impression que dans le fixture file, il faut lister les paramètre/type et que dans un deuxième temps, lister les mode opératoires et du coup l'assignation des channels.
genre:
- Fixture
-- Model
-- Manufacturer
--- Function: Position/Pan
--- Function: Control
--- Role: Control
---- 1-10 Reset
---- 11-20 Lamp On
---- 21-30 Lamp Off
---Mode
----6CH

---

ch1 = .....

---

ch2 = .....
etc....
----9CH

---

ch1 = ....
etc...
----11CH

(ça ressemble un peu à de l'homéopathie )

++

Slot is the word that is sometimes (often?) used to define the 'offset' from the 'main' channel.
The main channel is the DMX-channel that is, on the fixture, set with DIP-switches, or in the menu.

so, Slot 0 is the first (main) channel.
Slot 1 is the next channel.
...

To keep the fixture personality files simple, I would use a separate file per mode.
e.g.
ADJ-REVO4-4CH
ADJ-REVO4-256CH

By doing that, only the channels (slots) and function needs to be described in the file
e.g.
Slot 0,Pan Course,Control
0,255, Pan
Slot 1,Pan Fine,Control
0,255, Pan
Slot 2,Gobo, Control
0,63, Gobo1
64,127, Gobo2
128,191,Gobo3
193,255,Gobo4
Slot 3,Intensity,Intensity
0,255,Intensity

(in this case, the title of the file includes : Manufacturer, Model and Mode) [ MMM ]
(yep, it's a .csv file. But .xml would work also, of course.
If a line starts with 'Slot', the parameters are slot number,name,role. If not, it's "min,max,function')

Best regards,
Noël

@nico
Tu as raison, c'est moins redondant.
Du coup pour un paramètre [pan]

-- Function: Position/Pan
--- Slot 0
---- Type: Coarse
--- Slot 1
---- Type: Fine
-- Function: Control/Fixture control
--- Slot 10:
---- Type: Control

---

1-10 Reset

---

11-20 Lamp On

---

21-30 Lamp Off

Les fonctions peuvent être hiérarchisées :
- Position
-- Pan
-- Tilt
- Beam
-- Iris
-- Shutter/Dimmer
- Focus
-- Focus
-- Zoom
- Color
-- Color wheel
--- 1
--- 2
--- 3
-- Color mix (CMY)
--- Cyan
--- Magenta
--- Yellow
-- Color mix (RGB[Y])
--- Red
--- Green
--- Blue
--- Yellow
-- CT
--- CTO
--- CTB
- Control
-- Fixture control

I would like to add another suggestion.

In the present version, DL considers everything to be a 'dimmer', and displays (in the circuit window) levels (0-99 FF)

It would be great, when using Moving heads, scanners, ... to display other information (instead of level), like : which colour, gobo...

For example, the channels that controls the gobos :
0 to 63 is Gobo 1 (a triangle, let's say)
64 to 127 is Gobo 2 (a square)
128 to 191 is Gobo 3 (a circle)
192 to 255 is Gobo 4 (a cross)

In the fixture personality file, it would be possible to add an extra parameter, that either defines a text, or a picture.
e.g. (with Text)
0,63,'Tri.'
64,127,'Sqr.'
128,191,'Crc'
192,255,'Crs'

or (with picture. Could be .jpg or .png)
0,63,Triangle.jpg
64,127,Square.jpg
128,191,Circle.jpg
192,255,Cross.jpg

Best regards,
Noël

@Noel,
initially, I thought to crypt fixture personnality files to prevent bad text modification....
what do you thought about that?

I think we should not have several file of a same fixture because we would have to handle too many files at the end...

your idea of pict or colors for a value is great but it takes long time (internally few microseconds...) to display other things but text.
and moreover it would be longer to define a personnality if we need to fill pict info for each parameters.

@Ben,
concernant la hiérarchisation, ok mais je pense qu'il faudrait suivre celle définie par la norme E1.20

++

My personal preference is text-files or .csv-files. The main reason is that they are easy to modify, outside the software (using a simple text-processor). The advantage is that people (like me ) can then easily modify the files to their personal preference. But you have a point that the downside of this is, that is me be TOO easy to modify things, and there is no error-checking.

As for using separate files :
My idea would be to build a library of (small) files, of which every DL-user can install ONLY the files that (s)he needs (in a folder "DL-fixtures", or so). You either have a small amount of big(ger) files, or a big(ger) amount of small files.

For example, for the (5) different fixtures that I have, I would need :
Generic_Dimmer_4CH
Eurolite_PAR56LED_6CH
Ayro_540_13CH
MARTIN_812_7CH
ADJ_REVO4_256CH

I would not need to install (or even build):
Ayro_540_5CH
Martin_812_5CH
ADJ_REVO4_4CH

Attached is a text that I assembled, with some ideas on how things COULD look like, and 2 examples.

Best regards,
Noël

@Noel

The advantage is that people (like me ) can then easily modify the files to their personal preference. But you have a point that the downside of this is, that is me be TOO easy to modify things, and there is no error-checking.

exactly!
but we'll have to decide because after it'll be a huuuuuge work to step back.
regarding crypto, everything is inside DL (for each platform) and works well, you know the pros and cons....

My idea would be to build a library of (small) files, of which every DL-user can install ONLY the files that (s)he needs (in a folder "DL-fixtures", or so). You either have a small amount of big(ger) files, or a big(ger) amount of small files.

with several mode inside a file, they won't be such big as parameters can be define at the beginning of the file and mode are define at the end.
and I think it could be easier to look for a manufactuer/type file than a manufacturer/type/ch file.

I think I understand why you prefer one file per mode when I read the doc you wrote about fixture personnality thanx for the doc by the way...)
one mode per file allow personnality to be define in a ascendant channel way, several mode per file don't.

regarding your doc, IMHO, modern hardware are able to parse string instead of letters very efficiently. Thus, It's more readable to use string instead of letters. but if we crypt files, we don't care so much...
also, please keep in mind that xml is easier to parse than text files because of the bounds. Text files (.csv, .txt) are very unclear regarding the end of a line(it's different in windows and MacOS). Thus, I really prefer xml...

if we don't go for crypto, establishing a kind of standard is a good thing.
we can pick up idea form usitt ascii where ! are comments and any character as " ,/;<=>@" are delimiters. if we can use that, it simplify parsing for me as I ever wrote some routines to parse them.

if we use pict as label, I think they should be encoded with base64 standard to avoid extra files attached to a personnailty.

for the hex/percent display, I propose that we let DL decide according to the 'Level Style Display' parameter in the setup. Once again it's easier for me.

-The Filenames contain Manufacturer, Model and Mode (MMM), separate by underscore (_)
e.g. Varytec_PrestigeII_256.txt

for the filenames, I agree with you except for the Mode and the type of the file.

thanx for involving in this discussion

++

First, I forgot to mention that my files use ' (apostrophe) for comment lines. But ! will do as well, of course. Point is, that it is very useful to have comments in the files, so the human being to needs to work with it, knows what to do. The computer simply skips those lines.

I don't have a problem with using .xml-files. The advantage is still that it can be modified (and even created) outside DL. I'm already doing that. I export my midi-setup to .xml, modify it, and import it again. The same approach would be possible for the fixture personalities.

Once Dl start using these files, a lot of users will need fixture personality files. In other forums, for DMX consoles, I see that you need to send a request to the developer, to get such file(s). THAT, we should avoid (you have better things to do ). But I, and a few others here, could help in building those files, for users that don't have the time/skills to do this.

Best regards,
Noël

First, I forgot to mention that my files use ' (apostrophe) for comment lines. But ! will do as well, of course. Point is, that it is very useful to have comments in the files, so the human being to needs to work with it, knows what to do. The computer simply skips those lines.

agree, whatever the method we choose, we should explain it in every files as comments (like DL do for ascii files).

Once Dl start using these files, a lot of users will need fixture personality files. In other forums, for DMX consoles, I see that you need to send a request to the developer, to get such file(s). THAT, we should avoid

I've ever designed the GUI for creating fixture personnality, and everybody can create a personnality on his own. No need to request the dev for adding a new one.

what come next is how fixture personnality' files are shared/downloadable, etc...
GitHub is nice as I can check request before ack.
if anybody can upload a file (eg replace an existing one with an update), problems can rise very quickly...
crypted files can prevent some parts of errors....

do DL distribution come with all created fixture personnality hardcoded?

++

what come next is how fixture personnality' files are shared/downloadable, etc...
GitHub is nice as I can check request before ack.
if anybody can upload a file (eg replace an existing one with an update), problems can rise very quickly...
crypted files can prevent some parts of errors....

Why not create an extra folder in the 'Download' area of DL ?

do DL distribution come with all created fixture personnality hardcoded?

I would keep those separate, as I don't think that DL should re-install the personality-files with every new version.
They should be handled like the patches, midi-setup, ...
In other words, everyone puts his own collection of files together.

Best regards,
Noël