RTAS Wrapper requests

[railjonrogut]

Wondering if Jules would consider adding these to JUCE for RTAS?

BYPASS BUTTON

In AppConfig.h add

#ifndef  JucePlugin_RTASCanBypass
#define  JucePlugin_RTASCanBypass          0
#endif

and in RTAS_Wrapper.cpp in the method CreateEffectTypes() change it to:

if (JucePlugin_RTASCanBypass)
                type->AddGestalt (pluginGestalt_CanBypass);

========================

MULTI-OUT

In AppConfig.h

#ifndef JucePlugin_RTASMonoAuxOutputs #define JucePlugin_RTASMonoAuxOutputs 0 #endif #ifndef JucePlugin_RTASStereoAuxOutputs #define JucePlugin_RTASStereoAuxOutputs 0 #endif

Usage: Set the Aux Outputs values as desired (set to 0 will create no Aux Stems), for example:

#ifndef JucePlugin_RTASMonoAuxOutputs #define JucePlugin_RTASMonoAuxOutputs 6 #endif #ifndef JucePlugin_RTASStereoAuxOutputs #define JucePlugin_RTASStereoAuxOutputs 3 #endif

In juce_RTAS_Wrapper.cpp

add:

for class JucePlugInProcess add the method:

[code]
int getTotalNumOutputs()
{
int outs = GetNumOutputs() + GetNumAuxOutputPorts();

    return outs;
}[/code]

for class JucePlugInProcess modify EffectInit():

        SFicPlugInStemFormats stems;
        GetProcessType()->GetStemFormats (&stems);

        juceFilter->setPlayConfigDetails (fNumInputs, fNumOutputs,
                                          juceFilter->getSampleRate(), juceFilter->getBlockSize());
    
        // Addition & changes for Multi-Out:
    
        int output_num;
        int base_port_num;
    
        for (int k=0; k < JucePlugin_RTASMonoAuxOutputs; k++)
            {
            output_num = k+1;
            base_port_num = output_num;
            
            char name[cAOSPortStrSize] = "Mono";
            
            AppendOutputPortNumToName(name, output_num);
            
            AddAuxOutputStem(new CAOSInfo(ePlugIn_StemFormat_Mono, base_port_num, name));
            }
        
        for (int k=0; k < JucePlugin_RTASStereoAuxOutputs; k++)
            {
            // This names the stereo output starting at "Stereo 1" -- You may wish to change
            // this to start after int nb_main_outputs = GetNumOutputs();
            // as in the previous post in this thread

            output_num = k+1;
            base_port_num = output_num;
            
            char name[cAOSPortStrSize] = "Stereo";
            
            AppendOutputPortNumToName(name, output_num);
            
            AddAuxOutputStem(new CAOSInfo(ePlugIn_StemFormat_Stereo, base_port_num, name));
            }
    
        juceFilter->setPlayConfigDetails(fNumInputs, getTotalNumOutputs(), juceFilter->getSampleRate(), juceFilter->getBlockSize());
     
        :

in handleAsyncUpdate() change the line:

[code]
// Change for Multi-Out:

        // juceFilter->setPlayConfigDetails (fNumInputs, fNumOutputs, sampleRate, mRTGlobals->mHWBufferSizeInSamples);
    
        juceFilter->setPlayConfigDetails (fNumInputs, getTotalNumOutputs(),
                                      sampleRate, mRTGlobals->mHWBufferSizeInSamples);[/code]

in bypassBuffers() change the method declaration to:

and in the method change the line:

[code]
// Change for Multi-Out:

    // for (int i = fNumOutputs; --i >= 0;)

    for (int i = getTotalNumOutputs(); --i >= 0;)[/code]

in class JucePlugInGroup in the method CreateEffectTypes() add:

[code]
type->AddGestalt (pluginGestalt_CanBypass);
type->AddGestalt (pluginGestalt_SupportsVariableQuanta);

        // Addition for Multi-Out:
    
        if (JucePlugin_RTASMonoAuxOutputs || JucePlugin_RTASStereoAuxOutputs)
            {
            type->AddGestalt (pluginGestalt_DoesntSupportMultiMono);
            type->AddGestalt (pluginGestalt_SupportsAuxOutputStems);
            }
    
        ////////////////////////////////////////////////////////
    
        type->AttachEffectProcessCreator (createNewProcess);[/code]

Thanks,

Rail

[jules]

Thanks!

Sure, an option to disable bypass makes sense, I’ve added that.

The aux stuff is annoying, because what I should do, if I ever have the time to look at it, would be to implement a general aux system for all plugin formats, not just RTAS. So although your changes look fine, I can’t add them, because they’d just need to be removed again (breaking everyone’s code) when the cross-format system gets implemented…

[ckk]

What about adding getNumAuxChannels and getAuxSampleData to AudioSampleBuffer?
Together with some AuxChannelConfiguration (maybe not visible in the Introjucer and initialised with {0, 0} as long as it isn’t fully supported) this wouldn’t break any existing code and would also allow adding sidechain support at a later time.

Chris

[jules]

