Re: [Audacity-devel] Cut removes too much audio

[Bill W. <bi...@go...>]

On 19-Oct-09, at 3:15 PM, Al Dimond wrote:

>> [snip]
>>> Also, if no other tracks are selected, it should just act on all the
>>> tracks in
>>> its group instead of on all the tracks, similar to the rule for
>>> selection.
>>
>> Yes, and the user should see that - i.e. the on-screen selection
>> should extend only to the grouped tracks.
>>
>
> I don't know what you mean, here.  I don't think the "Labeled Regions"
> commands affect which tracks appear selected, whether linking is  
> enabled or
> not.  If you select a label, then deselect all the other tracks and  
> perform a
> "Labeled Region" operation, currently it operates on all of them but  
> doesn't
> show them as selected.  Are you proposing that this be changed?   
> That after
> the operation is complete, all the tracks acted on should be  
> selected?  I
> think that might be a nice change.

What I meant was, if a command is going to act on all tracks in a  
group, then the user should see those tracks selected before the  
action takes place. If a user chooses Cut, and audio is cut from  
tracks that do not show a selection, isn't that bad UI behaviour?

>

>> [snip]

>> What does it mean to have a track group?
>>
>> 1) For consistency, if there is a selection in one track of a group,
>> that selection should extend to all tracks in the group, and exclude
>> tracks outside the group (unless the user explicitly adds them?).
>> 1a) Clicking in the track panel of a track group selects all tracks  
>> in
>> the group and deselects any previously-selected tracks.
>> 1b) Dragging a selection in one track of a group extends that
>> selection to all tracks in the group and deselects any previously-
>> selected tracks.
>> 1c) Shift-clicking on the track panel of a track in a group to
>> deselect that track is an error - needs an explanatory warning  
>> dialog.
>> Similarly, using the arrow keys to give focus to a track in a group
>> then pressing enter to deselect that track is an error.
>>
>> The question remains as to whether the label track should be included
>> in these selections. Probably yes, since it is technically part of  
>> the
>> group. This would emphasize that one is dealing with a group.
>>
>
> This is where my point above comes in.  The point of grouping is not  
> that
> every action done to one must be done to all -- just that their  
> timelines are
> changed together.  There are important differences between a track  
> being
> selected and being grouped.

But in order to keep the timelines synchronized, whatever you do to  
one track in the group *must* be done to the others. If you cut  
something from one track it must be cut from all tracks in order to  
keep everything after the cut in sync. If you don't want this to  
happen, turn off the group.

>
> It's possible that this definition of grouping is too complicated.  It
> certainly complicates the code (pretty much every operation that can  
> insert or
> remove audio has to explicitly account for grouping, and the fact  
> that many of
> them don't yet is the reason there are so many weird bugs with  
> linking turned
> on).  And my explanation above about why label tracks have to be  
> changed when
> grouped tracks change... that ain't simple either.  Something like  
> what you're
> talking about, where grouping was handled entirely by manipulating the
> selection, would be easier for users and programmers to understand.   
> It would
> be less powerful, and the difficulty is that for some operations the  
> loss of
> power would be insignificant, and for others it would be very  
> significant.

Less powerful in what way?

>
>> 2) Clicking on a label below a track group selects only the tracks in
>> the group and deselects any previously-selected tracks. Perhaps we
>> could allow shift-clicking on a label to include any previously-
>> selected tracks, but that might introduce too many complications.
>> Instead the user could drag the wanted track into the group. But then
>> we have to watch for that situation and extend the selection to the
>> track that is now part of the group.
>>
>> UI suggestion: when a track group is selected, outline the group with
>> an orange (for example) border. That way the user explicitly sees the
>> group.
>
> In my opinion we do need something like this -- some visual  
> indicator that
> something new has been created when a user goes from two wave tracks  
> to two
> wave tracks and a label track.  Maybe a different-colored group  
> indicator for
> each group.  My understanding is that grouping will probably be  
> disabled for
> 2.0 and that post-2.0 we'll revisit the whole concept, maybe even  
> considering
> a change in definition.

I can't help thinking of how Pro Tools handles this. I'm not saying  
Pro Tools is the be-all and end-all, it's just what I've been exposed  
to. Pro Tools has track groups, but no labels. (Well, it has one label  
track at the top of the edit window, but that label track is not tied  
to any particular audio track.) Track groups are created by selecting  
the desired tracks and saying "Group Tracks". The group is given a  
name and a colour. The waveforms don't change colour, but (as I  
recall) there is a little dot in the track panel that indicates that  
the tracks are part of a group. The group can be enabled and disabled.  
The indicator in the track panel goes away if the group is disabled.  
There's a panel in the edit window that lists all your groups. Enabled  
groups are highlighted. You can enable and disable groups by clicking  
on their names in this panel. When a group is enabled any editing you  
do in one track affects the other tracks in the group. Groups can  
overlap. You can have your "Drum" group that just has the drum tracks,  
and your "Rhythm Bed" group that includes the drum tracks plus the  
bass and rhythm guitar.

Disclaimer: it's been over a year since I've sat in front of a Pro  
Tools system, so my memory may be a little hazy on some of the  
details. Also, this was Pro Tools 6LE, and they're up to version 8 now.

So my thinking now (and I reserve the right to change my mind), is  
that it is perhaps a mistake to tie groups to labels. Let groups be a  
thing unto themselves, that can include label tracks if you want.  
Carefully define what a group is and what it does, then implement that.

What do Audacity's users want? Is Audacity relentlessly marching down  
the road to becoming a digital audio workstation? Will it then be too  
complex for people who want to digitize their LPs or make podcasts? If  
people outgrow Audacity, there's always Ardour.

But, as you say, this is a bigger discussion best left until after 2.0  
is released. Just had to get this off my chest.

>
>> Or perhaps the yellow "focus" border could go around the group.
>> The question remains as to whether the user should be allowed to
>> change this focus with the keyboard (almost certainly yes, for VI
>> users at least), and what the implications are of moving focus  
>> outside
>> the group. This is a question of whether the user should be allowed  
>> to
>> add tracks outside the group to the selection.
>>
>
> I think the user has to be able to select a group along with non- 
> grouped
> tracks, because otherwise it's hard to keep an entire project  
> synchronized.

Agreed. At least for time-shifting. Possibly also for cut and paste.

-- Bill