Refreshing "parameter_description" ? - E1.20 RDM (Remote Device Management) Protocol Forums

ericthegeek · March 3rd, 2012

This did get me thinking about the behavior of PARAMETER_DESCRIPTION. Because of the section 6.2.10.2 language, I'd previously said that to save time, you could send a GET PARAMETER_DESCRIPTION to one responder in the rig, and apply the response to all fixtures from the same manufacturer that declare support for that PID.

But the text only requires that they have the same "meaning", not the identical response. Different fixtures could have the same meaning, but have different values for Min/Max or similar.

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
Usage of PARAMETER_DESCRIPTION for manufacturer-specific PIDs	R.Schladör	RDM General Implementation Discussion	9	September 26th, 2018 12:04 PM
Refreshing "parameter_description" ?	theguenni	RDM General Implementation Discussion	0	February 29th, 2012 02:36 PM
Refreshing of paramters need Queued Messages?	berntd	RDM General Implementation Discussion	33	May 25th, 2010 02:09 PM
PARAMETER_DESCRIPTION data type semantics	tim_ecue	RDM Interpretation Questions	4	October 14th, 2009 10:47 AM

March 3rd, 2012	#6
ericthegeek Task Group Member Join Date: Aug 2008 Posts: 390	This did get me thinking about the behavior of PARAMETER_DESCRIPTION. Because of the section 6.2.10.2 language, I'd previously said that to save time, you could send a GET PARAMETER_DESCRIPTION to one responder in the rig, and apply the response to all fixtures from the same manufacturer that declare support for that PID. But the text only requires that they have the same "meaning", not the identical response. Different fixtures could have the same meaning, but have different values for Min/Max or similar.