AU GetCurrentProgram() problem

Hey Jules -

I’ve just noticed that when I call getCurrentProgram() on AU plugins from my host I get screwed up results.
Previously I figured it was just certain plugins, but it seems to happen with all AUs and not with VSTs.

I tried it today with the PluginHost and got the same issue. The attached screenshot shows a compilation of the PluginHost with a timer that prints out the results of getCurrentProgram() for every loaded plugin.

The inputs/outputs return 0, as do any plugins with no programs. The others give (oddly similar) wrong answers (even the Apple plugin). I did find some that gave slightly different results (the Martin Eastwood plugin here always reports it is on program 519151360). The others seem to be returning a large number that varies with time.

Anyway, I checked it at the base call in and saw the wrong answers coming back there.

Also, I should note that getting the total number of programs, and their names, and setting current programs all seem to work just fine. I can actually set the program, say program 3, and see that it has worked, but I still get these screwy returned program numbers.

Anyway, take a look when you get a chance, or let me know what silly thing I am doing wrong if that is the case.


Ah, looks like a typo in that method… Try replacing it with this:

[code] int getCurrentProgram()
AUPreset current;
current.presetNumber = 0;
UInt32 sz = sizeof (AUPreset);

    AudioUnitGetProperty (audioUnit,
                          0, &current, &sz);

    return current.presetNumber;


yup - that’ll do it! Thanks.

Hmmm … actually maybe not.

It seems now that if I set the program (setProgram()), it will then switch programs and report the proper program number.

But … if I open the AudioUnit’s UI and switch programs there, it still reports the previous program. Presumably the AU itself is not updating the state somewhere. hmmm …

There are some “professional” companies (looking at you, Native Instruments), which make plugins that do not notify the hosts of changes … which seems ridiculous to me … but so far I’ve gotten around it by polling the parameters constantly and noting changes. I’m trying to do the same with the currentProgram, but since the internal state is not updated at least as far as current program is concerned … I guess I’m out of luck.

Still stumped by this.

If I change program via a setCurrentProgram() … then getCurrentProgram() comes back correct. If I change programs for within the plugs UI however, I get no love.

Got any theory on that?

I'm running into this problem too --- I have Massive loaded and if I select a different preset and then call AudioProcessor.getCurrentProgram() I can, by stepping through, see that the AUPreset NAME correctly contains the selected preset name but the presetNumber ALWAYS contains 0.

Anyone know how to fix this?

I think this is a limitation of the plug-in. The plug-in fills in those fields. It seems as if Massive sets the presetIdx field to zero.

I do have this same issue, however with a Juce plugin!

The host’s AudioPluginInstance always returns -1 for getCurrentProgram(), regardless what is selected. Interestingly, the call to getCurrentProgram() in that very Juce plugin doesn’t seem to be called (setting a breakpoint there has no effect). This is driving me nuts.

So this looks more like the call gets lost before reaching the hosted plugin in the first place.

As it often is, once digging into a thing deeper and deeper, a solution emerges only a few minutes later :wink:

It looks like calling updateHostDisplay() immediately after setCurrentProgram() fixes this. Obviously the AU needs to be notified to flush some cached information.

In order to fix this for all the cool Juce-built AU plugins out there, maybe it would make sense to integrate this with the AU plugin format code?