However, I’ve got a couple of major problems to note:
if I select any of Apple’s (many) Audio Units (e.g. AUDelay, AUDistortion etc - which I presume come from GarageBand?), I just get a small, empty host window displayed.
In case it helps, this always results in the following assertion:
AudioProcessorEditor* AudioProcessor::createEditorIfNeeded()
...
// You must make your hasEditor() method return a consistent result!
jassert (hasEditor() == (ed != nullptr));
If I select a 3rd party AUv3, such as Moog Model D or Wotja, I get the AUv3 displayed as expected… but there seems to be no way to resize it!!!
Plug-ins which display properly, such as the Moog Model D, are displayed with the wrong size and wrong orientation!
I’ve had a chance to investigate these issues now:
I was able to reproduce this in the AudioPluginHost. Calling hasEditor() on these plugins returns false for me. I think the solution is simply to check hasEditor() before attempting to call createEditor(). I’ll add this change in the demo host.
For AUv3 plugins, the host should resize the editor to an appropriate size. The plugin cannot resize its own view. Calling setBounds() on the AudioProcessorEditor of an AUv3 plugin from the host should resize the view to the requested size.
The AudioPluginHost doesn’t make this especially clear, as the editor windows provided aren’t resizable. I plan to push a change which makes the editor windows resizable via the window borders - with this change applied, it’s possible to resize AUv3 editors in the APH.
I think this is the same issue as your second point. The host must request whatever size it requires. The plugin is not responsible for opening with the correct size.
I’m not sure createEditorIfNeeded() needs to default to the juce generic editor implementation, as many times you want to pass forward the fact it’s nullptr or some other invalid representation of the editor.
Just thought I’d mention that in my Plug-in host window, when the close button is pressed, I’m finding I’m having to do this on iOS otherwise something hangs around that prevents me tapping-though the to user interface. Can’t see why, but just in case it helps somebody…
Sadly also with Wotja it’s the same. unless another host was open earlier on my iPad 7th gen with 14.4, I can’t get any AUv3 to show up or scan properly. as in the issue above.
AUVerb2 isn’t a problem btw, try other freebie third part AUv3.
Nice app btw, it seems you’ve used a lot native UIViews?
Well, that is really weird then. I wish I knew what to suggest!!!
Unless, perhaps, your host app is missing permissions / not signed properly (just clutching at straws here).
Many thanks for your kind comment. Actually, no!
Rather, Wotja’s UI sits on top of a “UIKit-like” layer I wrote (with a navigation model etc.) that in turn sits on top of Juce. It took a lot of work, but it means that Wotja feels pretty close to a native iOS (or macOS etc.) app, despite actually using Juce for all of its rendering!
IMO that is a big missing layer in Juce. I mean, there is nothing technically to stop any dev from creating their own layer, like I did, but it certainly took a lot of effort to create it, and then polish it!
Just to say that one thing that really bugs me about a lot of apps, is that so many of them seem to bring their own design language. We’ve worked pretty hard to keep ours very mainstream, i.e. as close to standard iOS vanilla app as possible. Wotja is hard enough to learn, without having to learn a different UI language