AUv3 Parameter Issues

I’m Currently running a beta test for my new iOS AUv3. A user has reported issues with automation tracking. Please see the attached screenshot of the automation for a “choice” parameter in Cubasis 2 (I’m told it doesn’t work in Cubasis 3). When I recorded this it started at the lowest value, before moving to a second value and then back to the lowest. The initial low value isn’t recorded which has led to this user saying “the automation doesn’t work”. Is this something that others have run into as a problem? Do I need to contact Steinberg and report this or is it likely I am doing something wrong?

EDIT: In Cubasis 3 its also not picking up all the parameter names, they are just listed as the plugin name, not the parameter. It’s not actually automating these at all. I’m wondering if this has something to do with parameter id (seems to happen with longer parameter ids)?


1 Like

I’m having the same issue here.
@DavidCNAntonia, have you figured out what’s going on?

@amethystdeceiver Yeah, I discovered that it wouldn’t pick them up properly if parameter id’s are too long. A little trial and error found that 9 characters is the maximum.

Hope this helps!

1 Like

Thanks for your response! Mine is only 7 chars long though… And yet I don’t have a slightest idea of why something like what you described is possible :face_with_monocle:

I’ve found something - pretty sure there is a bug in AUv3 wrapper that affects choice parameters. This needs to be fixed in processEvents():

case AURenderEventParameter:
case AURenderEventParameterRamp:
    const AUParameterEvent& paramEvent = event->parameter;

    if (auto* p = getJuceParameterForAUAddress (paramEvent.parameterAddress)) {
        setAudioProcessorParameter (p, paramEvent.value);
        // ^^^ MISSING NORMALISATION HERE ^^^, should be this:
        // auto normalisedValue = paramEvent.value / getMaximumParameterValue (p);
        // setAudioProcessorParameter (p, normalisedValue);

@t0m, can we please get it fixed? Should be quick to do

I don’t have Cubasis 3 at hand to check, but what certainly wasn’t working properly and now does with this change is mapping MIDI CC to parameters in AUM

Here’s a PR if you will:

No idea either, I had assumed it was something on the hosts end. Not too concerned however as I found the workaround.

FWIW, I have a Cubasis user reporting that everything is working as it should now that I’ve deployed the fix from my previous post. In my case the parameter had 40 choice options, so it was obvious it was reaching maximum too soon (at normalized value 1/40 instead of 1).

Seems logic as the regular AU does this

ComponentResult SetParameter (AudioUnitParameterID inID,
                                  AudioUnitScope inScope,
                                  AudioUnitElement inElement,
                                  Float32 inValue,
                                  UInt32 inBufferOffsetInFrames) override
        if (inScope == kAudioUnitScope_Global && juceFilter != nullptr)
            if (auto* param = getParameterForAUParameterID (inID))
                auto value = inValue / getMaximumParameterValue (param);

                param->setValue (value);

                inParameterChangedCallback = true;
                param->sendValueChangedMessageToListeners (value);

                return noErr;

        return MusicDeviceBase::SetParameter (inID, inScope, inElement, inValue, inBufferOffsetInFrames);

Yes. In fact, the AUv3 wrapper itself does this for regular parameter changes (but not for AURenderEvents in processEvents():

void valueChangedFromHost (AUParameter* param, AUValue value)
    if (param != nullptr)
        if (auto* p = getJuceParameterForAUAddress ([param address]))
            auto normalisedValue = value / getMaximumParameterValue (p);
            setAudioProcessorParameter (p, normalisedValue);

Thanks for reporting and suggesting a fix. We’ve pushed this in c492da9.

1 Like

Great, thanks for the quick response!