RTAS wrapper: UpdateControlValue

Audio Plugins
1

I’m having some issues with the RTAS wrapper, more specifically in this function:

ComponentResult UpdateControlValue (long controlIndex, long value)
    {
        if (controlIndex != bypassControlIndex)
            juceFilter->setParameter (controlIndex - 2, longToFloat (value));
        else
            mBypassed = (value > 0);
			
        return CProcess::UpdateControlValue (controlIndex, value);
    }

The first plugin that I’ve converted to RTAS showed no problems, but the second one did, and they seem to be caused by the extra call to setParameter that somehow changes parameters that shouldn’t be changed. Everything works fine when I comment out these lines. The only thing I can imagine at the moment is that the first plugin only has a rather small number of parameters, while the second one has 192… is there any known issue when going higher than 128 or so? Also, is this extra call really necessary (just asking :smiley: )?

2

You said “extra call to setParameter”, but I only see one call to that method…?

3

What I mean is that whenever setParameter is being called (by moving a GUI slider for instance), this function is being called afterwards, and calls setParameter again…

4

Well, you can’t just remove that callback, because otherwise if the host changes a parameter, your plugin won’t be told about it. If the host is calling it unnecessarily when you change a param, then that’s annoying, but not much I can think of that could be done without breaking something vital!

5

Ok, fair enough, only that when I change, e.g., parameter 74, that thing changes parameter 82. Very weird… could well be a bug on my side but I have no clue at the moment.
Edit: not only that, it changes parameter 82, 81, 80,… then a few in the 60s, totally random. Has really nobody ever had this issue?

6

Sounds like the host is doing that for some reason, but I can’t think why…

7

Ok, finally figured this out: for some parameters, the names were just empty strings since I didn’t want the user to fiddle around with them. Turns out that Protools seems to do its parameter bookkeeping not by index, but by name, and it f**s up when there’s no name so you really have to give proper names to each and every one of them… so keep this in mind!

8

Good discovery! I’ll add an assertion to help people in the future:

[code] void GetNameOfLength (char* name, int maxLength, OSType inControllerType) const
{
// Pro-tools expects all your parameters to have valid names!
jassert (juceFilter->getParameterName (index).isNotEmpty());

        juceFilter->getParameterName (index).copyToUTF8 (name, maxLength);
    }

[/code]

9

Just thought I’d add in that RTAS control names not only must be non-empty, they must be unique.

This is due to the underlying (and not visible to the SDK) control messaging scheme that coordinates GUI, automation, and external control surfaces; if you have multiple controls with the same name they will get each other’s update messages.

-Frank

10

I Suppose another way around this would be to append the index value to the parameter name, and then copy it. That way, even if two or more parameters share the same name, they would be stored along with their unique index so that changing one parameter will not affect the other. :slight_smile:

void GetNameOfLength (char* name, int maxLength, OSType inControllerType) const { String strParameterName = String(juceFilter->getParameterName(index)) + String("(") + String(index) + String(")"); strParameterName.copyToUTF8(name, maxLength); }
-Adel