CURVE supported : implies CURVE_DESCRIPTION in supported parameters ?

[RenZO]

Hello,

I have those PIDS in SUPPORTED_PARAMETERS:
CURVE
OUTPUT_RESPONSE_TIME

Then, I also have the PIDS :
CURVE_DESCRIPTION
OUTPUT_RESPONSE_TIME_DESCRIPTION

According the E1.37-1, as these are "required", do we need to add *_DESCRIPTION PIDS in SUPPORTED_PARAMETERS, or not ?

As said in another post, E1.20 says in Section 10.4.1:
PIDs that are included in the minimum support list, indicated by the “Required” column of Table A-3, shall not be reported.

But in E1.37-1 we have for example :
CURVE_DESCRIPTION
* Support required only if CURVE is supported.

So what to do please ?

Thanks,
RenZO.

[ericthegeek]

We run into this question with all of the PIDs that are "conditionally required" (DMX_START_ADDRESS, PARAMETER_DESCRIPTION, etc.). You can make a legitimate argument both ways.

In the real world, declaring extra PIDs in the list of supported parameters is unlikely to break any RDM Controllers. Controllers have to assume that new PIDs will be added in the future, so the extra information should just be ignored.

Thus I would suggest including the _DESCRIPTION PIDs in the list of supported parameters.

[RenZO]

Thank you ericthegeek, that makes sense
I would say it's the same for DMX_PERSONALITY_DESCRIPTION, which is not "conditionally required" in Table A-3 but should be, and I often see it in supported parameters.

[ericthegeek]

It is possible to support DMX_PERSONALITY without also supporting DMX_PERSONALITY_DESCRIPTION. This would be a poor design choice, and would require the user to lookup what each personality means in external documentation, but it is allowed by the the standard.

The reverse is also true, you can support DMX_PERSONALITY_DESCRIPTION without supporting DMX_PERSONALITY. This might be desirable it a responder that has only one personality and wants to give that personality a name (i.e. "Standard Mode").

I'd discourage implementers from using either of these corner cases (If you support one PID, you really should support the other), but those implementing controllers should consider this possibility.