Is that best handled by bindings/states?
1 Like
If you mean my comment, I would much prefer not having to add such. I simply cannot see the point in VST windows opening unless I decide to open them. And quite often I might have a rack open, save it and forgot I had the VST window open.
Other people might have a need for VST windows being open, so there is no right answer. I would simply love an option to force them to stay closed.
2 Likes
Hey Derek, as bindings already have the ability to control windows, I figured you were seeing that kind of GUI control as superfluous and more suited to rack control? Such as a tuner opening when a guitar rack is called? Or closing all open GUIs.
1 Like
Hi, Ade
Like I said, I can see why some people might want it as per your example, but I don’t, and I’d rather have a global disable rather than having to put bindings in every single song for every single rack… Or I guess you coudl do a binding per rack, I’ve never thought about it.
But simply put, I do not want GUIs open live, so a global suppress would suit me better, especially if I have had a VST open to edit it and then saved the rack and I’ve forgotten to close the GUI. I’d far sooner have the “inconvenience” of opening the GUI when I need to. Horses for courses of course.
1 Like
Exactly the same here - if I want a GUI open in live operation, I use a binding (mostly to open my guitar tuner). Definite +1 on having an option to disable plugin GUI open status restored (unless they’re tabbed)
2 Likes
I do the same with the DMXIS VST inside Cantabile. I have a hot key binding to open it if I need to that works across all my songs as is in the rack
1 Like
As to what I talked about above about groups of GUI’s, etc. It was about flexibility for those who want it. My “performance” setup is wiring view, severe minimalist, controlled by bindings. It’s the way I like it. When I use a plugin GUI, it’s for setup, tweak it and forget it. Please, don’t clutter that all up.
BTW, This is the only forum for anything that I participate in, why, because you folks are great. Thank you.
Practice serenity, john
3 Likes
+1
1 Like
I’m a little surprised by some of these responses. Seems like you guys almost never want plugins automatically opening.
A couple of comments:
-
With these changes, if you use live mode, plugins will never be opened because Live Mode stores its own tab set which is the set of well known tabs that you last had open in Live Mode ie: it will restore the split mode/position and set list grid, the show notes panel, the song and the background rack. Anything else will not be remembered by Live Mode.
-
The above also means if you have popup plugins open when entering Live Mode, they’ll be automatically closed.
-
The first exception to the above is if you mark a song’s tab set to be used for Live Mode - then it overrides the Live Mode tab set and it can reference plugin windows. Note that since tab sets need to be explicitly saved, there’s no risk of accidentally leaving a plugin open, saving the rack and then having it show up unexpectedly in live mode.
-
The second possible exception to the above is the plugin’s “Editor Visibility” state behaviour. This can conflict with plugin visibility stored in tab sets and I’m not sure how to resolve this yet.
-
I’m conflicted on the term “tab set”. I like its conciseness as it describes its main functionality, but by including plugin popup visibility it actually covers more than just tab sets. Maybe “View Set”, but that’s a more abstract term and not sure it conveys what it’s doing.
-
For the current build if you’re getting hit with popups you don’t want, don’t forget the View → Close all Popup Windows (Shift+F4) command, also available as a binding point:
Brad
This is exactly the issue that caught my attention; it looks like there’s a functioning wheel which is being reinvented.
I’d like to reframe the issue of GUI control to ask what is deficient in the current binding/state protocol that requires yet another way to address visibility?
1 Like
My issue with GUI visibility is not the state / binding protocol, but rather the fact that the visibility of plugin GUIs is not only controlled via state or bindings, but ALSO saved within songs or racks. And it is a bit of an annoyance to have a plugin GUI automatically show when loading a song, just because I forgot to close the GUI when last editing and saving one of the racks in it.
I would much prefer “floating” plugin GUI visibility NOT to be saved with songs or racks, but rather have that visibility status controlled explicitly via
- clicking the “open” button / double-clicking the plugin
- bindings (keyboard, MIDI or otherwise)
It’s different with tabbed plugin GUIs - for these, I have explicitly decided to have them as part of the song layout, so their visibility status should definitely be saved.
So to me, the “saving plugin GUI visibility status with song/rack” functionality is more annoying than helpful, so I’d much rather not have it (or have the option to disable it).
In that sense, to some extent I’d prefer a “tab set” paradigm that does NOT include floating plugin GUIs but rather deals with the “systematic” setup of the Cantabile screen layout. It would be easier for me to deal with opening floating plugin GUIs via explicit bindings or manually, rather than having them pop up unexpectedly, just because I forgot to close them when saving a rack or song…
Cheers,
Torsten
2 Likes
@Torsten
I feel exactly opposite - I frequently keep some plugins open in a song, and want to have them reopen when the song is opened for faster manipulation.
Your issue can be avoided easily if you do not forget to close plugin.
May be, a global parameter can be added to manage the song reopen visibility of plugins stored with a song, but I would strongly oppose behavior where plugins are never opened when I open a song.
That’s exactly what @Derek and I have been asking for…
Hmmm - being a bit patronizing, don’t you think?
1 Like
@Torsten
Sorry did not want to offend you.
Vlad
2 Likes
I think it is fair to say we have a broad spectrum of opinions on this and what is right is subjective.
Hopefully it is all food for thought for Brad and this a way to keep most of us happy.
Maybe an object could have a specific options to force show or force no show of a VST UI. I would then set of of mine to NO SHOW as I literally have no use case where I want to see a GUI unless I am editing a song, and I do not like the current behaviour of if the GUI is open that is saved in the state.
And/or a global preference to suppress the opening of GUIs when loading unless the user specifically opens it. I don’t mind either
Right now if there is one thing I could change in Cantabile it would be this behaviour. Yes it is nit picking, but Cantabile is so good I am down at the picking for nits level in terms my vote for how my subscription $$$s are spent! 
1 Like
Thanks for insight everyone. I’m working on it…
(right now, revert rack functionality is giving me grief with the tabs, but I’ll get there…)
2 Likes
Hi Torsten,
Just to expand my question a little further, does a binding to close all popup windows on state change, song unload etc. not guarantee that nothing is left open?
Not entirely: let’s say I edit a synth patch in a rack, then save the rack (while the plugin GUI is open) to make sure my edits to the patch are saved. Now I close the GUI via the “close all” binding, so the GUI is off screen. Nice so far.
But five songs later, I open another song that contains the same rack, and presto! the plugin GUI pops open again, since its “open” status was saved with the rack…
2 Likes
@Torsten explains it well and why I would love to globally suppress this behaviour. I will open a GUI window if I need to
I’m really trying to get my head into this - and we’re all old friends here now, so please hear this in the friendliest possible voice, and know that your input to the forum has been a tour de force which has provided fantastic insight into setting up a Cantabile rig in the most flexible and bulletproof way…..
What I’m not getting is how the guy who has the most methodical Cantabile discipline can live with racks which operate in a way which irritates the living daylights out of him, when a simple resave makes those GUIs stay out of the way, and bindings can act as a backup insurance.
We’re discussing another layer of GUI control.
It must be me. What am I missing? 
2 Likes