View Issue Details

IDCategoryLast Update
0007179bugs2016-12-19 14:26
ReportersoundradixAssigned To 
Reproducibilityalways 
Status newResolutionopen 
PlatformmacOSOS10.12OS Version10.12.2
Product Version5.5 
Fixed in Version 
Summary0007179: macOS X: Ardour EXPLICITLY hides all children windows
DescriptionArduor has a BIG problem: it EXPLICITLY (not implicitly by setting hidesOnDeactivate property) hides all children windows (including host windows plugins are attached to) on application deactivation.

As far as user clicks on plugin editor control (or elsewhere inside plugin window) 32 Lives Agent application is activated, causing Arduor deactivation and it hides all its child windows.

 Our "hide on deactivate" logic does not work nor in 2.0, nor in "stock" 32 Lives distribution.

This issue has nothing to do with OS X version. (happens on any macOS 10.x we tested so far).
Steps To ReproduceWe've attached a video showing 32 Lives interaction with Ardour.
Steps to reproduce:
- Get a 32bit plug-in (eg. https://tal-software.com/products/tal-bassline)
- Install 32 Lives (https://www.soundradix.com/products/32-lives/)
* Note it is possible to reproduce with the Demo version as well...
- Wrap your plug-ins from 32 Lives Manager.
- Launch Ardour and make sure you've scanned your AU / VST to be tested against.
- Insert the wrapped plug-in instance on any track.
- Click anywhere in the UI.

Result:
- Ardour hides EXPLICITLY children windows causing the UI to disappear.

Expected Result:
- Front UI should stay in-front.

------------------------------
We've also attached a video showing the issue
Additional InformationHi,
We're the developers of 32 Lives.
This issue is general to Ardour but affects our product as reported by users especially users of Harrison Mixbus.

Feel free to contact us for any additional questions.
TagsNo tags attached.

Activities

soundradix

2016-12-14 13:49

reporter  

Ardour - 32 Lives - Main Issue.mov (2,328,912 bytes)

paul

2016-12-17 12:20

administrator   ~0019160

It is NOT true that Ardour explicitly hides child windows on deactivate OR that is explicitly sets hidesOnDeactivate for all child windows.

What is true is this: our cross-platform toolkit sets hidesOnDeactivate for the following types of (cross-platform toolkit) windows: UTILITY, MENU, SPLASHSCREEN, NOTIFICATION, and TOOLTIP. It is hard to argue with this decision (especially since I made it :) Many other OS X DAWS and other applications that host 3rd party plugins with GUI code do precisely the same thing, at least as an option.

Anyway, we put the plugin NSView inside a window marked as a DIALOG, not any of the above window types. So.. although this behaviour is actually what I intended to happen, it isn't clear on a quick glance why it happens at all. I will keep looking ...

x42

2016-12-17 12:27

administrator   ~0019161

I rather like that all plugin-windows are hidden when changing application focus. From my POV it's a nice feature and the opposite of "a BIG problem".

But you do have a point.

IMHO, ideally there'd be some means to detect if the plugin is an external application and only override it for that specific child-window.

paul

2016-12-17 17:17

administrator   ~0019162

OK, found where we do this. PluginUIWindow tracks application activation status, explicitly to ensure that we show/hide plugin windows based on activation status.

This behaviour was based on what I consider entirely reasonable user requests. If the DAW has 8 plugin windows open, switching to a different application should hide those windows until you switch back to the DAW.

This model of having a separate application that is actually running the plugin really breaks this model. It also doesn't scale properly for large sessions (the context switch overhead is too large).

I suppose we can offer the option of whether or not to do this. But it is generally horrible to add new user options to work around an inability to make a policy decision. I strongly believe that leaving plugin windows when the app becomes deactivated is bad for almost all users.

soundradix

2016-12-19 14:02

reporter   ~0019171

Hi guys,

I think we didn't explain the issue properly, sorry!

First, there is no "BIG problem" with the fact that Ardour hides its plugins windows on app deactivation. The problem is just with 32 Lives integration with the way that Ardour does it.

With other DAWs, we found that relying on the 'hidesOnDeactivate' property works well. So, it would be great to also rely on it in Ardour. Is it possible and easy to just make the plugin windows disappear on app deactivation by setting the 'hidesOnDeactivate' property, instead of explicitly hiding them?

Following the above explanation by paul, maybe DIALOG windows can just be set with this property as well?

Thanks!
Dan

paul

2016-12-19 14:26

administrator   ~0019172

We should just try it. And we will. It won't be for all DIALOG windows, just for a derived class. Stay tuned.

Issue History

Date Modified Username Field Change
2016-12-14 13:49 soundradix New Issue
2016-12-14 13:49 soundradix File Added: Ardour - 32 Lives - Main Issue.mov
2016-12-17 12:20 paul Note Added: 0019160
2016-12-17 12:27 x42 Note Added: 0019161
2016-12-17 17:17 paul Note Added: 0019162
2016-12-19 14:02 soundradix Note Added: 0019171
2016-12-19 14:26 paul Note Added: 0019172