RTAS Wrapper's parameter values inconsistency


Hi Jules,

I have noticed that there are some inconsistencies and lacks in the RTAS wrapper, namely the JucePluginControl class.

  • The ConvertStringToValue and GetValueString are not symmetric: GetValueString asks the AudioProcessor class to convert the value, whereas ConvertStringToValue doesn’t.
  • GetValueString asks for a string version of the value given in parameter whereas the current implementation answers the string version of the current parameter value.

Do you have any improvements waiting to be committed or do I propose some hack for this? I’m encountering issues with EUCON controllers (parameter values), and I suspect that this is what causes them.


Haven’t got any thoughts on that myself, and haven’t looked in that code area for a long time - happy to hear any suggestions for improvements!


You will find the patch attached to this message.


Moreover, in the “Debug” menu of the RTAS plugin UI toolbar (cmd-clic on the automation button in Pro Tools), it can be seen that the number of steps of the continuous value is 1. I tracked this to the following line in the RTAS wrapper:

0xffffffff’s value as long on 32bit is -1

I have changed this value to 0x7fffffff and the menu now shows 2147483647 steps.

I think this is one more little bug which prevented control surfaces to handle juce RTAS plugins’ parameters.


Possibly related: http://www.rawmaterialsoftware.com/viewtopic.php?f=8&t=10508


Here is my current diff (with additional fixes) for page tables and control surfaces in RTAS. For the moment, everything looks fine using the Pro Tools debug menu, but is not yet tested with actual hardware; I’ll keep you posted as soon as it is validated.


Changing the number of steps seems like a good idea, but if a plugin gets recompiled with the new value, surely any values that were saved in a pre-existing project will be incorrect when re-loaded?


Actually, I don’t think so: the range of the parameters is 0-1 and does not change, right? I think the number of steps is used by ProTools in order to quantize the number of possible values in that range for automated parameters (and it hints so by the fact that it appears a -1 when you use 0xffffffff which is a negative number. Probably the range gets divided by the number of steps somewhere, and no proper sign handling is performed)


Well, it depends whether PT saves its values as the original long ints, or scaled as floats. And I think the only way to know the answer would be to test it.