Using ArtNet fixtures with fine channels

Hey everybody,
I can´t get a lighting fixture to work which uses a lot of 16bit channels.
I am pretty sure the OFL fixture definition is correct but score doesn´t seem to recognize the “xxx fine” channels in the mode definitions of the .json file.
I could work around it by just not using modes with fine channels, but i thought it might be an user error.

P.S. Thanks for this awesome freeware!


I think we don’t support 16-bit channels, at least I don’t remember implementing such a feature.
If you have some example of fixtures that do this and possibly some link to the specification I can look into doing that :slight_smile:

Uh that was a quick response :slight_smile: .
There are examples in the default library.
the spica-250m (fixture definition filepath:
for example should have fine channels for pan and tilt control
cut out from json file:
channel definition
“availableChannels”: {
“Pan”: {
“fineChannelAliases”: [“Pan fine”],
“defaultValue”: 32639,
“capability”: {
“type”: “Pan”,
“angleStart”: “0deg”,
“angleEnd”: “530deg”
“Tilt”: {
“fineChannelAliases”: [“Tilt fine”],
“defaultValue”: 32639,
“capability”: {
“type”: “Tilt”,
“angleStart”: “0deg”,
“angleEnd”: “280deg”

mode defenition:
“modes”: [
“name”: “16bit”,
“channels”: [
“Pan fine”,
“Tilt fine”,
“Pan/Tilt Speed”,
“Color Wheel”,
“Prism rotation”,
“Gobo Wheel”,
“Gobo rotation”,
“Shutter / Strobe”,

in score the fixture correctly launches with a default pan value of 32639 but the maximum is set to 255 and changing the maximum to 65025 doesn’t change the actual ArtNet output (I measured it with wireshark).
I’m not entirely sure what you mean with specification.
do you mean this :
open-fixture-library/ at master · OpenLightingProject/open-fixture-library · GitHub ?

16bit channels are often used for pan and tilt values so you have better control of where the lamp points to and to make the movement less steppy.
Also they can be pretty handy when using led lamps which often don’t dim smoothly in the low percentages.
I hope I’m not telling you obvious stuff :slight_smile:
if you would implement the feature you would have at least one happy customer :smiley:

Thanks! very precisely I’m looking for how the DMX frames should look on the wire: e.g. let’s say that you have a 16-bit value which is built of dmx channels 20 and 21: is the “coarse” data on channel 20 or on channel 21? this is the information I’m trying to find on internet haha. But i’ll assume they’re in the order given in the fixture file… and if it doesn’t work you’ll have to test and tell me because I don’t have any 16 bit DMX device to try sadly

Okay I did a tentative implementation, it’s there: Release Continuous build · ossia/score · GitHub . You will have to recreate the artnet devices however as until now they did not save the high resolution information, sorry :frowning:

Hey i did some first testing on your implementation :slight_smile:
Thank you for your quick response.
I think there are still some issues.
Here for example are the fixture definitions from the OFL homepage and the one out of score for the “spica 250m” in “16bit” mode

as you can see there are some channels missing.
In this example the “fine” and the “no function” channels.
In the json file the “no function” channels are translated as “null”.

the problem is that this also carries over to the actual ArtNet output.
Here is a screenshot of wireshark and score next to each other

as you can see i have Dimmer value corresponds to the 12th ArtNet address even though it should be the 16th.
I guess the “no function” parameters/channels one can just fix by stuffing any ol Attribute into the json file instead of the null lines.

Also after your changes the first three channels are not independent from each other anymore. I think they overlap like this.
Ch1 = Pan , Ch2 = Pan fine & tilt , Ch3 = Tilt fine & Pan_Tilt Speed (not entirely sure though)
I want to emphasize that i don´t have a problem with this behavior i will use Lamps without gaps in the Dmx addresses and in modes without fine Channels as i said earlier :smiley:
I thought it might be good to know that some Fixtures and Fixture modes out of the Library are not working as intended.
So thank you again for dedicating some time to my problem :slight_smile:
Maybe i’ll try looking into it myself - maybe i’ll learn coding this way :smiley:

Thanks for the detailed investigation! I did not know that Wireshark had such a cool DMX display, I’ll definitely use it to try to debug

Okay, got one of the bugs thanks to wireshark :slight_smile: for implementing the missing features, it’s a bit more work. If you (or someone else) is interested in looking into the code everything is in these files:

The parsing of the data structure from the open lighting json format is around here:

otherwise i’ll try to get to it by the end of the month, keeping you posted!

Got another bug fixed, null channels should be good now… please try in one hour-ish :slight_smile: it will have the commit message: “[dmx] Handle fixtures with jumps” in the changelog here
Release Continuous build · ossia/score · GitHub

Sorry for my late response i did some minor testing today just with wireshark and everything seems to be in order now.
I will do some more testing with actual fixtures.
Thanks a lot!!

I have 3 more minor issues and since i think i won’t learn coding fast enough, maybe you can do something about it.

  • i find it irritating that you can’t access ArtNet universe 0 (this one is really really minor since i normally start at universe 1)
  • in most programs dmx fixtures are not 0 indexed, neither the channelmodes are nor the 512 overall channels (this could lead to some confusion since you have to give the actual fixture a different address then in score)
  • when a fixture has a fine channel the max value still starts out at 255 so you have to manually give it the value 65535

as i said these are really minor since i can handle them myself, so thank you again. :smiley:
I will post again after testing with actual fixtures.