SELF_TEST_DESCRIPTION index range

[sblair]

Yes, we can add statements with "should" and "encourage" all day long unless there is someone during a Public Review cycle that screams bloody murder over it.

[tim_ecue]

Originally Posted by sblair

Yes, we can add statements with "should" and "encourage" all day long unless there is someone during a Public Review cycle that screams bloody murder over it.

"should" + advice that otherwise the test may not be detected by many control software systems would be sufficient.

Anything less than should + "otherwise it will not really work for your customers" is not strong enough.

I prefer "shall" given that no actual victims popped up so far. It is a strong statement and even if a few devices pop up, the number will be fairly limited and their IDs might even be explicitly published to enable control software vendors to add explicit support for these devices.

(Now I am already beyond bloody murder ... hehe)

[hamish]

(Now I am already beyond bloody murder ... hehe)

Hung for a sheep as a lamb.

I concur.

Now where is the rope?

[ericthegeek]

Originally Posted by tim_ecue

I prefer "shall" given that no actual victims popped up so far. It is a strong statement and even if a few devices pop up, the number will be fairly limited

Realistically we can't use that as an argument. We have to assume that there are RDM products we've never even heard of in far off lands whose language we can't speak and who've implemented RDM totally independently. They've never talked to a task group member, and probably don't even know the task group exists.

It's tempting to say "We don't know about anyone who does this, so we can change it without consequence". But we have to assume anything that can be done has been done.

[tim_ecue]

Originally Posted by ericthegeek

Realistically we can't use that as an argument. We have to assume that there are RDM products we've never even heard of in far off lands whose language we can't speak and who've implemented RDM totally independently. They've never talked to a task group member, and probably don't even know the task group exists.

It's tempting to say "We don't know about anyone who does this, so we can change it without consequence". But we have to assume anything that can be done has been done.

Hi Eric,

In general I would fully agree as standards need to be trustworthy. Still, this is a clarification, not a change. Furthermore, for this particular one I see little harm done for existing devices, but a great potential to fix a very critical issue. In the worst case, the control software will miss a test name. Still, since the parameter is not mandatory, it should anyway offer a way to trigger the test directly by number, so it should be still available for the user.

I am not sure if You truly recognize how bad this one really is. You have to keep in mind that we usually deal with very large installations that may have thousands to hundreds of thousands RDM fixtures. In practice this particular issue typically reduces performance (at least in the initial full examination of the fixture, which is crucial) for a fixture supporting that parameter to about 10% of what it would be if the numbers where consecutively ordered.

Since even without this catastrophic scenario slow performance is the major complaint customers have about RDM, this problem just breaks its neck because it makes it worse by a full order of magnitude. Our customers in the past have made it very clear, that poor RDM performance is a major reason for still using and even developing proprietary technology in place of RDM despite RDM being already available to them!

Best,
Tim