Apvts - "no default constructor"

Hi everyone,

I am having an issue where my juce::AudioProcessorValueTreeState apvts “does not have a default constructor”. How do I configure this for an apvts?

Thank you,
Andy

The AudioProcessorValueTreeState needs a backlink reference to the AudioProcessor to exist. So you need to supply that as argument, either in the header as default arguments in curly brackets (initialiser list) or in the member constructor list.

You add treeState (*this, undo, "PARAMETER", createParameterLayout()) to the constructor.

Have a look into this thread:

Thanks! I do have this in my constructor. I tried putting the code in my initializer list instead, and that did not work.

All I did was put {1,1}, {2,2} in the “Plugin Channel Configurations” section of the Projucer, and the apvts no longer is functional. If I take away {1,1}, {2,2}, the apvts works perfectly fine.

The bigger issue is that I am trying to ensure mono compatibility in Logic Pro, and I figured that doing the {1,1} thing would solve that. Maybe I’m looking at this from the wrong angle.

The legacy method of specifying channel layouts is probably what shot you in the foot. It triggers the macro mess in the generated to evaluate differently.

TBH I would remove the JucePlugin_PreferredChannelConfigurations conditional parts which makes it easier to read and debug. Instead I would implement the isBusesLayoutSupported(). This method is probed by the host and you simply have to return yes or no depending if you can handle the supplied BusesLayout.

Great! How do I implement isBusesLayoutSupported()?

Would I just delete this

#ifndef JucePlugin_PreferredChannelConfigurations
: AudioProcessor (BusesProperties()
                 #if ! JucePlugin_IsMidiEffect
                  #if ! JucePlugin_IsSynth
                   .withInput  ("Input",  juce::AudioChannelSet::stereo(), true)
                  #endif
                   .withOutput ("Output", juce::AudioChannelSet::stereo(), true)
                 #endif
                  )

and add this

#ifndef JucePlugin_PreferredChannelConfigurations
: AudioProcessor (isBusesLayoutSupported())

not quite. First you remove everything from the Projucer field PreferredChannelConfigurations, reactivates the code in this ifndef of the constructor.
You supply now the default BusesProperties.

Now scroll down and you will find the isBusesLayoutSupported() function. This one also was reactivated by removing the said Projucer field.
This is getting called with all sorts of bus configurations. Your job is to return only true for the ones you want to support.

This is the original thread with documentation

The APVTS is not included in that doc, but it is just an additional argument to your processor.

I have commented out the JucePlugin_PreferredChannelConfigurations in all places I can find, and it looks like the default isBusesLayoutSupported() overide is going to work for what I’m looking for.

The error Logic is giving me is on a 1 channel, 512 frame render test, and it says the test fails at line 245 in juce_AudioBlock.h (243 - 247)

AudioBlock getSingleChannelBlock (size_t channel) const noexcept
{
    jassert (channel < numChannels); // <- This guy
    return AudioBlock (channels + channel, 1, startSample, numSamples);
}

This leads me to believe that the channel being compared is some how larger than the numChannels, even though my plugin is supposed to compatible with mono. Is it possible my plugin is always stereo, and I need to do some work to make it mono compatible? Or should the framework take care of converting between the two for me?

Check in the debugger: what is channel, what is numChannel.
However, your code is calling getSingleChannelBlock()? directly or indirectly
Could it be that your code doesn’t respect the actual channel setup?

Highly possible. I don’t know how to go about making my code respect the actual channel set-up. I will test the other parameters to make sure I know what I am looking at.

Edit: numChannels = 2, channel = 0 or 1. This must mean that the code is not respecting the actual channel set-up, right? Because 1 !< 1, if that were the channel and numChannels respectively.

I got it! I was using dual mono processing with an element of my plugin, and that made it incompatible with mono, as channel < numChannels would break if processing the right channel (1).

Thanks for your help!