In the file vsttypes.h, the ParamID type is defined to be uint32. However, in the validator’s Scan Parameters test each parameter ID is implicitly casted to a int32 and the validation fails if this int32 < 0, ie when the uint32 parameter ID has its high-order bit set (scanparameters.cpp line 102 in VST SDK 3.6.13). Something similar happens in the ParameterContainer helper class’s addParameter method (vstparameters.cpp line 427). Is there a reason why we should not be setting the high-order bit of the uint32 parameter IDs like the SDK code is suggesting in these places?
Granted, 31 bits is a lot of bits to play with for a parameter ID, though I was wondering if this is a bug or there is a reason to consider parameter IDs with the high-order bit set as incorrect. Effectively, if you want to pass the validator, this reduces the amount of parameter IDs available to 2^31, half of the 2^32 figure quoted in the VST3 SDK documentation.
For example, I have seen code where certain parameter IDs are allocated from the top of the ParamID range downwards (eg reserving space for MIDI CC message parameters) which have failed in the validator as it thinks these IDs are negative due to the cast of the ID from uint32 to int32.