[quote=“ckk”]What about adding getNumAuxChannels and getAuxSampleData to AudioSampleBuffer?
Together with some AuxChannelConfiguration (maybe not visible in the Introjucer and initialised with {0, 0} as long as it isn’t fully supported) this wouldn’t break any existing code and would also allow adding sidechain support at a later time.
Chris[/quote]

That could be a good idea, but I don’t have the energy to explore it right now…

[TheVinn]

That could be a good idea, but I don’t have the energy to explore it right now…

I’ve noticed that this is a common theme in the last few months. My preference of course is to see energy directed towards improving the JUCE library instead of the tools (Projucer?)

[railjonrogut]

[quote=“jules”]Thanks!

Sure, an option to disable bypass makes sense, I’ve added that.

The aux stuff is annoying, because what I should do, if I ever have the time to look at it, would be to implement a general aux system for all plugin formats, not just RTAS. So although your changes look fine, I can’t add them, because they’d just need to be removed again (breaking everyone’s code) when the cross-format system gets implemented…[/quote]

Thanks - very understandable.

Cheers,

Rail

[railjonrogut]

[quote=“jules”]Sure, an option to disable bypass makes sense, I’ve added that.
[/quote]

Just checked the tip - you may want make the default 1 instead of 0 – I’m sure it’ll be more common to want the Bypass enabled.

Cheers,

Rail

[jules]

[quote=“Rail Jon Rogut”]Just checked the tip - you may want make the default 1 instead of 0 – I’m sure it’ll be more common to want the Bypass enabled.
Rail[/quote]

No… the flag is JucePlugin_RTASDisableBypass

[railjonrogut]

[quote=“jules”][quote=“Rail Jon Rogut”]Just checked the tip - you may want make the default 1 instead of 0 – I’m sure it’ll be more common to want the Bypass enabled.
Rail[/quote]

No… the flag is JucePlugin_RTASDisableBypass[/quote]

Aah… gotcha… I just took a quick look at the commitdiff but didn’t see you’d changed the #define name.

Thanks

Rail

[Exponential_Audo]

This topic gets very close to a minor issue that’s bugged me for some time. The RTAS (and AAX) bypass is a problem because it doesn’t pay any attention to the propagation delay reported by the plugin. This means that delay compensation works fine right up until the time somebody hits the bypass button. It’s a minor–but consistent complaint–I’ve run into. Turning off the bypass button (as I assume JucePlugin_RTASDisableBypass does) is one solution, but it would be helpful to have an overloadable function for bypass. I’ve looked through Juce documentation to find such a solution, but to no avail. So I’ll show my considerable ignorance here and ask about it.

[railjonrogut]

Hi Jules,

Can you add the same Bypass for AAX:

#ifndef  JucePlugin_AAXDisableBypass
#define  JucePlugin_AAXDisableBypass       0
#endif

In createDescriptor() in juce_AAX_Wrapper.cpp

properties->AddProperty (AAX_eProperty_CanBypass,           !JucePlugin_AAXDisableBypass);

Thanks,

Rail

[jules]

Good idea, thanks!

[yairadix]

@Mikey

This topic gets very close to a minor issue that’s bugged me for some time. The RTAS (and AAX) bypass is a problem because it doesn’t pay any attention to the propagation delay reported by the plugin. This means that delay compensation works fine right up until the time somebody hits the bypass button. It’s a minor–but consistent complaint–I’ve run into. Turning off the bypass button (as I assume JucePlugin_RTASDisableBypass does) is one solution, but it would be helpful to have an overloadable function for bypass. I’ve looked through Juce documentation to find such a solution, but to no avail. So I’ll show my considerable ignorance here and ask about it.

+1

Here’s a patch for this issue.

soft bypass support

Seems to do the trick in PT for proper latency.
The VST+AU parts were added for completeness’s sake as the docs seem to mention this issue and so some hosts may act like PT (though Logic and Cubase seem to not pass the samples through the plugins at all when bypassed). The AAX part is untested.
Cheers, Yair

[Exponential_Audo]

Hey thanks! That’s just what I was hoping for. Jules, can you pop it in?

[jules]

Thanks, I’ll take a look today!

[jules]

Many thanks, that all seemed to make sense, I’ve done some merging it’s checked-in if you want to try it!

[Exponential_Audo]

Thanks Jules! I’ll give 'er a shot.

[Pluggy]

Any updates on this? Just ran into the same latency compensation issue in bypass today…

Also need to know, when I am in bypass to clear various buffers, so I am not sending out historic audio from buffers when bypass is turned off.

[yairadix]

[quote=“Pluggy”]Any updates on this? Just ran into the same latency compensation issue in bypass today…

Also need to know, when I am in bypass to clear various buffers, so I am not sending out historic audio from buffers when bypass is turned off.[/quote]

Jules added (it’s in the git tip) a virtual method for plugins to specify what happens during bypass: processBlockBypassed.

You should override it to create the same latency processBlock creates (which PT compensates for) and also any transitions you may want to make between bypassed and wet.

[Exponential_Audo]

It took me a couple of days to get to the new bypass hook, but I can report that it works. That gets at least one persistent customer off my back!