New PID "Slot Labels" - E1.20 RDM (Remote Device Management) Protocol Forums

este_ · August 1st, 2014

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".

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search
Display Modes
Switch to Linear Mode Switch to Hybrid Mode Threaded Mode

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
Filling Device Labels to 32 chars is an error?	este_	RDM Interpretation Questions	14	June 13th, 2013 02:35 PM
Refreshing "parameter_description" ?	theguenni	RDM General Implementation Discussion	7	March 3rd, 2012 08:06 PM
Refreshing "parameter_description" ?	theguenni	RDM General Implementation Discussion	0	February 29th, 2012 02:36 PM
Slot Label Code	anstein	RDM General Implementation Discussion	1	August 10th, 2006 02:06 PM

August 1st, 2014	#4
este_ Junior Member Join Date: Jan 2010 Location: Germany Posts: 24	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".