But now that you’re offering a variety of views, it could well be the obvious progression?
Live mode benefits from consistency. If you’re ‘live’ you want to know where things are with certainty.
The ‘edit’ mode is where the handling of tabs, splits etc, would seem to be the most useful place to have the required view returned to the user, on request.
Have I missed the objective, @brad?
1 Like
Hey @brad,
I’m fully behind this approach - let song-specific layouts with all wildness around open racks, tabbed plugins etc etc be limited to “normal” mode.
I would want live mode to be fully predictable and consistent across songs - this is the stuff I need in the heat of live action; not the time for plugins pushing to the foreground or some changes I made to a specific song completely messing up my live experience.
With “normal mode”, my preference would be to get back to the layout of the song as I last saved it; including opened racks, tabbed plugins etc. With a “global” layout for individual songs in mormal mode, there is a lot that would get lost if this got forced on every song opened, like racks or tabbed plugins opened for editing.
What I would reeeeeally love, while you’re at it: have a limited set of “normal mode” screen configurations (open tabs, allocation of tabs to panes, which tabs are currently active and selected), stored with the song that I can easily switch between, e.g. using the number keys. So I can easily jump e.g. between a “song editing” config with table view on the left and bindings on the right, and a “rack editing” view that does the same for a specific rack, just by hitting “1” and “2”; then jump to the background rack editing view by hitting “9”. A bit like what @Ade was mentioning above - I use such stored layouts in Cubase all the time.
My first reflex would be to have these quick layouts stored with a song, since there is so much specific to a song that would make such a layout useful (depending on where I make my edits most frequently and thus which areas I need accessible quickly). Especially which racks routing or bindings to bring into view.
So TL/DR, short answer: live mode: global, limited layout; normal mode: stored with the song. Plus feature request: multiple layout configs, stored with the song, quickly accessible via number keys and/or buttons
Hope this makes sense!
Cheers,
Torsten
3 Likes
@brad I’ve finally had time to watch the video and it looks great, and I think a great improvement on the way you currently dive into racks and then have to “eject your way out”. Not that I have been unhappy with it so far, but you are now showing a new UI which looks a lot more flexible and definitely an improvement in my book. 
The split view would also be great when setting things up and save a lot of diving in and out of different racks, bindings…
I must confess I have never used live mode, as when playing live I just ensure that my show notes are visible. But my vote if I were to use live mode would be global config for live mode, not song by song.
1 Like
Thanks for the feedback everyone. I feel like I’m getting closer to an approach that will work.
1 Like
And in that application, the library function Itself has global layouts on one side and song specific layouts on the other. One can swap layouts from one side to the other, enabling any layout to be available to any song loaded, and also be song specific. Cubase also displays any associated key command.
yep, I like that in Cubase. Not sure, though, if that translates to Cantabile - in Cubase, a layout consists only of “standard” displays (mixing console, arrangement view, editors, …), whereas in Cantabile, there are a lot of song-specific displays (rack views, individual plugins) that make up a view configuration, so a song-specific view won’t fully translate to a (universal) live view config.
But of course having multiple presets for live view AND song view would be amazing…
1 Like
This is what I’m leaning towards:
- Keeping Live and Normal modes. These maintain the window layout similarly to how it works now: visible panels and bars, full screen mode etc…
- Adding support for per-song user configurable “tab sets”. A tab set stores the set of open tabs, the active tabs and the split mode. These will be short-cut key assignable. Since these are associated with a song, they can reference specific racks and plugins to quickly switch to a particular view of something in the song.
- Live mode will maintain its own “tab set” - the current set of well-known tabs (set list grid, show notes, song, and background rack views). Note this excludes rack and plugin views because these are per-song and not “well-known”.
- A song can optionally declare one tab set to be used for live mode. This allows overriding the displayed tabs for specified songs. If not specified, the live mode tab set is used.
Questions:
- I’m considering support for multiple layouts, but I’m not sure yet. Is this needed in addition to per-song tab sets?
- Would you prefer saved tab sets to update automatically or only when explicitly saved?
ie: if you load a tab set, open or close some tabs, switch to another tab set and then back again, should it restore the original tab set or the modified tab set? - Would it make sense for a tab set to also store the set of open non-docked plugins? (ie: those shown in overlaid popup windows). Although not technically “tabs” they’re very closely related. Maybe I need a better name for “tab sets”?
- It should also be possible to have globally saved tab sets (ie: non-song specified tab sets). Similarly to the live mode tab set, these would be limited to well-known views. Not sure if this is useful or just complicating things. What do we think?
As always, feedback welcome.
Brad
1 Like
On question 1 I agree with Torsten, presets would be amazing.
On question 2 I would lean toward auto update so you could undo or redo a given tab set. If that is already part of the undo/redo Cantabile has wouldn’t that cover it? If you were saving tab presets (if they were implemented) I would want to be able to save them explicitly. If not then the tab configurations for both views would save with a song save.
On question 3 I’m for having the tabs and detached windows having equal weight and being saved as a “tab set”
On question 4 I’m in the camp of it would be helpful to have that option. It would provide a customized starting point for song building.
Great work Brad 
2 Likes
Hi Brad, for me
- I think a normal layout per song is enough, without multiple layouts.
- I would prefer explicitly saved
- I agree with keeping at the same weight the tab set and the detached plugin so all stored in the same “tab set”. Maybe you could call it View Layout or similar
- Mh…I know what the global tab sets would mean as a developer and the effort behind, i would prefer not. Maybe you could include in the “per song” tab set, the tabs (and the popup of the detached plugins) related to the background rack. Am I saying right? Could it be possible?
About the split + tab view perfect choice! For the binding little icon it’s ok using the shortcut and similar approaches.
Thank you as always @brad !
1 Like
Not sure if I understand the difference between “layout” and “tab set”?
In my understanding, I’m looking for what I’d call a “view configuration”, which consists of
- split mode (single window, horizontal split, vertical split) and split geometry (relative width / height of windows)
- open tabs and their content per window
- active (visible) tab per window
- which window is currently in focus (receiving key presses)
- visibility of Cantabile’s screen elements like menu bar, tab bar, timeline, onscreen keyboard, …
- possibly also: any open un-tabbed plugin GUIs
All this would be a “view configuration” in my diction. Not sure what differentiates a “tab set” from a “layout” in your diction; maybe you can elaborate?
From my perspective, I wouldn’t need two different concepts like “tab set” and “layout”; I’d be happy to have all the above aspects (and any I’ve forgotten) wrapped into one concept; call it “layout”, call it “view” or whatever, but stick to one name 
Cheers,
Torsten
2 Likes
I lean towards keeping the concept consistent with presets and states - unless something is explicitly “locked”, it will be updated automatically. So we’d need a “lock view” button somewhere to stay consistent with other aspects of Cantabile. Maybe a row of buttons 1…9 for the custom views per song, plus an extra button for “lock view”…
1 Like
Hi @Torsten:
Layout: to do with the geometry of the main window: position, visible panels, table column widths, panel sizes, full screen mode, set list grid locked mode etc… (Basically, everything that changes when you switch between live and normal modes in the current version.)
Tab Set: the loaded set of tabs, the split mode and the active tab in each split panel. It’s restricted to the inner main working area of the main window.
Unless I’m misunderstanding how you see this working, I’m very reluctant to save most of the layout settings per-song because it will introduce all sorts of weird behaviour.
- Some of these settings are machine specific (like the main window position which is sensitive to the size of the screen, number of screens etc…). Do you really want to switch to a new song and the whole app moves to another monitor because that’s where it was when you last saved the song (and perhaps last time your saved it was on another machine)?
- Same for column widths and panel sizes - people adjust these based on available screen space, not which song they’re in.
- If the visibility of the set list panel is saved per-song, you can’t switch to that panel and the click through each of your songs (because some songs might have it hidden).
- Similarly for controller bar and ticker bar you show it and use it to start stepping through songs and then it disappears because it was hidden when you saved a particular song.
- What about the width of the side panel, height of the keyboard etc… these would be jumping around as you step through songs - unless you’re careful to save every song with the same geometry.
- I think a case could be made that some panels are song specific (metronome, time-line panel), but then it gets confusing, and I get support questions asking “why does X keep hiding and showing when I switch songs?”
- What happens when someone upgrades from Lite to Solo or Solo to Performer, do all their songs suddenly have to be updated to hide or show a panel that wasn’t available before?
- What happens when you create a new song? Does the layout get reset to default or does it inherit the layout that happened to be in use when you created the song?
- Many of these settings are just personal preferences that you want to set once and have it apply everywhere (eg: controller bar, menu bar, tool bar, tab bar visibility).
Another way of thinking about it: layouts choose a working mode and tab sets choose what you’re working on.
Having said all that, I can see the appeal of being able to hit a button and a particular view of a rack is loaded and certain panels automatically hidden/shown. Perhaps a tab set can be linked to a layout so that when the tab set is loaded the linked layout is also switched to.
Brad
Hey @brad,
OK, I get the differentiation now; and mostly I agree with your reasoning. There are some elements that I’d love to be able to switch on and off flexibly per “tab group” (e.g. onscreen keyboard and timeline), but a lot of the other elements you mention I hadn’t thought of in detail, and it makes sense to keep those stable.
So probably it is most useful to keep 2 “layouts” - one for Live Mode, the other for Normal Mode, and then work with tab groups inside these layouts.
I still hope that the layout WITHIN the main window can be stored with tab sets, i.e. split mode (horizontal, vertical, no split) and split position. That would make things flexible enough without messing up the overall logic, I think.
And for elements like Onscreen Keyboard or Timeline, these can be assigned to a Binding, so easy to turn on/off flexibly without having to recall a full “layout”, so by assigning multiple “view” bindings to the same Source, I can even have full multi-element visibility presets assigned to a key, button or MIDI command. Plus, these bindings could even be triggered by the same Source as a “tab set” recall; so if I want to always have the timeline open in tab set 1, I can do that - without confusing the majority of Cantabile users
Cheers,
Torsten
1 Like
This is why I was thinking of letting you link a Window Layout to a Tab Set. I haven’t committed to this yet, but it’s a possibility. See also below re Bindings.
I’m part way through implementing user-layouts - there will be one Live Mode layout and N user layouts.
I’m not sure about lock modes and auto update. I know that would make it consistent with other features in Cantabile but I’m not sure where the UI for that would live or even if it’s desirable. At least to start with both window layouts and tab sets will need to be manually saved to update them.
Speaking of UI, this will be menus and shortcut keys:
- View → Window Layout → submenu (Save, Manage, list of saved layouts)
- View → Tab Set → sub menu (Save, Manage, list of saved tab sets)
The Tab Set menu will probably be also available as hamburger button in the tab strip.
Yes. A tab set includes split mode, split position, tabs in each panel and the set of popup plugins and their positions.
In addition to user-saved tab sets there’s also the internally saved “current tab set” which is saved automatically with your song and brings you back to where you last were when you re-open it. Same for window layouts.
Each saved window layout and saved tab set will have an associated index number that determines which short cut key triggers it. There are 10 short cuts for window layouts and 10 for key sets. These keys can be remapped in Tools → Options → Hot Keys. You can also save unnumbered layouts but these can only be loaded via the menu.
I think the load layout/tab set functionality will also be available via bindings - both as a source event so you can trigger other actions when a layout/tab set is loaded and as a target so you can load one with a binding.
Brad
2 Likes
There’s a subtle change in behaviour these changes introduce that I’d like run by you all:
Previously the appearance and location of popup plugin editors was controlled by the rack that contains them. If you load a plugin into a rack, show its UI (in a popup) and save the rack, then any song you load that rack into the plugin will appear.
Because these changes of move the visibility of popups into the tab set, and because the tab set is a property of the current song and not the rack you can no longer have a rack that always shows a plugin whenever it’s added to song - unless you explicitly do it with bindings.
Brad
I guess this would actually make the popup behaviour more predictable, at least to me. 
In my first months using Performer, while learning how to use racks and states, I used to be taken by surprise by all these plugin popups suddenly appearing on my screen. Then I learned (I still hope I have understood this correctly) that the visibility of the plugin is stored in the rack and, if the rack uses states, it can be different for each state. That’s why I added a binding in my background rack to close all popup plugins at song loading, just in case I forgot to close all popups before updating a state and/or saving a rack.
Gabriel
1 Like
I can’t say that causes me any concern.
1 Like
Everything I am reading here is awesome. Get away from the 25 year old physical rack metaphor and move to a visual process one. I think these ideas have the potential to truly differentiate Cantabile.
As to the discussion, what to do with what brad calls tab sets. I would call then named groups of GUI objects. Song level or rack level? Remember, a “song” is just the top level rack (so I will just use “rack”) , with some number of nested racks. I see this stuff as a rack property. You should be able to put it in any and all racks. As simple or complex as you wish, that’s the beauty of Cantabile. If you want to have multiple setups per rack under tabs or whatever, for sure. And, there are states, they can have GUI sets. For some time them has been some discussion about how to make states more visual.
In Brad we trust.
2 Likes
May be, keep the split view, and allow tabs in each of these split screens.
1 Like
I personally would prefer no plugins popping up at all unless I open them. May be a preferences option to control that if there are different preferences for this behaviour?
2 Likes