BusesProperties public pls

1

Hey, I just wanted to ask really quickly if you (JUCE) would be so nice to put juce::AudioProcessor::BusesProperties into the public part of the class, so that I can write a free function in one of my headers for dealing with certain BusesProperties stuff for my constructor. I’d like to have that seperated from the rest of the AudioProcessor for code organisation reasons in projects that have a more complex buses layout, than 1input 1output

1 Like
2

It’s quite easy to circumvent the protected keyword (shhh don’t tell anyone)

struct BusPropertiesUtils : private AudioProcessor
{
    // Expose BusesProperties
    using AudioProcessor::BusesProperties;

    // Do some stuff with an instance of BusesProperties
    static bool validateBusesProperties (const BusesProperties&);

    // This type is just a namespace for utility functions, please don't construct it!
    BusPropertiesUtils() = delete;
};

Usage:

jassert (BusPropertiesUtils::validateBusesProperties (myBusProperties));
2 Likes
3

first of all thank you for the reply! if this works it will be a good resource for c++ moments like this in general. i think i can’t add it to my code base though, because it would look even more confusing than not being able to outsource the busesProperties stuff into another header. after all, the goal was code organisation and readability etc

4

I’ve had to do it the way you described Reuk but I agree it seems like it should be public.

I have shared processors which cross compile with different bus configurations depending on the environment it’s loaded, so I’ve got tons of these little dummy audio processors around which exist just to return a valid BusesProperties object

2 Likes