You are here

UI info saving, multiple track selection

Hi Rui,

Could you let me have your opinion on the below whenever you have chance, please?

Currently, it appears that different parts of the on-screen layout are saved in different places. For example, track height is in the qtr session file, Mixer layout (size etc) is in Qtractor.conf and info regarding the left pane info (column widths etc) seemingly returns to default upon restart of Qtractor. Is there a specific reason (design, technical etc) for this information being in different places?

The reason I ask is that, personally, I'd rather have all this info saved in the session (and template) files, as I generally want a specific set-up for specific projects/templates. At the moment, whenever I re-load a session, I have to adjust the Mixer layout and left hand pane column widths (Track Name gets covered by R/M/S/A buttons when track height is small) etc manually; if all this info were saved in the session file, it'd be restored to how I left it when I last saved.

It's not a huge issue, but it is mildly annoying. What are your thoughts on this?

I spoke to you about Shift/Ctrl-clicking to select multiple tracks in this thread last year, but you had no plans to implement this. However, I'm posting again to ask you whether you might reconsider and allow multiple tracks to be soloed/muted/armed for recording simultaneously?

At the moment, I'm working on a project with 30-odd MIDI and audio tracks and it's very tedious repeatedly having to click on tracks/buttons individually, rather than having the facility to select, say, the 1st to the 20th track with a couple of clicks and treat them all together (i.e. 20 clicks vs Shift + 3 clicks). I can't use the "easter egg" feature you referred to, as I need to differentiate between MIDI and audio tracks.

In terms of the functionality, I don't mean full "track grouping" (though that would obviously be very useful) - just multi-selection/operation. If there's a specific design/technical/amount of work reason for not allowing this that's fair enough, but I'd like to double check as the current implementation is slowing down my workflow a fair bit.

Thanks as ever for your time.

rncbc's picture

hi yuba,

track-heights do depend on the number of tracks you have in session, so it's stored on the session file; all other UI sizes and positionsare stored in the local configuration file, when applicable. unfortunately, track-column widths are not stored in either way, so they get their original size and positions as they were hard-coded, on every program launch. this has been like so ever since... you're the first one to touch that topic :) i'll see if i can do something of the sort. however, rest assured as these column-widths don't depend on any session content whatsoever, they will get stored on the global config.

[UPDATE:] on the first commit of the year, column widths are now persistent (qtractor v0.6.4.12 git [c282d7]).

i'll have to check myself whether there's a specific design/technical/amount of work reason for not having this in a near future. i'll check priorities too ;)


Thanks very much for looking into this.

Just tested the latest version and the left pane info is indeed persistent - thanks. It's now much better, but for my particular workflow at least, this (and the mixer info etc) would be better in the session file, as I tend to switch between multiple sessions, each requiring their own UI set-up. However, you think it works better stored in the global config?

It would be an enormous help if you're able to do anything about this :-)

rncbc's picture

you might try the latest git head (>= v0.6.4.13) where the latest change-log entry gets to:

  • Extended multi-selection is now featured on the track-list (main left-pane), primarily allowing for group mute/solo (and monitor) switching. (EXPERIMENTAL)

hope you like it:)

Thank you indeed for this - it's a huge improvement :-) This issue has been destroying my workflow for quite some time now. Just to check on the functionality:

1) Shift-click and Ctrl-click seem to do the same thing. Is this intentional? I'd have expected:

Ctrl-click: select individual tracks, keeping the currently highlighted ones highlighted
Shift-click: select a "range" of tracks in between two points, e.g. shift-clicking Track 1 then Track 10 would select Tracks 1-10

However, both appear to behave as Ctrl-click. It's not an issue in terms of lack of functionality, as it's also possible to drag to select a range of tracks, but I'd like to confirm whether this is working as intended.

2) Are you planning to add the Record state to this multi-select feature too, or not? It's not a massive issue if it's not there (Mute/Solo were the big ones), but it'd be nice to have as it would help when bouncing large numbers of MIDI tracks to audio tracks.

Finally, do you have any thoughts on the UI INFO SAVE/RESTORE point (session vs global) above?

rncbc's picture

the intended behavior is supposed to be consistent as usual for extended multi-selection item list views:

first of all, there's the current track concept and now the selected track one: there's only one and single current track at any one time and this concept is kept unchanged as before, as for all editing purposes. the current track is always displayed on a slight darker background. otoh. there may be none, one or more selected tracks; selected tracks are shown with regular highlight colors as from current color palette scheme or theme (default to desktop environment's).

1) to select and/or deselect tracks you can use the business-as-usual mouse shift+left_click/drag_lasso (add), ctrl+left_click/drag_lasso (toggle) and the keyboard shift+home/end (add), ctrl+home/end (toggle) and shift/ctrl+up/down (add).

nb. the old "easter-egg" behavior also applies to the current selected track set, not only to the whole track universe, which still applies though, depending whether the "anchor" track is selected or not ;)

2) the track record state is not supported at this time on this new multi-selection feature. it wasn't either before; reasons prevail as it's dang tricky to secure it correctly especially in regard to undo/redo scenarios. hyu.

re. UI INFO SAVE/RESTORE (session vs global)
i think i've already made my point. there's nothing to be done here. things that are global are stored globally (eg. column widths); things that are session dependent are stored in session/template file (eg. row heights, zoom level, etc.). there isn't much to argue here, but one better keep things simple as possible (cf. kiss. methodology;)).


Thanks for the various clarifications. I still don't quite follow the distinctions behind the UI, but it appears it's functioning as intended. I'll update the wiki with this new info once I get chance.

Add new comment