iOS AUv3 size negotiation


#1

Has anyone actually successfully used the size negotiation for iOS AUv3? Is there an example somewhere of it in action? I see it is in the AUv3 wrapper, but I can’t for the life of me get it to work, and there are (naturally) no Apple docs about it.


#2

I don’t know of a public example, but it’s used by the ROLI software team. What isn’t working?


#3

Example instrument would be Moog Model 15 and Effect would be FAC Maxima


#4


#5

Hey, Tom, we’re finally at the point where we need to attack this for our latest, and I could really use some help, or at least face me in the right direction. I see the two methods in the AUv3 wrapper (getSupportedViewConfigurations and selectViewConfiguration) but from the Processor level where we work, we don’t actually have access to these methods, best I can tell.

My thinking was that I would access the holder the way I would for the standalone holder (e.g. including the Standalone wrapper and something like auto holder = StandalonePluginHolder::getInstance();

The obvious problem there is that the AUv3 wrapper is .mm. I’m compiling PluginProcessor.cpp as Obj-C++, because I need access to NSFileManager and NSURL, but if I try to include an .mm, it’s turtles all the way down. To paraphrase JWZ, now I have two problems.

So, just a tiny smidge of code to point me in the right direction would be appreciated.

EDIT: Obviously, I’d be more than happy to do this in Editor rather than Processor. We store the size in our globals which are dealt with in Processor’s constructor, so I naturally thought to put the negotiation there, but whatevs.


#6

Do you need access to the whole negotiation process? What do you want the outcome to be?

At the moment JUCE uses the editor’s constrainer and the result of the virtual method supportsHostMIDIControllerPresence to determine if configuration is supported:

(Edit: link fixed)


#7

That link is a 404, but I know the method you mean, and I was briefly bemused that that seemed to be the only entry point.

In any case, to answer your question, here’s the problem: the only way the UI will have access to the full screen button in Garageband or open its full window on first instance in AUM and apematrix is if the size negotiation took place, and we allowed a 3:2 ratio in addition to the normal 3:1 ratio, unless I’m reading things totally wrong. So the aspect of the negotiation I need access to is the ability to see the proffered ratios and allow and prepare for them. There’s nothing to be gained if I don’t know what ratios were negotiated. So, to use your terminology, yes, I need access to the whole negotiation process.

Now, all that said, we need to make this a public accessible function like the IAA host icon and switching mechanism; in that vein, I’d suggest adding the two negotiation methods to juce_audio_plugin_client_utils.cpp like the IAA stuff, so we can just deal with it on our own time.

EDIT: Ah, I see. That function rolls through the available configs and asks the constrainer if they’ll work; if they will, it adds them to the index. Got it. Back to the salt mines.


#9

Yep, that’s it.

The approach might be problematic if you wanted to rule out some intermediate sizes though.


#10

Yeah. We’re definitely going to need a more sophisticated approach in the long term, but as far as getting the little fucker to full-screen in Garageband, this’ll do the trick. Just have to figure out the right aspects to return.