Clarify zero indexed DMX Channel Numbering in Documentation and Error Messages

[WilliamsEC]

Something that got me very confused today. I noticed the dmxnet library is using 0-511 which maps to DMX Channel 1 - 512. So for instance the user or coder has to take the user channel 1 and then put that into channel 0 for it to control the correct fixture. Should this not be shifted within the library so that we are passing the correct channels down to the lowest level before transmission ?

[margau]

Hi,
I voted to count 0-indexed as usual in informatics. Actually, as the both values and channes are a 8-bit/9-bit value, that is the technically correct interpretation (I'm not sure what the standard says). When we are e.g. addressing an array with all channels, we also would use index 0 - 511.
Even if we would agree to change that, it is not feasible, as it would break backward compatibility/api consistency.
I'd therefore close this issue, feel free to comment if you have an idea how to solve this.

[WilliamsEC]

Hi, Thanks. I understand and that totally makes sense. It is just a issue as we have to remember to adjust the user data within the array down by 1 before we pass out but I'm guessing this must be how all DMX based programs are working then. The only issue will be if the library throws an error regarding the 0-512 channels.

throw new Error('Channel must be between 0 and 512');

Technically it is either 1- 512 which is the DMX channel or 0 - 511 which is the "indexed" channel. If this is an user message then it is conflicting as the user would expect a DMX channel of 1 - 512 if that makes sense.

The way I've fixed it now is that I take the user data and reduce the channel number by one and then pass it over. Just seems a bit dirty but it works. I would have to then error if someone passed a 0 channel (which they shouldn't anyway).

[margau]

So, maybe a clarification of the Error Message and the documentation would be a good Idea.

[ghost]

I created two pull requests to switch error messages in lib.js and added a hint in the notes block of README.

With this this issue should be closed as I think that we should not switch channel numbering to 1-512 for all function calls and then handle the drift in the library. But - if this is wanted from the community - I am willing to do a pull request for this, too.

[ghost]

Possibly we could use another config option to let the users choose the range of 0-511 or 1-512 for the channel numbers they input.
(Just an idea)