|Proposal pages help us get from feature requests into actual plans. This page is about fixing the linked-labels feature of Audacity. The text and discussion makes it clear that this a design problem, not just one of implementing missing functionality.|
Proposal pages are used on an ongoing basis by the Audacity development team and are open to edits from visitors to the wiki. They are a good way to get community feedback on a proposal.
- Note: Proposals for Google Summer of Code projects are significantly different in structure, are submitted via Google's web app and may or may not have a corresponding proposal page.
As of 10 February 2010 linking and everything to do with it is a mess. Here are some proposals for how to fix it.
Backing for doing something to fix this:
- Al, James, Martyn, Vaughan, Gale, Ashton.
AWD: I assume any real solution to the linking woes involves:
- Fixing the iterators to use the original definition of a track group: n audio tracks followed by m label tracks (currently only one label track is allowed).
- Make it easier for code that needs linking behavior to get it correctly.
- Get rid of all the incorrect re-implementations of the iterators (see pretty much every place where grouping behavior is handled: cut, paste, clear, just about every effect etc.) and replace by using those easier methods.
Linking affects selection but not action
AWD: This has been proposed by James. The basic idea is that when linking is enabled to only allow selection by group (no selection of tracks independent of their groups). Then actions like Cut/Paste/effects/generators don't have to know about linking at all (major simplification of code).
This is perfect for removing audio, but for inserting it, it's hard to control which tracks receive audio (it's also hard to control which tracks are copied to the clipboard). Some proposals:
- Only insert to the first selected track. If a user wants to insert to a different track s/he can move it.
- Some sort of refinement where the user can select which track(s?) is(/are?) to receive audio or be copied.
I (Al) think that the major strength of this idea is simplicity and orthogonality. Linking isn't even considered in effects, or in Cut/Paste/Clear/etc.
The major weakness is the loss of selection granularity. If there's a refinement where the user can select which tracks receive/copy then that adds the granularity back in a different way, adding back some of the complexity of grouping as it is. And the user-facing part of that complexity would probably have to remain even with linking disabled, if linking is not to effect anything but the selection.
Linking as second-tier selection
AWD: I think the current way we do linking essentially creates a second tier of selection. We just don't present it that way to the user or to ourselves. So my proposal goes something like:
- Selection means exactly what it does now.
- Show users the "second-tier selection" somehow. Maybe a diagonally-striped selection tint.
- Add bool Track::IsGroupSelected(), which checks whether any track in this track's group is selected using the group iterators.
- Use that in all the peripheral places possible instead of dealing with the group iterators.
- Get rid of the distinction between Track::HandleClear() and Track::Clear(). Track::Clear() shouldn't be clearing from other tracks; if it's dead-simple to figure out whether a track is in a selected group there's no need to put "group clearing" or "group pasting" in the Track class.
James: +1. Well argued! Can we come up with a better name than 'second tier'? I think it would help sell this suggestion. I'm looking for something that gets across the idea that this is about preserving time. Do we call our two types of selection audio-selection and synchro-selection? Can we also firm up the idea of how to represent the 'less intense' selection visually? Diagonal bands are too like 'on-demand' for me and would cause confusion. Perhaps something to tie-in to the timeline, or perhaps something (watermark?) to tie into the chain symbol? Nothing stops us changing the chain symbol to something better.
- AWD: I'm open to just about anything for a name, and for visuals. Synchro selection sounds fine. As for visuals... A lighter selection tint with a watermark could work really well. I'll give that a shot.
- David: Just checking something. If a user wants to insert/paste some audio at the cursor position in a group of tracks, then is there some action to take on the audio in the other tracks which is what the user wants in the vast majority of cases. If not, then the added complexity of this proprosal may not be worth it - using the previous proposal, the user can always ungroup, move and paste audio as required, and then regroup if desired. For example, if the cursor is in the middle of one or more clips in the other tracks, is it going to be normally right just to time shift the audio in these tracks, of might the user reasonalby often want to leave some of these clips unchanged but shift the clips that started at a later time.
(These are smaller ideas that could fit under any scheme)
- AWD: Possibly change the definition of track groups so that if you have some audio tracks but no label tracks it's still a group. I understand that the original point of this feature was to keep labels synchronized, but it turns out after taking the full implications into account that labels are really secondary to the feature.
- JKC: +1. Makes the linking icon more useful.
- AWD: Along similar lines, don't use label tracks as the boundary between groups; instead have a dedicated group separator. That way a label track can be at the top of a group, in the middle, anywhere the user wants.
- JKC: +1 - but we could go live without that. Perhaps we could add an 'edge' to the label tracks (now), and later on make that edge into a track in its own right. Particularly like this idea of a dedicated group separator as labels will in time be able to live on audio tracks (space saver).
- David: When it's been decided which proposal to adopt, I'll add some suggestions about additional keystokes etc to ensure this is all accessible.