Re: [Audacity-devel] P3: Labels cannot be repeated ... and more!

[Al D. <bus...@gm...>]

Patches attatched.  I put the P2 cut fix in a different file, since it's an easy 
fix that's unlikely to warrant further discussion.  Revert previous versions of 
the awd_repeat_paste_fixes patch before applying, or dragons will rise from the 
sea and we'll all be doomed then.

On Thursday 15 October 2009 17:10:06 Martyn Shaw wrote:
> Hi Al
> 
> Please see my following post as well, covering whether Label tracks
> should be automatically selected...
> 

In that other post about whether Label tracks should be auto-selected when 
linked you note that I keep changing my mind about it.  This is true.  I also 
seem to keep changing my mind to disagree with the person I'm replying to... 
which is not turning out to be very productive.

My current thinking is: people will almost always want labels completely 
overlapped by the selection repeated, they will almost always want labels 
partially overlapped by the selection extended, and they likely won't want a 
bunch of extra labels spawned when the selection is partially overlapped.  
I've played with labels and thought about label use cases for a couple days, 
and that's what seems right.

I think it's fairly intuitive to have selection of the label track control 
label repeating behavior, even with linking turned on, in the abstract.  If 
fully-overlapped labels always repeat with linking turned on, however, I think 
it's then unintuitive to have the behavior of partially-overlapped labels 
change when the label track is selected.  The second point, to me, is more 
important: fully-overlapped labels should always repeat with linking turned 
on.  So selection doesn't matter if linking is turned on in Version 3.

> Al Dimond wrote:
> ...
> 
> >> Al Dimond wrote:
> >>> On Tuesday 13 October 2009 13:58:28 Al Dimond wrote:
> >>>> Attached is the new version of the paste/repeat fixes patch.  It
> >>>> shouldn't be applied on top of my old patch, so be sure to reverse it
> >>>> first if you have applied it.
> >>
> >> I cleared out old stuff before applying.  Had to put the patch in
> >> audacity\src and use patch -p 1 -i awd_...2
> >
> > Huh.  I usually make the patches outside of the src directory, so paths
> > should be relative to that.  I was able to apply it in my second copy, in
> > the root directory (where src, lib-src, etc.) live, with "patch -p0 <
> > awd_...2.patch".
> 
> Probably my error then, sorry.
> 
> ...
> 
> >>>>  - Label repeating behavior when only one end of the label overlaps
> >>>> the selection is as discussed -- and now the front and back ends of
> >>>> the label work exactly the same way.
> >>
> >> Again, if the new behaviour has been agreed then fair enough.  I think
> >> that labels should only be repeated if they are entirely contained by
> >> the selection, other solutions I have seen do not appear to mean much.
> >>   For example before:
> >> http://dl.getdropbox.com/u/1327769/trackpanel000.png
> >> after repeat 3:
> >> http://dl.getdropbox.com/u/1327769/trackpanel001.png
> >> does not look 'right' to me.  Maybe they should look more like
> >> http://dl.getdropbox.com/u/1327769/trackpanel003.png
> >> (I constructed that one, it may not be sample accurate) since the
> >> 'fish' label still covers all the audio that it covered before
> >> (+repeats of that).
> >
> > The constructed example is what the first patch did (or, at least, what
> > it was supposed to do)
> 
> Then lets make it do what the first patch was supposed to do
> (http://dl.getdropbox.com/u/1327769/trackpanel003.png)!  Your thoughts
> were the same as mine.  It must be right, or at least as good as can
> be done.  The label still cover the RH bit of the track that wasn't
> selected and still starts at the same place.  OK, some of the audio
> inside is not the same as what was there before, that's life.  Same
> arguments obviously apply to selections overlapping labels at the
> other end.  Can you implement that?
> 
> ...

Indeed... it actually is a lot easier than what the second patch did.

> 
> >>>>  - You can copy/paste whitespace at the end of the selection.  This is
> >>>> achieved by inserting a dummy WaveClip with isPlaceholder set.  It's
> >>>> not the most beautiful thing, but it makes Audacity behave more
> >>>> consistently.
> >>
> >> but will probably get a 'users won't like that' response.  Why?
> >> Because they are used to making a lazy selection thus:
> >> http://dl.getdropbox.com/u/1327769/window002.png
> >> (note the highlighted bit in the ruler) expecting to select from 3s to
> >> the end of that clip at 5s (note that I selected off the end of the
> >> first track, from about 3s to about 8.6s).  A 'copy', click at 6s and
> >> then 'paste' gives:
> >> (well that Screen Capture didn't work) an error message saying 'There
> >> is not enough room available to paste the selection'.  But there
> >> really is!
> >
> > I think snapping to clip boundaries makes it easy enough for people to
> > make correct selections; it should be pretty obvious what they've done
> > when they copy/paste extra whitespace, and they can correct their
> > behavior in the future.  Working on this bug convinced me that trying to
> > modify the selection based on clip boundaries is confusing
> 
> I agree that it is the correct behaviour, and that that it should be
> obvious to users.  We shall see!
> 

Indeed.

> > I had never tested anything with the "editing clips allows other clips to
> > move" preference turned off, and now that I have I found a bug related to
> > linking that I'll have to investigate a little more: when that error
> > message appears, some linked tracks already have had extra silence
> > inserted, and it's not removed when the paste is canceled.
> 
> Hmm.  I just saw something similar which can be undone with Ctrl+Z, so
> not a major problem?
> 

What I'm seeing cannot be undone with Ctrl+Z, at least here on Linux.  I'll 
look at it more, but it's not going on this patch... I think I'm declaring 
this patch "feature-complete".

> TTFN
> Martyn
> 

 - Al