Abstract JuceAU (CoreAudio changed again) - CanScheduleParameters()


Hi Jules,

Installed the CoreAudio utilities (for the Rez error) and my code's not compiling because it says JuceAU is an abstract type.

/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUBase/ComponentBase.h:283:23: Allocating an object of abstract class type 'JuceAU'

/Applications/Xcode.app/Contents/Developer/Extras/CoreAudio/AudioUnits/AUPublic/AUBase/AUBase.h:250:15: Unimplemented pure virtual method 'CanScheduleParameters' in 'JuceAU'

I'm using the newest 3.0.7 modules and a search for CanScheduleProgramming here resulted in nothing, so I'm guessing this is something that simply hasn't come to your attention yet.

The online CoreAudio doc lists the method as follows:

virtual bool CanScheduleParameters() const { return true; }

But the actual source now looks like this:

virtual bool CanScheduleParameters() const = 0;

So I guess they just took out the function body and made it abstract without updating the doc.


[EDIT]: Yep, adding the function makes my code compilable, so that's it.


Actually, I can add an implementation of that method to the JuceAU class, which should avoid needing to modify their code.

But WTF does the method do? Apple's documentation says absolutely nothing about it! I actually think it probably makes more sense for it to return false, as it seems to be involved in making a list of changed parameters, which we probably don't want to happen.


Yeah, I modified it so that my code compiles now, and to see whether this was the only added abstract virtual. Of course, it'd be best to change this in the JUCE source itself.

I've got no idea as to what it does. Either way, my code compiles and runs. I'll keep it at false for now and humbly await a JUCE update :)

[EDIT]: AUBase also shows a virtual ScheduleParameter function(), but it has a body.

I think scheduling parameters is just some new functionality (having to do with automation or something?). JuceAU never implemented this, if I'm seeing correctly, so I guess a return false would indeed be best.