Notifications
Clear all

Placement of Opening VST GUI  

  RSS

Kendall W Cochran III
(@pbeprod)
Member
Joined: 7 months ago
Posts: 116
November 22, 2020 2:36 pm  

@getdunne

I was wondering how it is determined where the opening Window of a VST's GUI is going to be. Is that just based on Mac's OS or is there code in UNIFY that determines that. If so is there a way to have it remember where the last open window was closed? So when I'm creating the libraries of course I have to be able to see both Unify and Omnisphere's GUI and the limited screen space on my MBP makes them fight for dominance. Of course I reduce the size of both but when I have to switch between patches I have to constantly move O2 out of the way. Of course when I'm completing the library at the end I open the O2 Standalone so I can input Macro settings and it's not an issue then, but I do have to select each of the patches before I save them in UNIFY prior to that. Anyways was just curious.

Thanks

KWCIII


Quote
getdunne
(@getdunne)
Member Admin
Joined: 1 year ago
Posts: 1579
November 22, 2020 3:31 pm  

@pbeprod

Unify uses a very simple approach. The first time a new plug-in instance's GUI is opened, the top-left corner will be put at pixel coordinates (200, 200). Each time you close it, Unify remembers the top-left corner coordinates, so if you re-open it, it should re-open wherever you put it before. Whenever that plug-in instance is entirely removed, though (swapped out, layer deleted, patch changed), the saved coordinates are forgotten and it will start again at (200, 200).

I'm open to suggestions for better ways to do this.


ReplyQuote
Kendall W Cochran III
(@pbeprod)
Member
Joined: 7 months ago
Posts: 116
November 22, 2020 6:08 pm  

@getdunne

That's above my pay grade and intelligence! 🙂 I know that you had to make adjustments so that VSTs would open quicker. Like with Massive Power Pak, so it wouldn't take so long to open patches via a buffer of some sort? Would it be possible to have UNIFY be able to determine between patches if the same VST is being used that it would allow the GUI to remain open? But I guess that would cause an issue with other code - I'm guessing. Honestly I have no clue about how any of this works. The last programming languages I took were Pascal and Fortran in HS on Apple IIs and Basic in College.  I guess this is my brain trying to wrap itself Unify possibilities. 


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 1 year ago
Posts: 1579
November 22, 2020 6:38 pm  

@pbeprod

Don't sell yourself short, Kendall, you're on the right track here.

I do have plans to keep plug-in instances in memory and re-use them (to make patches load even faster), but this is going to require some tricky code wrangling. The idea of keeping the GUIs open is an interesting one. It wouldn't provide any advantage for most plug-ins, but for a few (like Omnisphere) it just might.

Sometimes just kicking ideas around like this can shake loose some valuable insights.


ReplyQuote
Kendall W Cochran III
(@pbeprod)
Member
Joined: 7 months ago
Posts: 116
November 22, 2020 6:48 pm  

@getdunne

The problem with the GUI remaining open, how would the state of the window be resolved from one patch to the next. It would have to be updated with showing which O2 patch is being used. Every time I work on another library my mind wanders about Unify compatibilities. I'm trying to finish Signs of life within the next few days, John asked me this morning if it was done so he can include it in the Black Friday sale.


J Hall liked
ReplyQuote
mschiff
(@mschiff)
Estimable Member
Joined: 5 months ago
Posts: 101
November 23, 2020 7:07 am  

@pbeprod

Cool! I just bought Signs of Life. Thanks Kendall!


ReplyQuote
J Hall
(@zinct)
Member
Joined: 6 months ago
Posts: 97
November 23, 2020 7:55 am  

@pbeprod Thanks, Signs of Life is also on my Black Friday wishlist (along with Perspektiv).


ReplyQuote
karlfranz
(@karlfranz)
Trusted Member
Joined: 7 months ago
Posts: 53
November 24, 2020 1:49 am  

Forget keeping the VSTs open. I'd be happy if they just remembered the last coordinates where they were last before I closed them. Having to hunt them down from my other monitor each time the open gets old. The monitor by my keyboard controller is configured as my primary so every time I open Unify, a VST window or a Macro assignment window, that's where it shows. Not very helpful when I'm on the other monitor at my desk.


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 1 year ago
Posts: 1579
November 24, 2020 3:16 am  

@karlfranz

They do remember the last location before they were closed -- until the plug-in instances they're attached to are removed, e.g. by changing patches. then they default to (200, 200). Would you like the ability to change that default to something that works with your monitor layout?


ReplyQuote
karlfranz
(@karlfranz)
Trusted Member
Joined: 7 months ago
Posts: 53
November 24, 2020 4:29 am  

@getdunne

I believe the standard OSX convention was for applications to store their parent and child windows's positions along with any other user preferences in the file ~/Library/Preferences/appname.plist so that they can recall them the next time the app restarts. That would be my preference.

I see you're storing some of Unify's data including window gui scale factor in ~/Library/Application Support/PluginGuru/Unify.settings as an xml file. Could you store window coordinates there every time you get a window resize or move notification?


ReplyQuote
getdunne
(@getdunne)
Member Admin
Joined: 1 year ago
Posts: 1579
November 24, 2020 2:58 pm  

@karlfranz

If I follow the Apple convention, I would have to save a coordinate-pair for every plug-in. That would be a lot of management, for questionable utility. Do you think it would be sufficient to simply remember the location of the last plug-in GUI window (any plug-in) that was moved by the user?


ReplyQuote
Share: