You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We discussed this in today's E1.37-5 meeting and came to the conclusion that doing something like this is counter to the intent of the Parameter Metadata Language. The Parameter Metadata Language is intended as a complement to RDM--not a replacement. Encoding this information here is no longer just describing the PID, but is actually implementing it outside the realm of the RDM conversation. Beyond that, E1.37-5 specifically prohibits transmitting PIDs with the ESTA Manufacturer ID, because those definitions exist and can only be altered as part of the ratified RDM documents.
I don't disagree with your comment but... Is a manufacturer specific parameter definition providing labels like in the example above not implementing it outside the realm of the normal RDM conversation? If we are to take that route should labels not be omitted and a description parameter much the same as DMX_PERSONALITY_DESCRIPTION be used along side the parameter to provide its labels?
There is a plausible scenario where a manufacturer may want to write a manufacturer specific version of an E1.20 parameter, for example:
I've used the scope property referred to in #13, but do we think this should be a thing?
The text was updated successfully, but these errors were encountered: