Sneak Peak + Need Feedback: Tabs and Split View

I think the point is that it’s easy to save a rack with a plugin editor open without realizing it and then it annoyingly reappears later when that rack is loaded into another song.

While it’s probably possible to create a binding that automatically closes any popups, they’ll probably first flicker on/off (not sure, untested).

In any case you shouldn’t need to do that an it’s pretty easy for me to add a setting “don’t re-open plugin editors when loading songs and racks”.

For those who do want plugin editors re-opened it will work as follows:

  1. Tab sets will remember which popups are open - so you can manually save a tab set on a song with a particular set of plugins open.
  2. There’s a concept of current tab set that saves the current set of things when a song is saved. So if you save a song and re-open it the previously open popups will re-appear.

Finally, if a plugin’s “Editor Visibility” state behaviour is enabled, that plugin is excluded from the above logic and the state controls it directly. This overrides both tab set behaviour and any new settings to re-open plugin popups.

Brad

5 Likes

I can confirm that they first appear on the screen before being closed. I have a song in my setlist that uses a rack saved with a couple of opened GUIs. I have a binding firing at song load which closes all the popups. When I load the song, I can see the popups open and then close in about a second…and I always forget to check which rack is the culprit so that I can save it again with the popup closed! :laughing:

Gabriel

1 Like

@brad

I think what you describe will give everybody what they want.

The fact that there has been so much discussion on this aspect of Plugin UI visibility shows there is no right answer. :slight_smile:

1 Like

@Derek
I reckon we can all agree the above is not optimal.
:blush:

2 Likes

so essentially, you are telling me in the nicest possible (and a very British) way that I must be a bit dense that I feel this is a problem? :wink:

First: this doesn’t “irritate the living daylights out of me” - it is rather an annoyance and a bit inefficient, and since we are currently discussing the general mechanisms within Cantabile to store and recall window configurations, I think this is a good place to bring it up.

Let me illustrate when this is annoying - mostly in sound design / editing sessions. My plugins all sit in racks, so their GUI open state gets saved with the rack. When I edit my sounds, I open the GUI for one or multiple plugins inside that rack (using a custom button on the rack). So I now have e.g. a synth and an EQ plugin open and edit away happily. To save the current state of my editing to the rack, I now need to

  • close all open plugin GUIs
  • update the rack state and save the rack (another custom button)
  • re-open the GUIs to continue editing when I’m not quite finished…

If I simply went and saved the rack state, all open plugin GUIs would pop up and annoy me whenever I load that rack some other time…

In a world with a setting that de-activates recalling the “open” status of floating windows, I can simply save my editing progress whenever I feel like it without having to jump through the hoops of closing and re-opening the plugin GUI…

Of course, there are ways to work around this using “safety bindings” and such-like, but why should I need to if there could be a better way? I think @brad has got it:

One piece of info that may also help understand my issues: my live / rehearsal setup of Cantabile does not have a PC keyboard set up, simply a 10’’ touch screen and a mouse/trackball. So any need to interact with the screen unnecessarily is a nuisance.

On my studio PC, I’d simply hit a shortcut key and close everything I don’t want to see easily; with my live setup, the simple act of getting rid of a plugin window is a real distraction…

Love & Peace,

Torsten

4 Likes

Did I miss my calling in the diplomatic corps?
:joy::joy:

A compelling presentation, from which the above certainly deserves full empathy.
I guess it just remains to be seen how the issue of open GUIs (as presently operating) will be addressed in practice.
Frieden und Liebe

3 Likes

Toresten absolutely nails the case for why some of us do not want Plugin window visibility to be saved in rack state.

A single global preference state to stop the behaviour is much more efficient for those of us who never, never, never want a Plugin window to open based its visibility when a rack is a last saved. It means you do the selection of preference once globally and can then forget about it. No need for faffing about filling songs/racks with “safety bindings”.

I think what @brad is offering will keep all of us happy, and avoid diplomatic incidents. :slight_smile:

4 Likes

And today was a classic example of why I am asking for what I am asking for. I was diagnosing a problem yesterday with an old song getting ready for my next gig. I think I must have deleted a route by mistake at some point, because Falcon was no longer responding to Montage controllers.

I opened the song again this morning to finish off, and there was the Falcon UI because it had been open whilst I was trying to fix the problem when I saved the song and I had forgotten to close it.

1 Like

I am stoked about the coming changes to the views, I’m betting that Brad has that cooking up right now and it will be time to enjoy it soon. :slight_smile:

2 Likes

Available now, see here.