View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007179 | ardour | bugs | public | 2016-12-14 13:49 | 2016-12-19 14:26 |
| Reporter | soundradix | Assigned To | |||
| Priority | normal | Severity | major | Reproducibility | always |
| Status | new | Resolution | open | ||
| Platform | macOS | OS | 10.12 | OS Version | 10.12.2 |
| Product Version | 5.5 | ||||
| Summary | 0007179: macOS X: Ardour EXPLICITLY hides all children windows | ||||
| Description | Arduor 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 Reproduce | We'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 Information | Hi, 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. | ||||
| Tags | No tags attached. | ||||
|
|
|
|
|
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 ... |
|
|
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. |
|
|
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. |
|
|
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 |
|
|
We should just try it. And we will. It won't be for all DIALOG windows, just for a derived class. Stay tuned. |
| 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 |
