View Single Post
Old August 1st, 2014   #4
este_
Junior Member
 
Join Date: Jan 2010
Location: Germany
Posts: 24
Default

Peter, thanks for your comments which I appreciate.

You're right, choosing sub-device labels to circumvent this issue is not just a workaround; as soon a sub-device is using more than one slot it would no longer be possible to do it this way. The goal is to create a fader label, not a device label. I'm uncomfortable using sub-devices; that's why we disable sub-devices by default and let the user enable them (using our PID FF0F) when he feels this might make sense in his installation. Enabling sub-devices by default will always call for BLOCK_ADDRESS, which is badly supported (see the PID popularity contest, http://www.rdmprotocol.org/rdm-pid-popularity/ ) and cannot replace the START_ADDRESS PID. And: I know some guys, who even "don't like the BLOCK_ADDRESS PID".

You're also right, that slot labels could differ when the personality is changed. But there is no need to give the personality number when writing slot labels; simply set the personality, write the slot label and re-set the personality if needed. The responder should be smart enough to write personality-specific slot labels associated to a specific personality (or personalities..) if the responder supports this. Thus I do not feel there is a need to make things more complicated by adding additional parameters.

It would be enough to allow a SET for SLOT_LABELS.

Basically, there is no new command needed.
There is no new syntax needed.
There is no new format needed.

In case the responder does not feature write capabilities, it should NACK the request. That's all. If responders can't do that (because they did not know a SET SLOT_LABELS was possible), the command will time out. Same result.

I can't see any problem. So "let's make the world a little bit smarter".
este_ is offline   Reply With Quote