Have you considered using the rdm.openlighting.org model data to speed up/simplify fixture creation?

[peternewman]

We gather, but its not currently exposed on the webpage yet, slot data for the active personality when people run the model collector ( https://github.com/OpenLightingProject/ola/blob/master/tools/rdm/ModelCollector.py ). Here is some example data, or run it against the dummy responders for more:

https://github.com/OpenLightingProject/rdm-app/blob/63673d0778973c8267b006ae982f60a22a1691b2/data/model_data.py#L103

You could use this to generate a rough fixture profile for devices.

Alternatively you could look at converting QLC+ personalities: https://github.com/mcallegari/qlcplus/tree/master/resources/fixtures

[brunchboy]

Those are great ideas. The definitions would be lacking the geometric information Afterglow needs for its direction and aim cues, but they would be a great start, especially for big, tedious fixture capability lists. I think what I would want to do is write a tool that spits out a starting fixture definition, and encourage people to verify and flesh it out before submitting it for inclusion. That would be a great help to people who are new to Afterglow and Clojure. Thanks!

(Plus, it would let me benefit from the effort I already put into my QLC+ definitions, as well as everyone else’s!)

It would also be kind to write conversions in the other direction, in case someday there is a fixture that gets set up in Afterglow before QLC+.

[brunchboy]

@peternewman, I have been looking for documentation of the QXF format, and have not yet succeeded in finding any, not even an XML schema or DTD. Do you happen to know where this is documented?

[brunchboy]

OK, I think I will be able to reverse-engineer the QXF format well enough to get some useful results, but it would have been nice to start with solid documentation and a specification. It will be a little awkward to convert to Afterglow fixture definitions because I model some things fundamentally differently, but I have a plan. I’ve already determined that the only Group values used in all the QLC+ channel definitions are:

#{"Effect" "Intensity" "Pan" "Nothing" "Speed" "Colour" "Gobo" "Shutter" "Prism" "Beam"
  "Maintenance" "Tilt"}

So there is pretty good consistency. And I have figured out how multi-byte channels are represented, and should be able to piece that back together, and more or less tell what the basic color channels are, and figure out how heads are grouped.

Also, I have not forgotten your comments about the RDM model data. That will be interesting to explore someday too, but I am starting with QLC because I suspect that few of the early adopters of Afterglow are going to be the kind of people who can afford fixtures fancy enough to support RDM. 😊

[brunchboy]

All right! Translation of QLC+ fixture definitions has been implemented! It was more work than I expected, because I decided I wanted the auto-generated code to be clean, readable, and instructive as well as a good starting point. This will be really helpful, thanks again for the suggestion.