tracktion_engine::Plugin::showWindowExplicitly() creates AUGenericView for some plugins

General JUCE discussion
#1

Hi there,

I’m experimenting with PluginDemo and want to open plugin editor right after adding it to a track.

I’ve added a call to plugin->showWindowExplicitly(); to an addButton click handler in TrackFooterComponent like this:

   addButton.onClick = [this]
   {
       if (auto plugin = showMenuAndCreatePlugin (track->edit)) {
         track->pluginList.insertPlugin (plugin, 0, &editViewState.selectionManager);
         plugin->showWindowExplicitly(); // <-- this call has been added
       }
   };

It works, but not for all plugins. For some plugins AUGenericView is being shown.

I was able to trace the issue till the moment of pluginView creation in juce_AudioUnitPluginFormat.mm.

pluginView is null after execution of:

pluginView = [factory uiViewForAudioUnit: plugin.audioUnit
                                withSize: NSMakeSize (getWidth(), getHeight())];

The issue is consistently reproduced with KORG Collection - M1 plugin, but not with KORG Collection - Triton, for example.

I’m new to audio programming in C++, so basically there are two questions:

  1. Am I doing an illegal thing by calling showWindowExplicitly() in the button’s click handler?
  2. What is the recommended way of debugging issues which involve native libraries like Apple’s AudioToolbox in this case?

Thanks!

#2

Hi @t0m! I wonder whether you have any ideas regarding the issue mentioned above?

#3

No, I would generally expect this to work.

That’s a good question! Often, the best we can do is to read the documentation for the API and attempt to determine whether or not this host/client have implemented the API correctly. Unfortunately, the documentation is quite sparse in this case, so the answer is not clear.

The API documentation for the AUCocoaUIBase protocol (which includes the uiViewForAudioUnit method) doesn’t mention any requirements about when this method is allowed to be called, or cases in which the returned view is allowed to be null. I think I would expect the plugin to be able to return a valid view directly after construction for this reason, and I also think it’s a reasonable fallback for JUCE to automatically create a generic view if creating a non-generic view fails.

The best hint I found was on this page:

An audio unit’s view should work whether the audio unit is simply instantiated or whether it has been initialized. The view should continue to work if the host uninitializes the audio unit.

So, I’m inclined to say that this is a bug in this specific plugin. If you’re aware of more concrete documentation indicating that JUCE’s hosting behaviour is at fault, please let me know and I’ll take a look. Otherwise, I’d recommend filing a bug report against the plugin.

Finally, in testing, it looked like this particular plugin is able to create its non-generic view a little while after construction (Timer::callAfterDelay (100, [plugin] { plugin->showWindowExplicitly(); }); worked fine). Maybe that’s a suitable workaround for your use-case.

#4

@reuk thank you for a detailed answer!

Yeah, timer-based solution will work in my case and JUCE’s fallback behaviour is definitely reasonable.

That was also good to know that there is no other way than reading native library’s documentation.

I’ll submit a bug report to the manufacturer of the plugin.