Audacity › audacity-devel

P3: Labels cannot be repeated ... and more!

52 messages

1 2 3

Al Dimond

P3: Labels cannot be repeated ... and more!

Reply Threaded

I was looking at this bug, which probably won't be very important if
linking/"track groups" wind up being disabled, as was discussed in the "Edit >
Cut removes too much audio when label track included in selection" thread.
But I ran into a couple other issues with repeat and paste that I thought were
significant. Attached is a patch that fixes a lot of weird repeat and paste
behavior.

1. The labels thing. Labels get repeated if the label track is selected. If
it's not selected they don't get repeated. I think this is more logical than
making them repeat whenever linking is enabled. I don't really know how real
people use labels, though, or the repeat effect, for that matter... so I could
be wrong. If linking is not enabled in the future that's a moot point.

2. You have two tracks that do not end at quite the same time. You select
from some point to the end of the longer one and bring the shorter one into
the selection. You use the repeat effect. Existing behavior: the repeated
sections are not synchronized. Patched behavior: the repeated sections are
synchronized (there is whitespace at the end of each one.

3. Same thing, except at the beginning of tracks. The reason this is a
separate point is that it was a bug in paste, not repeat. When you paste a
track that starts with whitespace into the middle of a clip the whitespace is
not accounted for in that clip (it is, however, accounted for when shifting
other clips around). The patch fixes that (by making pastes that start with
whitespace act like multi-clip pastes), thus making repeat work at the
beginning of tracks.

There's a similar issue with copying/pasting tracks that end in whitespace,
but for a different reason: WaveTrack doesn't represent whitespace at the end
of tracks. Because of this it is harder to fix, but it doesn't affect repeats
or shift clips inconsistently so it's less of a problem. It probably causes
problems with multi-track pastes into the middle of projects. The fix for that
would have to go in AudacityProject::OnPaste(), and I can imagine what it
might look like but touching OnPaste() looks dangerous.

- Al

[awd_repeat_paste_fixes.patch]

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

Hi Al

I applied this patch and had a go..

Al Dimond wrote:

> I was looking at this bug, which probably won't be very important if
> linking/"track groups" wind up being disabled, as was discussed in the "Edit >
> Cut removes too much audio when label track included in selection" thread.
> But I ran into a couple other issues with repeat and paste that I thought were
> significant. Attached is a patch that fixes a lot of weird repeat and paste
> behavior.
>
> 1. The labels thing. Labels get repeated if the label track is selected. If
> it's not selected they don't get repeated. I think this is more logical than
> making them repeat whenever linking is enabled. I don't really know how real
> people use labels, though, or the repeat effect, for that matter... so I could
> be wrong. If linking is not enabled in the future that's a moot point.

Works for me if completely selected. Overlaps with L or R end are
problematic (see below).

> 2. You have two tracks that do not end at quite the same time. You select
> from some point to the end of the longer one and bring the shorter one into
> the selection. You use the repeat effect. Existing behavior: the repeated
> sections are not synchronized. Patched behavior: the repeated sections are
> synchronized (there is whitespace at the end of each one.

Audio bit works for me, as described. However if you don't select the
shorter one as well (the second track for me) then extra unneeded
silence gets inserted into the unselected track.

Label only gets repeated if both ends are inside the selected region,
which seems sensible.

> 3. Same thing, except at the beginning of tracks. The reason this is a
> separate point is that it was a bug in paste, not repeat. When you paste a
> track that starts with whitespace into the middle of a clip the whitespace is
> not accounted for in that clip (it is, however, accounted for when shifting
> other clips around). The patch fixes that (by making pastes that start with
> whitespace act like multi-clip pastes), thus making repeat work at the
> beginning of tracks.

Audio bit works for me, as described. However the label gets extended
if just the LH end is inside the selection, which I don't think is
right. I would just leave the single copy, as in 2).

Also if the label track is selected as well, and just the LH end is
inside the selection, the RH ends of the new labels are not getting
set correctly (visibly a major problem, probably a minor coding error.

TTFN
Martyn

> There's a similar issue with copying/pasting tracks that end in whitespace,
> but for a different reason: WaveTrack doesn't represent whitespace at the end
> of tracks. Because of this it is harder to fix, but it doesn't affect repeats
> or shift clips inconsistently so it's less of a problem. It probably causes
> problems with multi-track pastes into the middle of projects. The fix for that
> would have to go in AudacityProject::OnPaste(), and I can imagine what it
> might look like but touching OnPaste() looks dangerous.
>
> - Al
>
>
> ------------------------------------------------------------------------
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

On Saturday 10 October 2009 14:22:25 Martyn Shaw wrote:

> Hi Al
>
> I applied this patch and had a go..
>
> Al Dimond wrote:
> > I was looking at this bug, which probably won't be very important if
> > linking/"track groups" wind up being disabled, as was discussed in the
> > "Edit > Cut removes too much audio when label track included in
> > selection" thread. But I ran into a couple other issues with repeat and
> > paste that I thought were significant. Attached is a patch that fixes a
> > lot of weird repeat and paste behavior.
> >
> > 1. The labels thing. Labels get repeated if the label track is selected.
> > If it's not selected they don't get repeated. I think this is more
> > logical than making them repeat whenever linking is enabled. I don't
> > really know how real people use labels, though, or the repeat effect, for
> > that matter... so I could be wrong. If linking is not enabled in the
> > future that's a moot point.
>
> Works for me if completely selected. Overlaps with L or R end are
> problematic (see below).
>
> > 2. You have two tracks that do not end at quite the same time. You
> > select from some point to the end of the longer one and bring the shorter
> > one into the selection. You use the repeat effect. Existing behavior:
> > the repeated sections are not synchronized. Patched behavior: the
> > repeated sections are synchronized (there is whitespace at the end of
> > each one.
>
> Audio bit works for me, as described. However if you don't select the
> shorter one as well (the second track for me) then extra unneeded
> silence gets inserted into the unselected track.
>

That actually happens whether the patch is applied or not (I just reversed the
patch, rebuilt, and got the exact same behavior). It comes from
WaveTrack::HandleGroupPaste(), so it only happens when linking is turned on.
There are lots of similarly annoying behaviors when linking is turned on
(generators, IIRC, cause corresponding silence to be pasted into linked
tracks... I think it would be less annoying if whitespace was inserted
instead, but I'm not entirely sure of that).

> Label only gets repeated if both ends are inside the selected region,
> which seems sensible.
>
> > 3. Same thing, except at the beginning of tracks. The reason this is a
> > separate point is that it was a bug in paste, not repeat. When you paste
> > a track that starts with whitespace into the middle of a clip the
> > whitespace is not accounted for in that clip (it is, however, accounted
> > for when shifting other clips around). The patch fixes that (by making
> > pastes that start with whitespace act like multi-clip pastes), thus
> > making repeat work at the beginning of tracks.
>
> Audio bit works for me, as described. However the label gets extended
> if just the LH end is inside the selection, which I don't think is
> right. I would just leave the single copy, as in 2).
>

I actually never checked what it did if you repeated a region only overlapping
the RH side of a label. I actually like the behavior when you have just the
left side overlapped better. If you have audio that says "cha-ching", and a
label extending from the middle of the "cha" to the middle of the "ching",
then you repeat the "cha" twice, the audio now goes "cha-cha-cha-ching!" And
the label extends from the first "cha" through the "ching", which I think is
right. One way or another, the two behaviors should match. I don't think
changing them either way would be that hard.

I should mention that neither of these behaviors are new to the patch, and
result from the behavior of WaveTrack::HandleGroupPaste().

> Also if the label track is selected as well, and just the LH end is
> inside the selection, the RH ends of the new labels are not getting
> set correctly (visibly a major problem, probably a minor coding error.
>

This is intentional. Again, with the "cha-ching" example, now you have a
label extending from each "cha" through its concluding "ching". It doesn't
make any sense for the labels to end somewhere in the middle of a repeating
segment when they were initially drawn out to a point after it.

- Al

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

| From Al Dimond <[hidden email]>
| Sat, 10 Oct 2009 16:38:43 -0600
| Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!

> On Saturday 10 October 2009 14:22:25 Martyn Shaw wrote:
> > Hi Al
> >
> > I applied this patch and had a go..
> >
> > Al Dimond wrote:
> > > I was looking at this bug, which probably won't be very important if
> > > linking/"track groups" wind up being disabled, as was discussed in the
> > > "Edit > Cut removes too much audio when label track included in
> > > selection" thread. But I ran into a couple other issues with repeat and
> > > paste that I thought were significant. Attached is a patch that fixes a
> > > lot of weird repeat and paste behavior.
> > >
> > > 1. The labels thing. Labels get repeated if the label track is selected.
> > > If it's not selected they don't get repeated. I think this is more
> > > logical than making them repeat whenever linking is enabled. I don't
> > > really know how real people use labels, though, or the repeat effect, for
> > > that matter... so I could be wrong. If linking is not enabled in the
> > > future that's a moot point.
> >
> > Works for me if completely selected. Overlaps with L or R end are
> > problematic (see below).

It's "possibly" more useful that labels are not repeated unless
included in the selection, otherwise the user who doesn't want to
repeat the label has to turn linking off while doing the repeat.

I think one viewpoint could state it isn't "logical", since audio and
label tracks are supposed to be a unit.

Given you can repeat the label with linking off by including it in
the selection, making the user include it when linking is on does
water down the distinction between linking "on" and "off".

> > > 2. You have two tracks that do not end at quite the same time. You
> > > select from some point to the end of the longer one and bring the shorter
> > > one into the selection. You use the repeat effect. Existing behavior:
> > > the repeated sections are not synchronized. Patched behavior: the
> > > repeated sections are synchronized (there is whitespace at the end of
> > > each one.

Clearly that's better than before, but behaviour is the same whether
linking is on or off. The second track is not synchronised with the
first, because the ends of each track are not at the same point on the
timeline. The implication with current linking behaviour is that
silence would be inserted where the white space is, up to the end of
the longer track.

> > Audio bit works for me, as described. However if you don't select the
> > shorter one as well (the second track for me) then extra unneeded
> > silence gets inserted into the unselected track.
> >
>
> That actually happens whether the patch is applied or not (I just reversed the
> patch, rebuilt, and got the exact same behavior). It comes from
> WaveTrack::HandleGroupPaste(), so it only happens when linking is turned on.
> There are lots of similarly annoying behaviors when linking is turned on
> (generators, IIRC, cause corresponding silence to be pasted into linked
> tracks... I think it would be less annoying if whitespace was inserted
> instead, but I'm not entirely sure of that).

As you know, whether white space should be treated as silence has
been debated a lot recently.

However if you select only the longer track when linking is on and
repeat it, what happens looks wrong to me, because silence is only
inserted into the unselected track corresponding to the length of
the repeat (with whitespace to left of the silence). That creates
a separate clip which the user didn't ask for.

> > Label only gets repeated if both ends are inside the selected region,
> > which seems sensible.
> >
> > > 3. Same thing, except at the beginning of tracks. The reason this is a
> > > separate point is that it was a bug in paste, not repeat. When you paste
> > > a track that starts with whitespace into the middle of a clip the
> > > whitespace is not accounted for in that clip (it is, however, accounted
> > > for when shifting other clips around). The patch fixes that (by making
> > > pastes that start with whitespace act like multi-clip pastes), thus
> > > making repeat work at the beginning of tracks.
> >
> > Audio bit works for me, as described.

It doesn't work for me though if I time shift a clip to start at 1s, then
select from there to zero and repeat. The whitespace is ignored.

>> However the label gets extended if just the LH end is inside the selection, .
>> which I don't think is right. I would just leave the single copy, as in 2).
> >
>
> I actually never checked what it did if you repeated a region only overlapping
> the RH side of a label. I actually like the behavior when you have just the
> left side overlapped better. If you have audio that says "cha-ching", and a
> label extending from the middle of the "cha" to the middle of the "ching",
> then you repeat the "cha" twice, the audio now goes "cha-cha-cha-ching!" And
> the label extends from the first "cha" through the "ching", which I think is
> right. One way or another, the two behaviors should match. I don't think
> changing them either way would be that hard.
>
> I should mention that neither of these behaviors are new to the patch, and
> result from the behavior of WaveTrack::HandleGroupPaste().

I think the label getting extended is OK, if done when selecting an
overlap on either edge. But see below.

> > Also if the label track is selected as well, and just the LH end is
> > inside the selection, the RH ends of the new labels are not getting
> > set correctly (visibly a major problem, probably a minor coding error.
> >
>
> This is intentional. Again, with the "cha-ching" example, now you have a
> label extending from each "cha" through its concluding "ching". It doesn't
> make any sense for the labels to end somewhere in the middle of a repeating
> segment when they were initially drawn out to a point after it.

Clearly the label which has been inserted within the old label doesn't
mark the region which has been repeated, which is what I would have
expected. If I select all the first "cha" to repeat once, with the label
starting in the middle of that "cha", the inserted label goes from
halfway through the second "cha" to halfway through the "ching".
I agree with Martyn that's wrong.

On a related subject, from "Release Checklist not aiming" we have this:

" Repeat: If selection area made at end of clip strays into white space,
the selection area after the repeat is not the full length of the repeated
area, but is reduced by the excess length of the selection area made
before running Repeat. Note: a case could be made that if you select
beyond the end of your clip or track into the white space, repeat
"should" repeat what you selected (and then select the entirety of
that repeated area). This would be useful in some cases. If you need
to select exactly the clip that you want to repeat, you can always do
so by double-clicking inside it. "

It seems the part before "Note" has already been fixed (before your
patch), but maybe now we're taking white space into account in the
case of "white space before track start" we should also do so with
"white space after track end"? At the moment, neither paste or repeat
seems to take it into account.

As Martyn might say,

Cha-Cha for now.

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

On Sunday 11 October 2009 17:32:58 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Sat, 10 Oct 2009 16:38:43 -0600
> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> |
> > On Saturday 10 October 2009 14:22:25 Martyn Shaw wrote:
> > > Hi Al
> > >
> > > I applied this patch and had a go..
> > >
> > > Al Dimond wrote:
> > > > I was looking at this bug, which probably won't be very important if
> > > > linking/"track groups" wind up being disabled, as was discussed in
> > > > the "Edit > Cut removes too much audio when label track included in
> > > > selection" thread. But I ran into a couple other issues with repeat
> > > > and paste that I thought were significant. Attached is a patch that
> > > > fixes a lot of weird repeat and paste behavior.
> > > >
> > > > 1. The labels thing. Labels get repeated if the label track is
> > > > selected. If it's not selected they don't get repeated. I think this
> > > > is more logical than making them repeat whenever linking is enabled.
> > > > I don't really know how real people use labels, though, or the repeat
> > > > effect, for that matter... so I could be wrong. If linking is not
> > > > enabled in the future that's a moot point.
> > >
> > > Works for me if completely selected. Overlaps with L or R end are
> > > problematic (see below).
>
> It's "possibly" more useful that labels are not repeated unless
> included in the selection, otherwise the user who doesn't want to
> repeat the label has to turn linking off while doing the repeat.
>
> I think one viewpoint could state it isn't "logical", since audio and
> label tracks are supposed to be a unit.
>
> Given you can repeat the label with linking off by including it in
> the selection, making the user include it when linking is on does
> water down the distinction between linking "on" and "off".
>

The way it is now is analagous to what happens with other linked WaveTracks:
if you don't have linking turned on and they're not selected, nothing happens.
If you have linking turned on and they're not selected, they get silence
inserted (in the case of labels, that can mean a label gets extended). And if
you have them selected, they repeat. That's the initial reason I made a
distinction between selected and not with linking enabled. I'm not sure
either way is right or wrong... it depends on how you think about it.

When I do the next patch I'll do it with label tracks repeating any time
they're linked.

> > > > 2. You have two tracks that do not end at quite the same time. You
> > > > select from some point to the end of the longer one and bring the
> > > > shorter one into the selection. You use the repeat effect. Existing
> > > > behavior: the repeated sections are not synchronized. Patched
> > > > behavior: the repeated sections are synchronized (there is whitespace
> > > > at the end of each one.
>
> Clearly that's better than before, but behaviour is the same whether
> linking is on or off. The second track is not synchronised with the
> first, because the ends of each track are not at the same point on the
> timeline. The implication with current linking behaviour is that
> silence would be inserted where the white space is, up to the end of
> the longer track.
>

I hadn't considered that. Do I understand that we agree that when both the
longer and shorter track are selected they should stay synchronized on a
repeat, regardless of whether linking is enabled? But then you're also
saying: if linking is turned on, the shorter track should act like it ends
when the longer track does, even if the longer track is not selected. If
that's what you mean, then I agree. I can change that.

> > > Audio bit works for me, as described. However if you don't select the
> > > shorter one as well (the second track for me) then extra unneeded
> > > silence gets inserted into the unselected track.
> >
> > That actually happens whether the patch is applied or not (I just
> > reversed the patch, rebuilt, and got the exact same behavior). It comes
> > from WaveTrack::HandleGroupPaste(), so it only happens when linking is
> > turned on. There are lots of similarly annoying behaviors when linking is
> > turned on (generators, IIRC, cause corresponding silence to be pasted
> > into linked tracks... I think it would be less annoying if whitespace was
> > inserted instead, but I'm not entirely sure of that).
>
> As you know, whether white space should be treated as silence has
> been debated a lot recently.
>
> However if you select only the longer track when linking is on and
> repeat it, what happens looks wrong to me, because silence is only
> inserted into the unselected track corresponding to the length of
> the repeat (with whitespace to left of the silence). That creates
> a separate clip which the user didn't ask for.
>

I agree that it's bad. When I noticed it (and, again, it's not new to the
patch, it's always acted this way with linking enabled) I thought it would be
really hard to fix, so I left it. Having thought about it a little more, there
should be a reasonably good solution possible in HandleGroupPaste() that will
probably also solve some of the other screwy behavior where new clips get
created in the middle of whitespace with linking enabled. I'll get that in
the next patch, too. And I promise not to split any clips where they aren't
already being split now, as that would probably start a holy war.

> > > Label only gets repeated if both ends are inside the selected region,
> > > which seems sensible.
> > >
> > > > 3. Same thing, except at the beginning of tracks. The reason this is
> > > > a separate point is that it was a bug in paste, not repeat. When you
> > > > paste a track that starts with whitespace into the middle of a clip
> > > > the whitespace is not accounted for in that clip (it is, however,
> > > > accounted for when shifting other clips around). The patch fixes
> > > > that (by making pastes that start with whitespace act like multi-clip
> > > > pastes), thus making repeat work at the beginning of tracks.
> > >
> > > Audio bit works for me, as described.
>
> It doesn't work for me though if I time shift a clip to start at 1s, then
> select from there to zero and repeat. The whitespace is ignored.
>

The whitespace only repeats if there's another track selected with a clip
during that time. If you have another track selected that starts at .5, only
the whitespace from .5 to 1 will be repeated. If there's another selected
track going all the way back to zero the whole whitespace repeats. That's the
behavior I see... are you getting something different?

The original behavior was that whitespace at the beginning/end of tracks was
not repeated, and I wanted to keep that the same if just one track, or a set
of tracks ending at the same time, was selected. If people agree that it
would be better to always repeat whitespace within the selection, well, that
only makes the code simpler, so I'm all for it.

> >> However the label gets extended if just the LH end is inside the
> >> selection, . which I don't think is right. I would just leave the
> >> single copy, as in 2).
> >
> > I actually never checked what it did if you repeated a region only
> > overlapping the RH side of a label. I actually like the behavior when
> > you have just the left side overlapped better. If you have audio that
> > says "cha-ching", and a label extending from the middle of the "cha" to
> > the middle of the "ching", then you repeat the "cha" twice, the audio now
> > goes "cha-cha-cha-ching!" And the label extends from the first "cha"
> > through the "ching", which I think is right. One way or another, the two
> > behaviors should match. I don't think changing them either way would be
> > that hard.
> >
> > I should mention that neither of these behaviors are new to the patch,
> > and result from the behavior of WaveTrack::HandleGroupPaste().
>
> I think the label getting extended is OK, if done when selecting an
> overlap on either edge. But see below.
>
> > > Also if the label track is selected as well, and just the LH end is
> > > inside the selection, the RH ends of the new labels are not getting
> > > set correctly (visibly a major problem, probably a minor coding error.
> >
> > This is intentional. Again, with the "cha-ching" example, now you have a
> > label extending from each "cha" through its concluding "ching". It
> > doesn't make any sense for the labels to end somewhere in the middle of a
> > repeating segment when they were initially drawn out to a point after it.
>
> Clearly the label which has been inserted within the old label doesn't
> mark the region which has been repeated, which is what I would have
> expected. If I select all the first "cha" to repeat once, with the label
> starting in the middle of that "cha", the inserted label goes from
> halfway through the second "cha" to halfway through the "ching".
> I agree with Martyn that's wrong.
>

So you think the newly created labels should go from the middle of a "cha" to
the middle of a "cha", right? That they should be exactly the length of the
repeated segment? That sounds like a fine idea to me. Honestly, I hadn't
thought of that... the only idea I thought of for length for the new labels,
other than how it turned out in the patch, was "the same length as the
original label", which I didn't like at all.

I'll do this in the new patch, too.

> On a related subject, from "Release Checklist not aiming" we have this:
>
> " Repeat: If selection area made at end of clip strays into white space,
> the selection area after the repeat is not the full length of the
> repeated area, but is reduced by the excess length of the selection area
> made before running Repeat. Note: a case could be made that if you select
> beyond the end of your clip or track into the white space, repeat "should"
> repeat what you selected (and then select the entirety of that repeated
> area). This would be useful in some cases. If you need to select exactly
> the clip that you want to repeat, you can always do so by double-clicking
> inside it. "
>
> It seems the part before "Note" has already been fixed (before your
> patch), but maybe now we're taking white space into account in the
> case of "white space before track start" we should also do so with
> "white space after track end"? At the moment, neither paste or repeat
> seems to take it into account.
>

Getting repeat to take excess whitespace into account even when there's only
one track selected would be very easy (easier than what it does now, by far).
Getting copy/paste to take whitespace at the beginning of a selection into
account wasn't all that hard.

But getting general copy/paste to take into account whitespace at the end of a
selection would be a lot harder, because WaveTracks cannot represent
whitespace at the end of tracks. A track contains clips, and if the first clip
starts at time x, where x > 0, we consider there to be whitespace between 0
and x. There is no similar standard way to know the amount of whitespace that
"exists" at the end of a track. I don't think one would be useful, for that
matter.

Maybe when copying an area that ends in whitespace extra silence could be
added to the clipboard track with the length of the whitespace. It could be
made its own clip, even, for easy deletion... maybe even add a flag to WaveClip
that means something like "this clip is a placeholder for whitespace, so don't
paste it in, just make room for it". It's a bit of a hack, but it would make
things work better. I'll try to do this in the new patch and see how it comes
out.

This new patch I keep talking about will not get done tonight, because of the
CPU usage stuff. Maybe tomorrow, depending on how that is going.

>
> As Martyn might say,
>
> Cha-Cha for now.
>

Hehe. Good evening.

- Al

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Gale (Audacity Team)

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

| From Al Dimond <[hidden email]>
| Sun, 11 Oct 2009 19:27:13 -0600
| Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!

> On Sunday 11 October 2009 17:32:58 Gale Andrews wrote:
> > | From Al Dimond <[hidden email]>
> > | Sat, 10 Oct 2009 16:38:43 -0600
> > | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> > |
> > > On Saturday 10 October 2009 14:22:25 Martyn Shaw wrote:
> > > > Hi Al
> > > >
> > > > I applied this patch and had a go..
> > > >
> > > > Al Dimond wrote:
> > > > > I was looking at this bug, which probably won't be very important if
> > > > > linking/"track groups" wind up being disabled, as was discussed in
> > > > > the "Edit > Cut removes too much audio when label track included in
> > > > > selection" thread. But I ran into a couple other issues with repeat
> > > > > and paste that I thought were significant. Attached is a patch that
> > > > > fixes a lot of weird repeat and paste behavior.
> > > > >
> > > > > 1. The labels thing. Labels get repeated if the label track is
> > > > > selected. If it's not selected they don't get repeated. I think this
> > > > > is more logical than making them repeat whenever linking is enabled.
> > > > > I don't really know how real people use labels, though, or the repeat
> > > > > effect, for that matter... so I could be wrong. If linking is not
> > > > > enabled in the future that's a moot point.
> > > >
> > > > Works for me if completely selected. Overlaps with L or R end are
> > > > problematic (see below).
> >
> > It's "possibly" more useful that labels are not repeated unless
> > included in the selection, otherwise the user who doesn't want to
> > repeat the label has to turn linking off while doing the repeat.
> >
> > I think one viewpoint could state it isn't "logical", since audio and
> > label tracks are supposed to be a unit.
> >
> > Given you can repeat the label with linking off by including it in
> > the selection, making the user include it when linking is on does
> > water down the distinction between linking "on" and "off".
> >
>
> The way it is now is analagous to what happens with other linked WaveTracks:
> if you don't have linking turned on and they're not selected, nothing happens.
> If you have linking turned on and they're not selected, they get silence
> inserted (in the case of labels, that can mean a label gets extended). And if
> you have them selected, they repeat. That's the initial reason I made a
> distinction between selected and not with linking enabled. I'm not sure
> either way is right or wrong... it depends on how you think about it.
>
> When I do the next patch I'll do it with label tracks repeating any time
> they're linked.

This isn't an easy decision to make, but the way I see it, labels
are affected by actions in linked audio tracks even when the
label track is not selected, as you describe, including by timeline
changing (where it works - it seems at the moment that changing
speed on one of two linked audio tracks isn't currently affecting
the second track at all).

If you imagine the case where you have amplified a region of
audio and labelled it, then you select a region starting before
that label, extend it to after the label then apply negative
change speed, the label track won't be selected, but it would
seem obvious the label should be extended and moved right if
linking is on. Otherwise, the label simply no longer relates to
the original amplified piece of audio which was supposed to be
the point of linking. Needless to say, nothing currently happens
to the label track now.

With Repeat, perhaps it's less obvious what should happen
if you don't include the label track in the above scenario,
because if nothing happens the label will still relate to
the original audio (in one sense). But given the above cases
where clearly not selecting the label track still affects labels,
it seems odd to me not to repeat the labels when selecting
only the audio track.

> > > > > 2. You have two tracks that do not end at quite the same time. You
> > > > > select from some point to the end of the longer one and bring the
> > > > > shorter one into the selection. You use the repeat effect. Existing
> > > > > behavior: the repeated sections are not synchronized. Patched
> > > > > behavior: the repeated sections are synchronized (there is whitespace
> > > > > at the end of each one.
> >
> > Clearly that's better than before, but behaviour is the same whether
> > linking is on or off. The second track is not synchronised with the
> > first, because the ends of each track are not at the same point on the
> > timeline. The implication with current linking behaviour is that
> > silence would be inserted where the white space is, up to the end of
> > the longer track.
> >
>
> I hadn't considered that. Do I understand that we agree that when both the
> longer and shorter track are selected they should stay synchronized on a
> repeat, regardless of whether linking is enabled?

I believe so. But that means to be consistent that we have
to capture that white space when copying/cutting and
pasting as well. Currently only the audio is pasted (though
the entire selection region is painted) which is the "Release
Checklist not aiming" suggestion at the bottom of this e-mail.

> But then you're also saying: if linking is turned on, the shorter track
> should act like it ends when the longer track does, even if the longer
> track is not selected. If that's what you mean, then I agree. I can
> change that.

That was the original specification of linked tracks, that the
ends of the tracks would synchronise (the means for which
which was inserting silence).

>
> > > > Label only gets repeated if both ends are inside the selected region,
> > > > which seems sensible.
> > > >
> > > > > 3. Same thing, except at the beginning of tracks. The reason this is
> > > > > a separate point is that it was a bug in paste, not repeat. When you
> > > > > paste a track that starts with whitespace into the middle of a clip
> > > > > the whitespace is not accounted for in that clip (it is, however,
> > > > > accounted for when shifting other clips around). The patch fixes
> > > > > that (by making pastes that start with whitespace act like multi-clip
> > > > > pastes), thus making repeat work at the beginning of tracks.
> > > >
> > > > Audio bit works for me, as described.
> >
> > It doesn't work for me though if I time shift a clip to start at 1s, then
> > select from there to zero and repeat. The whitespace is ignored.
> >
>
> The whitespace only repeats if there's another track selected with a clip
> during that time. If you have another track selected that starts at .5, only
> the whitespace from .5 to 1 will be repeated. If there's another selected
> track going all the way back to zero the whole whitespace repeats. That's the
> behavior I see... are you getting something different?
>
> The original behavior was that whitespace at the beginning/end of tracks was
> not repeated, and I wanted to keep that the same if just one track, or a set
> of tracks ending at the same time, was selected. If people agree that it
> would be better to always repeat whitespace within the selection, well, that
> only makes the code simpler, so I'm all for it.

Yes it's the case where I only select the region in one track
where the whitespace doesn't repeat. I have two tracks and
the upper one has the audio starting at 1s and the lower at 0s.
I select from 0s to 5s in the upper track and Effect > Repeat
(choosing one time to repeat). Whitespace is ignored and the
track is extended by 4s.

If I undo and SHIFT + Down to select both tracks and Repeat
again, the whitespace in the upper track is included in the
repeat. That feels wrong to me.

Also consider the case where both tracks are offset to 1s.
Repeat (in your patch) then ignores the whitespace even if
both tracks are selected.

> > >> However the label gets extended if just the LH end is inside the
> > >> selection, . which I don't think is right. I would just leave the
> > >> single copy, as in 2).
> > >
> > > I actually never checked what it did if you repeated a region only
> > > overlapping the RH side of a label. I actually like the behavior when
> > > you have just the left side overlapped better. If you have audio that
> > > says "cha-ching", and a label extending from the middle of the "cha" to
> > > the middle of the "ching", then you repeat the "cha" twice, the audio now
> > > goes "cha-cha-cha-ching!" And the label extends from the first "cha"
> > > through the "ching", which I think is right. One way or another, the two
> > > behaviors should match. I don't think changing them either way would be
> > > that hard.
> > >
> > > I should mention that neither of these behaviors are new to the patch,
> > > and result from the behavior of WaveTrack::HandleGroupPaste().
> >
> > I think the label getting extended is OK, if done when selecting an
> > overlap on either edge. But see below.
> >
> > > > Also if the label track is selected as well, and just the LH end is
> > > > inside the selection, the RH ends of the new labels are not getting
> > > > set correctly (visibly a major problem, probably a minor coding error.
> > >
> > > This is intentional. Again, with the "cha-ching" example, now you have a
> > > label extending from each "cha" through its concluding "ching". It
> > > doesn't make any sense for the labels to end somewhere in the middle of a
> > > repeating segment when they were initially drawn out to a point after it.
> >
> > Clearly the label which has been inserted within the old label doesn't
> > mark the region which has been repeated, which is what I would have
> > expected. If I select all the first "cha" to repeat once, with the label
> > starting in the middle of that "cha", the inserted label goes from
> > halfway through the second "cha" to halfway through the "ching".
> > I agree with Martyn that's wrong.
> >
>
> So you think the newly created labels should go from the middle of a "cha" to
> the middle of a "cha", right? That they should be exactly the length of the
> repeated segment? That sounds like a fine idea to me. Honestly, I hadn't
> thought of that... the only idea I thought of for length for the new labels,
> other than how it turned out in the patch, was "the same length as the
> original label", which I didn't like at all.

I have my label from middle of "cha" to middle of "ching",
and select the "cha" and repeat it once. What I am suggesting
is that the new label should align with the second "cha",
on the grounds the "cha" was what was repeated.

>
> I'll do this in the new patch, too.
>
> > On a related subject, from "Release Checklist not aiming" we have this:
> >
> > " Repeat: If selection area made at end of clip strays into white space,
> > the selection area after the repeat is not the full length of the
> > repeated area, but is reduced by the excess length of the selection area
> > made before running Repeat. Note: a case could be made that if you select
> > beyond the end of your clip or track into the white space, repeat "should"
> > repeat what you selected (and then select the entirety of that repeated
> > area). This would be useful in some cases. If you need to select exactly
> > the clip that you want to repeat, you can always do so by double-clicking
> > inside it. "
> >
> > It seems the part before "Note" has already been fixed (before your
> > patch), but maybe now we're taking white space into account in the
> > case of "white space before track start" we should also do so with
> > "white space after track end"? At the moment, neither paste or repeat
> > seems to take it into account.
> >
>
> Getting repeat to take excess whitespace into account even when there's only
> one track selected would be very easy (easier than what it does now, by far).
> Getting copy/paste to take whitespace at the beginning of a selection into
> account wasn't all that hard.
>
> But getting general copy/paste to take into account whitespace at the end of a
> selection would be a lot harder, because WaveTracks cannot represent
> whitespace at the end of tracks. A track contains clips, and if the first clip
> starts at time x, where x > 0, we consider there to be whitespace between 0
> and x. There is no similar standard way to know the amount of whitespace that
> "exists" at the end of a track. I don't think one would be useful, for that
> matter.
>
> Maybe when copying an area that ends in whitespace extra silence could be
> added to the clipboard track with the length of the whitespace. It could be
> made its own clip, even, for easy deletion... maybe even add a flag to WaveClip
> that means something like "this clip is a placeholder for whitespace, so don't
> paste it in, just make room for it". It's a bit of a hack, but it would make
> things work better. I'll try to do this in the new patch and see how it comes
> out.

I'm not 100% sure of the use cases users had in mind when
suggesting that whitespace after the end of the track should
be taken into account. It would be a shortcut to creating a
separated clip where you paste. There seems some user
expectation that whitespace should be taken into account
even at the end of the track, and it would be consistent with
other changes you are making.

Thanks

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

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'm top-posting this because the replies are really long and I can't think of
a coherent way to edit them down... so here's a summary of changes:

- Linked label tracks behave exactly the same in repeat as selected ones.

- 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.

- Repeat uses the entire selection length on all repeated tracks, regardless
of when any of them end. This should clear up some of the confusing repeating
problems near the start and end of tracks.

- No more bogus silent clips created in the middle of whitespace due to
repeat or paste with linking turned on. This also seems to affect generate,
which is nice.

- 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.

- I fixed another bug that was bothering me, because it was in the
neighborhood: pasting into multiple tracks (which includes pasting into a
stereo track) didn't observe proper group behavior (so it inserted too much
silence into other grouped tracks). Now it does.

I think that's all. If I forgot to address a problem let me know... there
were lots of them, it's easy for me to lose track :).

- Al

On Monday 12 October 2009 13:30:57 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Sun, 11 Oct 2009 19:27:13 -0600
> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> |
> > On Sunday 11 October 2009 17:32:58 Gale Andrews wrote:
> > > | From Al Dimond <[hidden email]>
> > > | Sat, 10 Oct 2009 16:38:43 -0600
> > > | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> > > |
> > > > On Saturday 10 October 2009 14:22:25 Martyn Shaw wrote:
> > > > > Hi Al
> > > > >
> > > > > I applied this patch and had a go..
> > > > >
> > > > > Al Dimond wrote:
> > > > > > I was looking at this bug, which probably won't be very important
> > > > > > if linking/"track groups" wind up being disabled, as was
> > > > > > discussed in the "Edit > Cut removes too much audio when label
> > > > > > track included in selection" thread. But I ran into a couple
> > > > > > other issues with repeat and paste that I thought were
> > > > > > significant. Attached is a patch that fixes a lot of weird
> > > > > > repeat and paste behavior.
> > > > > >
> > > > > > 1. The labels thing. Labels get repeated if the label track is
> > > > > > selected. If it's not selected they don't get repeated. I think
> > > > > > this is more logical than making them repeat whenever linking is
> > > > > > enabled. I don't really know how real people use labels, though,
> > > > > > or the repeat effect, for that matter... so I could be wrong. If
> > > > > > linking is not enabled in the future that's a moot point.
> > > > >
> > > > > Works for me if completely selected. Overlaps with L or R end are
> > > > > problematic (see below).
> > >
> > > It's "possibly" more useful that labels are not repeated unless
> > > included in the selection, otherwise the user who doesn't want to
> > > repeat the label has to turn linking off while doing the repeat.
> > >
> > > I think one viewpoint could state it isn't "logical", since audio and
> > > label tracks are supposed to be a unit.
> > >
> > > Given you can repeat the label with linking off by including it in
> > > the selection, making the user include it when linking is on does
> > > water down the distinction between linking "on" and "off".
> >
> > The way it is now is analagous to what happens with other linked
> > WaveTracks: if you don't have linking turned on and they're not selected,
> > nothing happens. If you have linking turned on and they're not selected,
> > they get silence inserted (in the case of labels, that can mean a label
> > gets extended). And if you have them selected, they repeat. That's the
> > initial reason I made a distinction between selected and not with linking
> > enabled. I'm not sure either way is right or wrong... it depends on how
> > you think about it.
> >
> > When I do the next patch I'll do it with label tracks repeating any time
> > they're linked.
>
> This isn't an easy decision to make, but the way I see it, labels
> are affected by actions in linked audio tracks even when the
> label track is not selected, as you describe, including by timeline
> changing (where it works - it seems at the moment that changing
> speed on one of two linked audio tracks isn't currently affecting
> the second track at all).
>
> If you imagine the case where you have amplified a region of
> audio and labelled it, then you select a region starting before
> that label, extend it to after the label then apply negative
> change speed, the label track won't be selected, but it would
> seem obvious the label should be extended and moved right if
> linking is on. Otherwise, the label simply no longer relates to
> the original amplified piece of audio which was supposed to be
> the point of linking. Needless to say, nothing currently happens
> to the label track now.
>
> With Repeat, perhaps it's less obvious what should happen
> if you don't include the label track in the above scenario,
> because if nothing happens the label will still relate to
> the original audio (in one sense). But given the above cases
> where clearly not selecting the label track still affects labels,
> it seems odd to me not to repeat the labels when selecting
> only the audio track.
>
> > > > > > 2. You have two tracks that do not end at quite the same time.
> > > > > > You select from some point to the end of the longer one and bring
> > > > > > the shorter one into the selection. You use the repeat effect.
> > > > > > Existing behavior: the repeated sections are not synchronized.
> > > > > > Patched behavior: the repeated sections are synchronized (there
> > > > > > is whitespace at the end of each one.
> > >
> > > Clearly that's better than before, but behaviour is the same whether
> > > linking is on or off. The second track is not synchronised with the
> > > first, because the ends of each track are not at the same point on the
> > > timeline. The implication with current linking behaviour is that
> > > silence would be inserted where the white space is, up to the end of
> > > the longer track.
> >
> > I hadn't considered that. Do I understand that we agree that when both
> > the longer and shorter track are selected they should stay synchronized
> > on a repeat, regardless of whether linking is enabled?
>
> I believe so. But that means to be consistent that we have
> to capture that white space when copying/cutting and
> pasting as well. Currently only the audio is pasted (though
> the entire selection region is painted) which is the "Release
> Checklist not aiming" suggestion at the bottom of this e-mail.
>
> > But then you're also saying: if linking is turned on, the shorter track
> > should act like it ends when the longer track does, even if the longer
> > track is not selected. If that's what you mean, then I agree. I can
> > change that.
>
> That was the original specification of linked tracks, that the
> ends of the tracks would synchronise (the means for which
> which was inserting silence).
>
> > > > > Label only gets repeated if both ends are inside the selected
> > > > > region, which seems sensible.
> > > > >
> > > > > > 3. Same thing, except at the beginning of tracks. The reason
> > > > > > this is a separate point is that it was a bug in paste, not
> > > > > > repeat. When you paste a track that starts with whitespace into
> > > > > > the middle of a clip the whitespace is not accounted for in that
> > > > > > clip (it is, however, accounted for when shifting other clips
> > > > > > around). The patch fixes that (by making pastes that start with
> > > > > > whitespace act like multi-clip pastes), thus making repeat work
> > > > > > at the beginning of tracks.
> > > > >
> > > > > Audio bit works for me, as described.
> > >
> > > It doesn't work for me though if I time shift a clip to start at 1s,
> > > then select from there to zero and repeat. The whitespace is ignored.
> >
> > The whitespace only repeats if there's another track selected with a clip
> > during that time. If you have another track selected that starts at .5,
> > only the whitespace from .5 to 1 will be repeated. If there's another
> > selected track going all the way back to zero the whole whitespace
> > repeats. That's the behavior I see... are you getting something
> > different?
> >
> > The original behavior was that whitespace at the beginning/end of tracks
> > was not repeated, and I wanted to keep that the same if just one track,
> > or a set of tracks ending at the same time, was selected. If people
> > agree that it would be better to always repeat whitespace within the
> > selection, well, that only makes the code simpler, so I'm all for it.
>
> Yes it's the case where I only select the region in one track
> where the whitespace doesn't repeat. I have two tracks and
> the upper one has the audio starting at 1s and the lower at 0s.
> I select from 0s to 5s in the upper track and Effect > Repeat
> (choosing one time to repeat). Whitespace is ignored and the
> track is extended by 4s.
>
> If I undo and SHIFT + Down to select both tracks and Repeat
> again, the whitespace in the upper track is included in the
> repeat. That feels wrong to me.
>
> Also consider the case where both tracks are offset to 1s.
> Repeat (in your patch) then ignores the whitespace even if
> both tracks are selected.
>
> > > >> However the label gets extended if just the LH end is inside the
> > > >> selection, . which I don't think is right. I would just leave the
> > > >> single copy, as in 2).
> > > >
> > > > I actually never checked what it did if you repeated a region only
> > > > overlapping the RH side of a label. I actually like the behavior
> > > > when you have just the left side overlapped better. If you have
> > > > audio that says "cha-ching", and a label extending from the middle of
> > > > the "cha" to the middle of the "ching", then you repeat the "cha"
> > > > twice, the audio now goes "cha-cha-cha-ching!" And the label extends
> > > > from the first "cha" through the "ching", which I think is right. One
> > > > way or another, the two behaviors should match. I don't think
> > > > changing them either way would be that hard.
> > > >
> > > > I should mention that neither of these behaviors are new to the
> > > > patch, and result from the behavior of WaveTrack::HandleGroupPaste().
> > >
> > > I think the label getting extended is OK, if done when selecting an
> > > overlap on either edge. But see below.
> > >
> > > > > Also if the label track is selected as well, and just the LH end is
> > > > > inside the selection, the RH ends of the new labels are not getting
> > > > > set correctly (visibly a major problem, probably a minor coding
> > > > > error.
> > > >
> > > > This is intentional. Again, with the "cha-ching" example, now you
> > > > have a label extending from each "cha" through its concluding
> > > > "ching". It doesn't make any sense for the labels to end somewhere
> > > > in the middle of a repeating segment when they were initially drawn
> > > > out to a point after it.
> > >
> > > Clearly the label which has been inserted within the old label doesn't
> > > mark the region which has been repeated, which is what I would have
> > > expected. If I select all the first "cha" to repeat once, with the
> > > label starting in the middle of that "cha", the inserted label goes
> > > from halfway through the second "cha" to halfway through the "ching". I
> > > agree with Martyn that's wrong.
> >
> > So you think the newly created labels should go from the middle of a
> > "cha" to the middle of a "cha", right? That they should be exactly the
> > length of the repeated segment? That sounds like a fine idea to me.
> > Honestly, I hadn't thought of that... the only idea I thought of for
> > length for the new labels, other than how it turned out in the patch, was
> > "the same length as the original label", which I didn't like at all.
>
> I have my label from middle of "cha" to middle of "ching",
> and select the "cha" and repeat it once. What I am suggesting
> is that the new label should align with the second "cha",
> on the grounds the "cha" was what was repeated.
>
> > I'll do this in the new patch, too.
> >
> > > On a related subject, from "Release Checklist not aiming" we have this:
> > >
> > > " Repeat: If selection area made at end of clip strays into white
> > > space, the selection area after the repeat is not the full length of
> > > the repeated area, but is reduced by the excess length of the selection
> > > area made before running Repeat. Note: a case could be made that if you
> > > select beyond the end of your clip or track into the white space,
> > > repeat "should" repeat what you selected (and then select the entirety
> > > of that repeated area). This would be useful in some cases. If you need
> > > to select exactly the clip that you want to repeat, you can always do
> > > so by double-clicking inside it. "
> > >
> > > It seems the part before "Note" has already been fixed (before your
> > > patch), but maybe now we're taking white space into account in the
> > > case of "white space before track start" we should also do so with
> > > "white space after track end"? At the moment, neither paste or repeat
> > > seems to take it into account.
> >
> > Getting repeat to take excess whitespace into account even when there's
> > only one track selected would be very easy (easier than what it does now,
> > by far). Getting copy/paste to take whitespace at the beginning of a
> > selection into account wasn't all that hard.
> >
> > But getting general copy/paste to take into account whitespace at the end
> > of a selection would be a lot harder, because WaveTracks cannot represent
> > whitespace at the end of tracks. A track contains clips, and if the
> > first clip starts at time x, where x > 0, we consider there to be
> > whitespace between 0 and x. There is no similar standard way to know the
> > amount of whitespace that "exists" at the end of a track. I don't think
> > one would be useful, for that matter.
> >
> > Maybe when copying an area that ends in whitespace extra silence could be
> > added to the clipboard track with the length of the whitespace. It could
> > be made its own clip, even, for easy deletion... maybe even add a flag to
> > WaveClip that means something like "this clip is a placeholder for
> > whitespace, so don't paste it in, just make room for it". It's a bit of
> > a hack, but it would make things work better. I'll try to do this in the
> > new patch and see how it comes out.
>
> I'm not 100% sure of the use cases users had in mind when
> suggesting that whitespace after the end of the track should
> be taken into account. It would be a shortcut to creating a
> separated clip where you paste. There seems some user
> expectation that whitespace should be taken into account
> even at the end of the track, and it would be consistent with
> other changes you are making.
>
>
> Thanks
>
>
> Gale
>
>
>
> ---------------------------------------------------------------------------
> --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

[awd_repeat_paste_fixes_2.patch]

Index: src/WaveTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveTrack.cpp,v retrieving revision 1.169 diff -u -r1.169 WaveTrack.cpp --- src/WaveTrack.cpp 11 Oct 2009 14:55:47 -0000 1.169 +++ src/WaveTrack.cpp 13 Oct 2009 19:24:12 -0000 @@ -438,6 +438,25 @@ } } } + + // AWD, Oct 2009: If the selection ends in whitespace, create a placeholder + // clip representing that whitespace + if (newTrack->GetEndTime() + 1.0 / newTrack->GetRate() < t1 - t0) + { + WaveClip *placeholder = new WaveClip(mDirManager, + newTrack->GetSampleFormat(), newTrack->GetRate()); + placeholder->SetIsPlaceholder(true); + if ( ! placeholder->InsertSilence( + 0, (t1 - t0) - newTrack->GetEndTime()) ) + { + delete placeholder; + } + else + { + placeholder->Offset(newTrack->GetEndTime()); + newTrack->mClips.Append(placeholder); + } + } *dest = newTrack; @@ -518,7 +537,10 @@ // If duration is 0, then it's just a plain paste if (dur == 0.0) { - return Paste(t0, src, tracks, relativeLabels); + if (useHandlePaste) + return HandlePaste(t0, src); + else + return Paste(t0, src, tracks, relativeLabels); } // If provided time warper was NULL, use a default one that does nothing @@ -865,36 +887,55 @@ for( ; t; t = it.Next() ) { if (t->GetKind() == Track::Wave) { + WaveTrack *wt = (WaveTrack *)t; if (t==this) { //paste in the track - if ( !( ((WaveTrack *)t)->HandlePaste(t0, src)) ) return false; + if ( !( wt->HandlePaste(t0, src)) ) return false; if (t->GetLinked()) t=it.Next(); } else { if (! (t->GetSelected()) ) { if ( sel_len > length ) - // if selection is bigger than the content to add then we need to clear the extra length in the group tracks - ((WaveTrack*)t)->HandleClear(t0+length, t0+sel_len, false, false); + // if selection is bigger than the content to add then we + // need to clear the extra length in the group tracks + wt->HandleClear(t0+length, t0+sel_len, false, false); else if (sel_len < length) { - // if selection is smaller than the content to add then we need to add extra silence in the group tracks - TrackFactory *factory = p->GetTrackFactory(); - WaveTrack *tmp = factory->NewWaveTrack( ((WaveTrack*)t)->GetSampleFormat(), ((WaveTrack*)t)->GetRate()); - tmp->InsertSilence(0.0, length-sel_len); - tmp->Flush(); - if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + // if selection is smaller than the content to add then we + // need to add extra space in the group tracks. If the track + // is empty at this point insert whitespace; otherwise, + // silence + if (wt->IsEmpty(t0+sel_len, t0+sel_len)) + { + Track *tmp = NULL; + wt->Cut(t0 + sel_len, wt->GetEndTime()+1.0/wt->GetRate(), + &tmp, false); + wt->HandlePaste(t0 + length, tmp); + delete tmp; + } + else + { + TrackFactory *factory = p->GetTrackFactory(); + WaveTrack *tmp = factory->NewWaveTrack( wt->GetSampleFormat(), wt->GetRate()); + tmp->InsertSilence(0.0, length-sel_len); + tmp->Flush(); + if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + } } } } } else if (t->GetKind() == Track::Label) { LabelTrack *lt = (LabelTrack *)t; - if (relativeLabels && (sel_len != 0.0)) - lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); - else { - if ((length - sel_len) > 0.0) - lt->ShiftLabelsOnInsert(length-sel_len, t0); - else if ((length - sel_len) < 0.0) - lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + if (!t->GetSelected()) + { + if (relativeLabels && (sel_len != 0.0)) + lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); + else { + if ((length - sel_len) > 0.0) + lt->ShiftLabelsOnInsert(length-sel_len, t0); + else if ((length - sel_len) < 0.0) + lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + } } } } @@ -933,17 +974,21 @@ // the only behaviour which is different to what was done before, but it // shouldn't confuse users too much. // - // - If multiple clips should be pasted, these are always pasted as single - // clips, and the current clip is splitted, when necessary. This may seem - // strange at first, but it probably is better than trying to auto-merge - // anything. The user can still merge the clips by hand (which should be - // a simple command reachable by a hotkey or single mouse click). + // - If multiple clips should be pasted, or a single clip that does not fill + // the duration of the pasted track, these are always pasted as single + // clips, and the current clip is splitted, when necessary. This may seem + // strange at first, but it probably is better than trying to auto-merge + // anything. The user can still merge the clips by hand (which should be a + // simple command reachable by a hotkey or single mouse click). // if (other->GetNumClips() == 0) return false; //printf("paste: we have at least one clip\n"); + + bool singleClipMode = (other->GetNumClips() == 1 && + other->GetStartTime() == 0.0); double insertDuration = other->GetEndTime(); WaveClipList::compatibility_iterator it; @@ -952,7 +997,7 @@ // Make room for the pasted data if (editClipCanMove) { - if (other->GetNumClips() > 1) { + if (!singleClipMode) { // We need to insert multiple clips, so split the current clip and // move everything to the right, then try to paste again if (!IsEmpty(t0, GetEndTime())) { @@ -974,7 +1019,7 @@ } } - if (other->GetNumClips() == 1) + if (singleClipMode) { // Single clip mode // printf("paste: checking for single clip mode!\n"); @@ -1054,11 +1099,15 @@ { WaveClip* clip = it->GetData(); - WaveClip* newClip = new WaveClip(*clip, mDirManager); - newClip->Resample(mRate); - newClip->Offset(t0); - newClip->MarkChanged(); - mClips.Append(newClip); + // AWD Oct. 2009: Don't actually paste in placeholder clips + if (!clip->GetIsPlaceholder()) + { + WaveClip* newClip = new WaveClip(*clip, mDirManager); + newClip->Resample(mRate); + newClip->Offset(t0); + newClip->MarkChanged(); + mClips.Append(newClip); + } } return true; } Index: src/LabelTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.cpp,v retrieving revision 1.118 diff -u -r1.118 LabelTrack.cpp --- src/LabelTrack.cpp 29 Sep 2009 00:28:07 -0000 1.118 +++ src/LabelTrack.cpp 13 Oct 2009 19:24:13 -0000 @@ -278,14 +278,14 @@ { for (unsigned int i=0;i<mLabels.GetCount();i++){ // label is after the insert point - if (mLabels[i]->t > pt) { + if (mLabels[i]->t >= pt) { mLabels[i]->t = mLabels[i]->t + length; mLabels[i]->t1 = mLabels[i]->t1 + length; // label is before the insert point - }else if (mLabels[i]->t1 < pt) { + }else if (mLabels[i]->t1 <= pt) { //nothing // insert point is inside the label - }else if (mLabels[i]->t < pt && mLabels[i]->t1 > pt){ + }else{ mLabels[i]->t1 = mLabels[i]->t1 + length; } } @@ -2176,6 +2176,95 @@ return true; } +// This repeats the labels in a time interval a specified number of times. +// Like Paste(), it does not shift existing labels over +// - It assumes that you've already called ShiftLabelsOnInsert(), because +// sometimes with linking enabled that's hard to avoid. +// - It assumes that you inserted the necessary extra time at t1, not t0. +bool LabelTrack::Repeat(double t0, double t1, int n) +{ + // Sanity-check the arguments + if (n < 0 || t1 < t0) return false; + + double tLen = t1 - t0; + + for (unsigned int i = 0; i < mLabels.GetCount(); i++) + { + if (mLabels[i]->t >= t0 && mLabels[i]->t <= t1 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label is completely inside the selection; duplicate it in each + // repeat interval + unsigned int pos = i; // running label insertion position in mLabels + + for (int j = 1; j <= n; j++) + { + LabelStruct *l = new LabelStruct(); + l->t = mLabels[i]->t + j * tLen; + l->t1 = mLabels[i]->t1 + j * tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + } + else if (mLabels[i]->t >= t0 && mLabels[i]->t <= t1 && + mLabels[i]->t1 > t1 + n * tLen) + { + // Label begins inside the selection; ShiftLabelsOnInsert() has + // extended it through all the repeat blocks (that's why we don't test + // (mLabels[i]->t1 > t1); if we did that we'd catch labels created by + // the case below). We replace that with a sequence of repeated + // labels. + unsigned int pos = i; + LabelStruct *l = NULL; + + for (int j = 1; j <= n; j++) + { + l = new LabelStruct(); + l->t = mLabels[i]->t + j * tLen; + l->t1 = l->t + tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + + // Now the last one created needs to extend to where the original one + // does, and the original one needs to be cut down to the length of + // the selection + l->t1 = mLabels[i]->t1; + mLabels[i]->t1 = mLabels[i]->t + tLen; + } + else if (mLabels[i]->t < t0 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label ends inside the selection; ShiftLabelsOnInsert() hasn't touched + // it, and we need a sequence of labels as before. + unsigned int pos = i; + + for (int j = 0; j < n; j++) + { + LabelStruct *l = new LabelStruct(); + l->t = mLabels[i]->t1 + j * tLen; + l->t1 = l->t + tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + } + } + + return true; +} + bool LabelTrack::Clear(double t0, double t1) { AudacityProject *p = GetActiveProject(); Index: src/LabelTrack.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.h,v retrieving revision 1.51 diff -u -r1.51 LabelTrack.h --- src/LabelTrack.h 12 Sep 2009 06:05:41 -0000 1.51 +++ src/LabelTrack.h 13 Oct 2009 19:24:13 -0000 @@ -117,6 +117,7 @@ virtual bool Copy (double t0, double t1, Track ** dest);// const; virtual bool Clear(double t0, double t1); virtual bool Paste(double t, Track * src); + bool Repeat(double t0, double t1, int n); virtual bool Silence(double t0, double t1); virtual bool InsertSilence(double t, double len); Index: src/WaveClip.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.h,v retrieving revision 1.40 diff -u -r1.40 WaveClip.h --- src/WaveClip.h 9 Oct 2009 14:28:48 -0000 1.40 +++ src/WaveClip.h 13 Oct 2009 19:24:14 -0000 @@ -213,6 +213,10 @@ // Cache of values to colour pixels of Spectrogram - used by TrackArtist SpecPxCache *mSpecPxCache; + // AWD, Oct 2009: for pasting whitespace at the end of selection + bool GetIsPlaceholder() { return mIsPlaceholder; }; + void SetIsPlaceholder(bool val) { mIsPlaceholder = val; }; + protected: wxRect mDisplayRect; @@ -239,6 +243,9 @@ // Cut Lines are nothing more than ordinary wave clips, with the // offset relative to the start of the clip. WaveClipList mCutLines; + + // AWD, Oct. 2009: for whitespace-at-end-of-selection pasting + bool mIsPlaceholder; }; #endif Index: src/WaveClip.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.cpp,v retrieving revision 1.57 diff -u -r1.57 WaveClip.cpp --- src/WaveClip.cpp 9 Oct 2009 14:28:48 -0000 1.57 +++ src/WaveClip.cpp 13 Oct 2009 19:24:15 -0000 @@ -308,6 +308,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = false; } WaveClip::WaveClip(WaveClip& orig, DirManager *projDirManager) @@ -339,6 +340,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = orig.GetIsPlaceholder(); } WaveClip::~WaveClip() Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.527 diff -u -r1.527 Menus.cpp --- src/Menus.cpp 20 Sep 2009 19:06:04 -0000 1.527 +++ src/Menus.cpp 13 Oct 2009 19:24:18 -0000 @@ -2931,7 +2931,7 @@ void AudacityProject::OnCut() { - TrackListIterator iter(mTracks); + TrackAndGroupIterator iter(mTracks); Track *n = iter.First(); Track *dest; @@ -3003,7 +3003,11 @@ break; } } - n = iter.Next(); + // Wave and Label tracks may need group behavior + if (IsSticky() && (n->GetKind() == Track::Wave || n->GetKind() == Track::Label)) + n = iter.NextGroup(); + else + n = iter.Next(); } msClipLen = (mViewInfo.sel1 - mViewInfo.sel0); @@ -3294,6 +3298,10 @@ bool advanceClipboard = true; double srcLength = c->GetEndTime(); + // Keeps track of whether n would be the first WaveTrack in its group to + // receive data from the paste. + bool firstInGroup = true; + while (n && c) { if (n->GetSelected()) { advanceClipboard = true; @@ -3319,7 +3327,11 @@ if (!c){ c = tmpC; while (n && (c->GetKind() != n->GetKind()) ) + { n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; + } if (!n) c = NULL; } @@ -3352,7 +3364,12 @@ ((WaveTrack *) c)->Lock(); if (c->GetKind() == Track::Wave && n && n->GetKind() == Track::Wave) - pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, (WaveTrack*)c); + { + // If not the first in group we set useHandlePaste to true + pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, + (WaveTrack*)c, true, true, NULL, false, !firstInGroup); + firstInGroup = !pastedSomething; + } else pastedSomething = n->Paste(t0, c); @@ -3367,12 +3384,23 @@ if (!((WaveTrack *) n)->IsEmpty(t0, t1)) { ((WaveTrack *) n)->Clear(t0, t1); } + + // firstInGroup should always be false here, unless pasting to + // the first channel failed + if (firstInGroup) + { + pastedSomething = ((WaveTrack *)n)->Paste(t0, c); + firstInGroup = !pastedSomething; + } + else + { + pastedSomething = ((WaveTrack *)n)->HandlePaste(t0, c); + } } else { - ((WaveTrack *) n)->Clear(t0, t1); + n->Clear(t0, t1); + n->Paste(t0, c); } - - n->Paste(t0, c); } if (msClipProject != this && c->GetKind() == Track::Wave) @@ -3385,6 +3413,8 @@ } n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; } // This block handles the cases where our clipboard is smaller Index: src/effects/Repeat.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/effects/Repeat.cpp,v retrieving revision 1.34 diff -u -r1.34 Repeat.cpp --- src/effects/Repeat.cpp 8 Jul 2009 12:09:54 -0000 1.34 +++ src/effects/Repeat.cpp 13 Oct 2009 19:24:18 -0000 @@ -25,7 +25,9 @@ #include "Repeat.h" #include "../ShuttleGui.h" #include "../WaveTrack.h" +#include "../LabelTrack.h" #include "../widgets/TimeTextCtrl.h" +#include "../Project.h" #include <wx/button.h> #include <wx/defs.h> @@ -113,44 +115,55 @@ int nTrack = 0; bool bGoodResult = true; - double maxDestLen = 0.0; // used to change selection to generated bit + double maxDestLen = 0.0; // used to change selection to generated bit + + // Is linking enabled? + AudacityProject *p = GetActiveProject(); + bool isSticky = ( p && p->IsSticky()); TrackListIterator iter(mOutputTracks); - // go to first wavetrack - Track* t; - for (t = iter.First(); t->GetKind() != Track::Wave; t = iter.Next()); - if (!t) - return false; // we only do a "group change" in the first selected track of the group. // Paste call does changes to the group tracks bool first = true; - for (; t && bGoodResult; t = iter.Next()) { + for (Track *t = iter.First(); t && bGoodResult; t = iter.Next()) { if (t->GetKind() == Track::Label) + { + // We repeat labels if linking is enabled and a WaveTrack before this + // has been repeated, or if the label track is selected + if (t->GetSelected() || (isSticky && !first)) + { + LabelTrack* track = (LabelTrack*)t; + + // If this track isn't selected, ShiftLabelsOnInsert() has + // already been called + if (t->GetSelected()) + track->ShiftLabelsOnInsert((mT1 - mT0) * repeatCount, mT1); + + if (!track->Repeat(mT0, mT1, repeatCount)) + { + bGoodResult = false; + break; + } + } first = true; - else if (t->GetKind() == Track::Wave && t->GetSelected()) { + } + else if (t->GetKind() == Track::Wave && t->GetSelected()) + { WaveTrack* track = (WaveTrack*)t; - double trackStart = track->GetStartTime(); - double trackEnd = track->GetEndTime(); - double t0 = mT0 < trackStart? trackStart: mT0; - double t1 = mT1 > trackEnd? trackEnd: mT1; - - if (t1 <= t0) - continue; - - sampleCount start = track->TimeToLongSamples(t0); - sampleCount end = track->TimeToLongSamples(t1); + sampleCount start = track->TimeToLongSamples(mT0); + sampleCount end = track->TimeToLongSamples(mT1); sampleCount len = (sampleCount)(end - start); double tLen = track->LongSamplesToTime(len); - double tc = t0 + tLen; + double tc = mT0 + tLen; if (len <= 0) continue; Track *dest; - track->Copy(t0, t1, &dest); + track->Copy(mT0, mT1, &dest); for(int j=0; j<repeatCount; j++) { if (first) { @@ -182,7 +195,6 @@ if (bGoodResult) { // Select the new bits + original bit -// mT0 = mT1; mT1 = maxDestLen; }

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

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.
>

The patch in the last email had a couple extra bits in src/Menus.cpp. They
shouldn't hurt anything; they were just from a fix I made for "P2: Edit > Cut
removes too much audio when label track included in selection" that hasn't
been accepted or rejected by an official developer. A patch with those parts
taken out is attached to this message.

> I'm top-posting this because the replies are really long and I can't think
> of a coherent way to edit them down... so here's a summary of changes:
>
> - Linked label tracks behave exactly the same in repeat as selected ones.
>
> - 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.
>
> - Repeat uses the entire selection length on all repeated tracks,
> regardless of when any of them end. This should clear up some of the
> confusing repeating problems near the start and end of tracks.
>
> - No more bogus silent clips created in the middle of whitespace due to
> repeat or paste with linking turned on. This also seems to affect
> generate, which is nice.
>
> - 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.
>
> - I fixed another bug that was bothering me, because it was in the
> neighborhood: pasting into multiple tracks (which includes pasting into a
> stereo track) didn't observe proper group behavior (so it inserted too much
> silence into other grouped tracks). Now it does.
>
> I think that's all. If I forgot to address a problem let me know... there
> were lots of them, it's easy for me to lose track :).
>
> - Al
>

[awd_repeat_paste_fixes_2.patch]

Index: src/WaveTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveTrack.cpp,v retrieving revision 1.169 diff -u -r1.169 WaveTrack.cpp --- src/WaveTrack.cpp 11 Oct 2009 14:55:47 -0000 1.169 +++ src/WaveTrack.cpp 13 Oct 2009 19:24:12 -0000 @@ -438,6 +438,25 @@ } } } + + // AWD, Oct 2009: If the selection ends in whitespace, create a placeholder + // clip representing that whitespace + if (newTrack->GetEndTime() + 1.0 / newTrack->GetRate() < t1 - t0) + { + WaveClip *placeholder = new WaveClip(mDirManager, + newTrack->GetSampleFormat(), newTrack->GetRate()); + placeholder->SetIsPlaceholder(true); + if ( ! placeholder->InsertSilence( + 0, (t1 - t0) - newTrack->GetEndTime()) ) + { + delete placeholder; + } + else + { + placeholder->Offset(newTrack->GetEndTime()); + newTrack->mClips.Append(placeholder); + } + } *dest = newTrack; @@ -518,7 +537,10 @@ // If duration is 0, then it's just a plain paste if (dur == 0.0) { - return Paste(t0, src, tracks, relativeLabels); + if (useHandlePaste) + return HandlePaste(t0, src); + else + return Paste(t0, src, tracks, relativeLabels); } // If provided time warper was NULL, use a default one that does nothing @@ -865,36 +887,55 @@ for( ; t; t = it.Next() ) { if (t->GetKind() == Track::Wave) { + WaveTrack *wt = (WaveTrack *)t; if (t==this) { //paste in the track - if ( !( ((WaveTrack *)t)->HandlePaste(t0, src)) ) return false; + if ( !( wt->HandlePaste(t0, src)) ) return false; if (t->GetLinked()) t=it.Next(); } else { if (! (t->GetSelected()) ) { if ( sel_len > length ) - // if selection is bigger than the content to add then we need to clear the extra length in the group tracks - ((WaveTrack*)t)->HandleClear(t0+length, t0+sel_len, false, false); + // if selection is bigger than the content to add then we + // need to clear the extra length in the group tracks + wt->HandleClear(t0+length, t0+sel_len, false, false); else if (sel_len < length) { - // if selection is smaller than the content to add then we need to add extra silence in the group tracks - TrackFactory *factory = p->GetTrackFactory(); - WaveTrack *tmp = factory->NewWaveTrack( ((WaveTrack*)t)->GetSampleFormat(), ((WaveTrack*)t)->GetRate()); - tmp->InsertSilence(0.0, length-sel_len); - tmp->Flush(); - if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + // if selection is smaller than the content to add then we + // need to add extra space in the group tracks. If the track + // is empty at this point insert whitespace; otherwise, + // silence + if (wt->IsEmpty(t0+sel_len, t0+sel_len)) + { + Track *tmp = NULL; + wt->Cut(t0 + sel_len, wt->GetEndTime()+1.0/wt->GetRate(), + &tmp, false); + wt->HandlePaste(t0 + length, tmp); + delete tmp; + } + else + { + TrackFactory *factory = p->GetTrackFactory(); + WaveTrack *tmp = factory->NewWaveTrack( wt->GetSampleFormat(), wt->GetRate()); + tmp->InsertSilence(0.0, length-sel_len); + tmp->Flush(); + if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + } } } } } else if (t->GetKind() == Track::Label) { LabelTrack *lt = (LabelTrack *)t; - if (relativeLabels && (sel_len != 0.0)) - lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); - else { - if ((length - sel_len) > 0.0) - lt->ShiftLabelsOnInsert(length-sel_len, t0); - else if ((length - sel_len) < 0.0) - lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + if (!t->GetSelected()) + { + if (relativeLabels && (sel_len != 0.0)) + lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); + else { + if ((length - sel_len) > 0.0) + lt->ShiftLabelsOnInsert(length-sel_len, t0); + else if ((length - sel_len) < 0.0) + lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + } } } } @@ -933,17 +974,21 @@ // the only behaviour which is different to what was done before, but it // shouldn't confuse users too much. // - // - If multiple clips should be pasted, these are always pasted as single - // clips, and the current clip is splitted, when necessary. This may seem - // strange at first, but it probably is better than trying to auto-merge - // anything. The user can still merge the clips by hand (which should be - // a simple command reachable by a hotkey or single mouse click). + // - If multiple clips should be pasted, or a single clip that does not fill + // the duration of the pasted track, these are always pasted as single + // clips, and the current clip is splitted, when necessary. This may seem + // strange at first, but it probably is better than trying to auto-merge + // anything. The user can still merge the clips by hand (which should be a + // simple command reachable by a hotkey or single mouse click). // if (other->GetNumClips() == 0) return false; //printf("paste: we have at least one clip\n"); + + bool singleClipMode = (other->GetNumClips() == 1 && + other->GetStartTime() == 0.0); double insertDuration = other->GetEndTime(); WaveClipList::compatibility_iterator it; @@ -952,7 +997,7 @@ // Make room for the pasted data if (editClipCanMove) { - if (other->GetNumClips() > 1) { + if (!singleClipMode) { // We need to insert multiple clips, so split the current clip and // move everything to the right, then try to paste again if (!IsEmpty(t0, GetEndTime())) { @@ -974,7 +1019,7 @@ } } - if (other->GetNumClips() == 1) + if (singleClipMode) { // Single clip mode // printf("paste: checking for single clip mode!\n"); @@ -1054,11 +1099,15 @@ { WaveClip* clip = it->GetData(); - WaveClip* newClip = new WaveClip(*clip, mDirManager); - newClip->Resample(mRate); - newClip->Offset(t0); - newClip->MarkChanged(); - mClips.Append(newClip); + // AWD Oct. 2009: Don't actually paste in placeholder clips + if (!clip->GetIsPlaceholder()) + { + WaveClip* newClip = new WaveClip(*clip, mDirManager); + newClip->Resample(mRate); + newClip->Offset(t0); + newClip->MarkChanged(); + mClips.Append(newClip); + } } return true; } Index: src/LabelTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.cpp,v retrieving revision 1.118 diff -u -r1.118 LabelTrack.cpp --- src/LabelTrack.cpp 29 Sep 2009 00:28:07 -0000 1.118 +++ src/LabelTrack.cpp 13 Oct 2009 19:24:13 -0000 @@ -278,14 +278,14 @@ { for (unsigned int i=0;i<mLabels.GetCount();i++){ // label is after the insert point - if (mLabels[i]->t > pt) { + if (mLabels[i]->t >= pt) { mLabels[i]->t = mLabels[i]->t + length; mLabels[i]->t1 = mLabels[i]->t1 + length; // label is before the insert point - }else if (mLabels[i]->t1 < pt) { + }else if (mLabels[i]->t1 <= pt) { //nothing // insert point is inside the label - }else if (mLabels[i]->t < pt && mLabels[i]->t1 > pt){ + }else{ mLabels[i]->t1 = mLabels[i]->t1 + length; } } @@ -2176,6 +2176,95 @@ return true; } +// This repeats the labels in a time interval a specified number of times. +// Like Paste(), it does not shift existing labels over +// - It assumes that you've already called ShiftLabelsOnInsert(), because +// sometimes with linking enabled that's hard to avoid. +// - It assumes that you inserted the necessary extra time at t1, not t0. +bool LabelTrack::Repeat(double t0, double t1, int n) +{ + // Sanity-check the arguments + if (n < 0 || t1 < t0) return false; + + double tLen = t1 - t0; + + for (unsigned int i = 0; i < mLabels.GetCount(); i++) + { + if (mLabels[i]->t >= t0 && mLabels[i]->t <= t1 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label is completely inside the selection; duplicate it in each + // repeat interval + unsigned int pos = i; // running label insertion position in mLabels + + for (int j = 1; j <= n; j++) + { + LabelStruct *l = new LabelStruct(); + l->t = mLabels[i]->t + j * tLen; + l->t1 = mLabels[i]->t1 + j * tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + } + else if (mLabels[i]->t >= t0 && mLabels[i]->t <= t1 && + mLabels[i]->t1 > t1 + n * tLen) + { + // Label begins inside the selection; ShiftLabelsOnInsert() has + // extended it through all the repeat blocks (that's why we don't test + // (mLabels[i]->t1 > t1); if we did that we'd catch labels created by + // the case below). We replace that with a sequence of repeated + // labels. + unsigned int pos = i; + LabelStruct *l = NULL; + + for (int j = 1; j <= n; j++) + { + l = new LabelStruct(); + l->t = mLabels[i]->t + j * tLen; + l->t1 = l->t + tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + + // Now the last one created needs to extend to where the original one + // does, and the original one needs to be cut down to the length of + // the selection + l->t1 = mLabels[i]->t1; + mLabels[i]->t1 = mLabels[i]->t + tLen; + } + else if (mLabels[i]->t < t0 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label ends inside the selection; ShiftLabelsOnInsert() hasn't touched + // it, and we need a sequence of labels as before. + unsigned int pos = i; + + for (int j = 0; j < n; j++) + { + LabelStruct *l = new LabelStruct(); + l->t = mLabels[i]->t1 + j * tLen; + l->t1 = l->t + tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + } + } + + return true; +} + bool LabelTrack::Clear(double t0, double t1) { AudacityProject *p = GetActiveProject(); Index: src/LabelTrack.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.h,v retrieving revision 1.51 diff -u -r1.51 LabelTrack.h --- src/LabelTrack.h 12 Sep 2009 06:05:41 -0000 1.51 +++ src/LabelTrack.h 13 Oct 2009 19:24:13 -0000 @@ -117,6 +117,7 @@ virtual bool Copy (double t0, double t1, Track ** dest);// const; virtual bool Clear(double t0, double t1); virtual bool Paste(double t, Track * src); + bool Repeat(double t0, double t1, int n); virtual bool Silence(double t0, double t1); virtual bool InsertSilence(double t, double len); Index: src/WaveClip.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.h,v retrieving revision 1.40 diff -u -r1.40 WaveClip.h --- src/WaveClip.h 9 Oct 2009 14:28:48 -0000 1.40 +++ src/WaveClip.h 13 Oct 2009 19:24:14 -0000 @@ -213,6 +213,10 @@ // Cache of values to colour pixels of Spectrogram - used by TrackArtist SpecPxCache *mSpecPxCache; + // AWD, Oct 2009: for pasting whitespace at the end of selection + bool GetIsPlaceholder() { return mIsPlaceholder; }; + void SetIsPlaceholder(bool val) { mIsPlaceholder = val; }; + protected: wxRect mDisplayRect; @@ -239,6 +243,9 @@ // Cut Lines are nothing more than ordinary wave clips, with the // offset relative to the start of the clip. WaveClipList mCutLines; + + // AWD, Oct. 2009: for whitespace-at-end-of-selection pasting + bool mIsPlaceholder; }; #endif Index: src/WaveClip.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.cpp,v retrieving revision 1.57 diff -u -r1.57 WaveClip.cpp --- src/WaveClip.cpp 9 Oct 2009 14:28:48 -0000 1.57 +++ src/WaveClip.cpp 13 Oct 2009 19:24:15 -0000 @@ -308,6 +308,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = false; } WaveClip::WaveClip(WaveClip& orig, DirManager *projDirManager) @@ -339,6 +340,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = orig.GetIsPlaceholder(); } WaveClip::~WaveClip() Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.527 diff -u -r1.527 Menus.cpp --- src/Menus.cpp 20 Sep 2009 19:06:04 -0000 1.527 +++ src/Menus.cpp 13 Oct 2009 19:24:18 -0000 @@ -3294,6 +3298,10 @@ bool advanceClipboard = true; double srcLength = c->GetEndTime(); + // Keeps track of whether n would be the first WaveTrack in its group to + // receive data from the paste. + bool firstInGroup = true; + while (n && c) { if (n->GetSelected()) { advanceClipboard = true; @@ -3319,7 +3327,11 @@ if (!c){ c = tmpC; while (n && (c->GetKind() != n->GetKind()) ) + { n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; + } if (!n) c = NULL; } @@ -3352,7 +3364,12 @@ ((WaveTrack *) c)->Lock(); if (c->GetKind() == Track::Wave && n && n->GetKind() == Track::Wave) - pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, (WaveTrack*)c); + { + // If not the first in group we set useHandlePaste to true + pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, + (WaveTrack*)c, true, true, NULL, false, !firstInGroup); + firstInGroup = !pastedSomething; + } else pastedSomething = n->Paste(t0, c); @@ -3367,12 +3384,23 @@ if (!((WaveTrack *) n)->IsEmpty(t0, t1)) { ((WaveTrack *) n)->Clear(t0, t1); } + + // firstInGroup should always be false here, unless pasting to + // the first channel failed + if (firstInGroup) + { + pastedSomething = ((WaveTrack *)n)->Paste(t0, c); + firstInGroup = !pastedSomething; + } + else + { + pastedSomething = ((WaveTrack *)n)->HandlePaste(t0, c); + } } else { - ((WaveTrack *) n)->Clear(t0, t1); + n->Clear(t0, t1); + n->Paste(t0, c); } - - n->Paste(t0, c); } if (msClipProject != this && c->GetKind() == Track::Wave) @@ -3385,6 +3413,8 @@ } n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; } // This block handles the cases where our clipboard is smaller Index: src/effects/Repeat.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/effects/Repeat.cpp,v retrieving revision 1.34 diff -u -r1.34 Repeat.cpp --- src/effects/Repeat.cpp 8 Jul 2009 12:09:54 -0000 1.34 +++ src/effects/Repeat.cpp 13 Oct 2009 19:24:18 -0000 @@ -25,7 +25,9 @@ #include "Repeat.h" #include "../ShuttleGui.h" #include "../WaveTrack.h" +#include "../LabelTrack.h" #include "../widgets/TimeTextCtrl.h" +#include "../Project.h" #include <wx/button.h> #include <wx/defs.h> @@ -113,44 +115,55 @@ int nTrack = 0; bool bGoodResult = true; - double maxDestLen = 0.0; // used to change selection to generated bit + double maxDestLen = 0.0; // used to change selection to generated bit + + // Is linking enabled? + AudacityProject *p = GetActiveProject(); + bool isSticky = ( p && p->IsSticky()); TrackListIterator iter(mOutputTracks); - // go to first wavetrack - Track* t; - for (t = iter.First(); t->GetKind() != Track::Wave; t = iter.Next()); - if (!t) - return false; // we only do a "group change" in the first selected track of the group. // Paste call does changes to the group tracks bool first = true; - for (; t && bGoodResult; t = iter.Next()) { + for (Track *t = iter.First(); t && bGoodResult; t = iter.Next()) { if (t->GetKind() == Track::Label) + { + // We repeat labels if linking is enabled and a WaveTrack before this + // has been repeated, or if the label track is selected + if (t->GetSelected() || (isSticky && !first)) + { + LabelTrack* track = (LabelTrack*)t; + + // If this track isn't selected, ShiftLabelsOnInsert() has + // already been called + if (t->GetSelected()) + track->ShiftLabelsOnInsert((mT1 - mT0) * repeatCount, mT1); + + if (!track->Repeat(mT0, mT1, repeatCount)) + { + bGoodResult = false; + break; + } + } first = true; - else if (t->GetKind() == Track::Wave && t->GetSelected()) { + } + else if (t->GetKind() == Track::Wave && t->GetSelected()) + { WaveTrack* track = (WaveTrack*)t; - double trackStart = track->GetStartTime(); - double trackEnd = track->GetEndTime(); - double t0 = mT0 < trackStart? trackStart: mT0; - double t1 = mT1 > trackEnd? trackEnd: mT1; - - if (t1 <= t0) - continue; - - sampleCount start = track->TimeToLongSamples(t0); - sampleCount end = track->TimeToLongSamples(t1); + sampleCount start = track->TimeToLongSamples(mT0); + sampleCount end = track->TimeToLongSamples(mT1); sampleCount len = (sampleCount)(end - start); double tLen = track->LongSamplesToTime(len); - double tc = t0 + tLen; + double tc = mT0 + tLen; if (len <= 0) continue; Track *dest; - track->Copy(t0, t1, &dest); + track->Copy(mT0, mT1, &dest); for(int j=0; j<repeatCount; j++) { if (first) { @@ -182,7 +195,6 @@ if (bGoodResult) { // Select the new bits + original bit -// mT0 = mT1; mT1 = maxDestLen; }

Gale (Audacity Team)

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

| From Al Dimond <[hidden email]>
| Tue, 13 Oct 2009 19:27:21 -0600
| Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!

> 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.
> >
>
> The patch in the last email had a couple extra bits in src/Menus.cpp. They
> shouldn't hurt anything; they were just from a fix I made for "P2: Edit > Cut
> removes too much audio when label track included in selection" that hasn't
> been accepted or rejected by an official developer. A patch with those parts
> taken out is attached to this message.

Hi Al,

I'd just applied the original patch and built when the above message
arrived. So as I had not tried your patch for the P2 above yet, I won't
bother to repatch minus the P2 fix, but will see how the P3 and P2
fixes are side by side.

I presume the actual code for the P2 fix was uncontroversial, given
no one commented, and that it's safe and worthwhile to commit it
even if we turn linking off for 2.0 (on the grounds we have time
before 2.0 to spot any side effects from it and/or revert it).

I haven't tested the results of the combined P2/3 patch yet. That'll
have to wait until about 18 hours or so.

Thanks

Gale

> > I'm top-posting this because the replies are really long and I can't think
> > of a coherent way to edit them down... so here's a summary of changes:
> >
> > - Linked label tracks behave exactly the same in repeat as selected ones.
> >
> > - 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.
> >
> > - Repeat uses the entire selection length on all repeated tracks,
> > regardless of when any of them end. This should clear up some of the
> > confusing repeating problems near the start and end of tracks.
> >
> > - No more bogus silent clips created in the middle of whitespace due to
> > repeat or paste with linking turned on. This also seems to affect
> > generate, which is nice.
> >
> > - 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.
> >
> > - I fixed another bug that was bothering me, because it was in the
> > neighborhood: pasting into multiple tracks (which includes pasting into a
> > stereo track) didn't observe proper group behavior (so it inserted too much
> > silence into other grouped tracks). Now it does.
> >
> > I think that's all. If I forgot to address a problem let me know... there
> > were lots of them, it's easy for me to lose track :).
> >
> > - Al
> >

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

On Wednesday 14 October 2009 03:04:59 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Tue, 13 Oct 2009 19:27:21 -0600
> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> |
> > 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.
> >
> > The patch in the last email had a couple extra bits in src/Menus.cpp.
> > They shouldn't hurt anything; they were just from a fix I made for "P2:
> > Edit > Cut removes too much audio when label track included in selection"
> > that hasn't been accepted or rejected by an official developer. A patch
> > with those parts taken out is attached to this message.
>
> Hi Al,
>
> I'd just applied the original patch and built when the above message
> arrived. So as I had not tried your patch for the P2 above yet, I won't
> bother to repatch minus the P2 fix, but will see how the P3 and P2
> fixes are side by side.
>
> I presume the actual code for the P2 fix was uncontroversial, given
> no one commented, and that it's safe and worthwhile to commit it
> even if we turn linking off for 2.0 (on the grounds we have time
> before 2.0 to spot any side effects from it and/or revert it).
>

I think the P2 fix was pretty uncontroversial... it only affected one function
and in a way very similar to how other group behavior is handled. As far as
side effects go, since the changes are in AudacityProject::OnCut() they
shouldn't affect much else. I was somewhat surprised that nobody really looked
at it or applied it, but I imagine you guys are pretty busy.

This patch, on the other hand, is a bit of a beast, and definitely has side-
effects (in the sense that it affects more that repeating); although all the
ones I've found so far have been positive that's not much to hang your hat on.

> I haven't tested the results of the combined P2/3 patch yet. That'll
> have to wait until about 18 hours or so.
>

OK. Thanks for having a look at this stuff.

- Al

> Thanks
>
>
> Gale
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

In reply to this post by Al Dimond

Hi Al

You are definitely nearly there on this one, and sorry I've been slack
with testing, I've been very busy. I may not have read every post in
this thread in detail.

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

> The patch in the last email had a couple extra bits in src/Menus.cpp. They
> shouldn't hurt anything; they were just from a fix I made for "P2: Edit > Cut
> removes too much audio when label track included in selection" that hasn't
> been accepted or rejected by an official developer. A patch with those parts
> taken out is attached to this message.
>
>> I'm top-posting this because the replies are really long and I can't think
>> of a coherent way to edit them down... so here's a summary of changes:
>>
>> - Linked label tracks behave exactly the same in repeat as selected ones.

I'm not sure what you mean here - it does not matter if they are
selected or not? That appears to be what happens. I'm not sure
that's good, but if it's been discussed and decided, well OK. I'd
have made them do things if selected and not if not (more control).
More on that below.

>> - 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).

>> - Repeat uses the entire selection length on all repeated tracks,
>> regardless of when any of them end. This should clear up some of the
>> confusing repeating problems near the start and end of tracks.

Looks good to me (apart from the labels), before
http://dl.getdropbox.com/u/1327769/trackpanel004.png
after:
http://dl.getdropbox.com/u/1327769/trackpanel005.png
(I had selected a bit after the clips finished).

>> - No more bogus silent clips created in the middle of whitespace due to
>> repeat

Much nicer :-)

or paste with linking turned on. This also seems to affect
>> generate, which is nice.

I didn't test these cases.

>> - 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 fixed another bug that was bothering me, because it was in the
>> neighborhood: pasting into multiple tracks (which includes pasting into a
>> stereo track) didn't observe proper group behavior (so it inserted too much
>> silence into other grouped tracks). Now it does.

Again, I didn't test the bug or solution.

Thanks for all you recent work on bugs Al, I will commit the patch as
it is now if you do no more on it, since it looks like it's 'better
than before'. I'd rather see these little faults ironed out though.

TTFN
Martyn

>> I think that's all. If I forgot to address a problem let me know... there
>> were lots of them, it's easy for me to lose track :).
>>
>> - Al
>>
>>
>> ------------------------------------------------------------------------
>>
>> ------------------------------------------------------------------------------
>> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
>> is the only developer event you need to attend this year. Jumpstart your
>> developing skills, take BlackBerry mobile applications to market and stay
>> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
>> http://p.sf.net/sfu/devconference
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> audacity-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

On Wednesday 14 October 2009 18:09:36 Martyn Shaw wrote:
> Hi Al
>
> You are definitely nearly there on this one, and sorry I've been slack
> with testing, I've been very busy. I may not have read every post in
> this thread in detail.
>

I understand completely...

> 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".

> > The patch in the last email had a couple extra bits in src/Menus.cpp.
> > They shouldn't hurt anything; they were just from a fix I made for "P2:
> > Edit > Cut removes too much audio when label track included in selection"
> > that hasn't been accepted or rejected by an official developer. A patch
> > with those parts taken out is attached to this message.
> >
> >> I'm top-posting this because the replies are really long and I can't
> >> think of a coherent way to edit them down... so here's a summary of
> >> changes:
> >>
> >> - Linked label tracks behave exactly the same in repeat as selected
> >> ones.
>
> I'm not sure what you mean here - it does not matter if they are
> selected or not? That appears to be what happens. I'm not sure
> that's good, but if it's been discussed and decided, well OK. I'd
> have made them do things if selected and not if not (more control).
> More on that below.
>

It means that if linking is turned on it doesn't matter if they are selected
or not. That was something Gale and I discussed. My first patch worked
probably the way you envision it working: with linking enabled, labels always
are moved/extended so they point to the same audio as before (except that it
didn't work right when selection overlapped the end of a label), but if
they're selected they can repeat; this is similar to the way wave tracks
behave. Gale thought this weakened the meaning of linking, so I changed it in
the second patch.

On one hand, I like the idea of giving the user more control. On the other,
the only reason I would know how to exercise my power is because I just wrote
the code. On that note, if there's a place I should update documentation when
these changes make it into a release, let me know.

> >> - 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) if the label track was linked but not selected.

> >> - Repeat uses the entire selection length on all repeated tracks,
> >> regardless of when any of them end. This should clear up some of the
> >> confusing repeating problems near the start and end of tracks.
>
> Looks good to me (apart from the labels), before
> http://dl.getdropbox.com/u/1327769/trackpanel004.png
> after:
> http://dl.getdropbox.com/u/1327769/trackpanel005.png
> (I had selected a bit after the clips finished).
>
> >> - No more bogus silent clips created in the middle of whitespace due to
> >> repeat
>
> Much nicer :-)
>
> or paste with linking turned on. This also seems to affect
>
> >> generate, which is nice.
>
> I didn't test these cases.
>
> >> - 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 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.

> >> - I fixed another bug that was bothering me, because it was in the
> >> neighborhood: pasting into multiple tracks (which includes pasting into
> >> a stereo track) didn't observe proper group behavior (so it inserted too
> >> much silence into other grouped tracks). Now it does.
>
> Again, I didn't test the bug or solution.
>
> Thanks for all you recent work on bugs Al, I will commit the patch as
> it is now if you do no more on it, since it looks like it's 'better
> than before'. I'd rather see these little faults ironed out though.
>
> TTFN
> Martyn
>
> >> I think that's all. If I forgot to address a problem let me know...
> >> there were lots of them, it's easy for me to lose track :).
> >>
> >> - Al
> >>
> >>
> >> ------------------------------------------------------------------------
> >>
> >> ------------------------------------------------------------------------
> >>------ Come build with us! The BlackBerry(R) Developer Conference in SF,
> >> CA is the only developer event you need to attend this year. Jumpstart
> >> your developing skills, take BlackBerry mobile applications to market
> >> and stay ahead of the curve. Join us from November 9 - 12, 2009.
> >> Register now! http://p.sf.net/sfu/devconference
> >>
> >> ------------------------------------------------------------------------
> >>
> >> _______________________________________________
> >> audacity-devel mailing list
> >> [hidden email]
> >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>
> ---------------------------------------------------------------------------
> --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Gale (Audacity Team)

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

| From Al Dimond <[hidden email]>
| Wed, 14 Oct 2009 23:50:07 -0600
| Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!

> On Wednesday 14 October 2009 18:09:36 Martyn Shaw wrote:
> > >> - Linked label tracks behave exactly the same in repeat as selected
> > >> ones.
> >
> > I'm not sure what you mean here - it does not matter if they are
> > selected or not? That appears to be what happens. I'm not sure
> > that's good, but if it's been discussed and decided, well OK. I'd
> > have made them do things if selected and not if not (more control).
> > More on that below.
> >
>
> It means that if linking is turned on it doesn't matter if they are selected
> or not. That was something Gale and I discussed. My first patch worked
> probably the way you envision it working: with linking enabled, labels always
> are moved/extended so they point to the same audio as before (except that it
> didn't work right when selection overlapped the end of a label), but if
> they're selected they can repeat; this is similar to the way wave tracks
> behave. Gale thought this weakened the meaning of linking, so I changed it in
> the second patch.
>
> On one hand, I like the idea of giving the user more control. On the other,
> the only reason I would know how to exercise my power is because I just wrote
> the code.

My sole problem with making labels only repeat if the label
track is included in the selection is essentially that the user
might no longer have a clear idea what the "rules of linking"
are.

Where the effect is one that can be applied to a label, the
distinction between linking or not is lost if you still have to
select the label to "apply the effect to it" (which shouldn't be
necessary with other time-changing effects if they work
correctly).

If the aim is thought of to "keep audio and labels synchronised"
(not the same thing as "apply the effect" where repeat is
concerned) then we are not breaking any rules to force the
user to select the track to repeat the labels.

I still haven't had a chance to look fully at how the patch
behaves and all Martyn's comments yet, but as I said before
I think this is a difficult decision, and I could easily be
persuaded Repeat is worth making an exception (if it is one).

For example, there is no easy way to make four labels into
one is there, if what you really wanted was:
http://dl.getdropbox.com/u/1327769/trackpanel003.png

But if the user wanted four labels, is it intuitive that they have
select the label track to get it?

> On that note, if there's a place I should update documentation
> when these changes make it into a release, let me know.

These would be the places:
http://manual.audacityteam.org/index.php?title=Label_Tracks#Linking_labels_with_audio_tracks
http://manual.audacityteam.org/index.php?title=Effect_Menu

Gale

> > >> - 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) if the label track was linked but not selected.
>
>
> > >> - Repeat uses the entire selection length on all repeated tracks,
> > >> regardless of when any of them end. This should clear up some of the
> > >> confusing repeating problems near the start and end of tracks.
> >
> > Looks good to me (apart from the labels), before
> > http://dl.getdropbox.com/u/1327769/trackpanel004.png
> > after:
> > http://dl.getdropbox.com/u/1327769/trackpanel005.png
> > (I had selected a bit after the clips finished).
> >
> > >> - No more bogus silent clips created in the middle of whitespace due to
> > >> repeat
> >
> > Much nicer :-)
> >
> > or paste with linking turned on. This also seems to affect
> >
> > >> generate, which is nice.
> >
> > I didn't test these cases.
> >
> > >> - 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 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.
>
>
> > >> - I fixed another bug that was bothering me, because it was in the
> > >> neighborhood: pasting into multiple tracks (which includes pasting into
> > >> a stereo track) didn't observe proper group behavior (so it inserted too
> > >> much silence into other grouped tracks). Now it does.
> >
> > Again, I didn't test the bug or solution.
> >
> > Thanks for all you recent work on bugs Al, I will commit the patch as
> > it is now if you do no more on it, since it looks like it's 'better
> > than before'. I'd rather see these little faults ironed out though.
> >
> > TTFN
> > Martyn
> >
> > >> I think that's all. If I forgot to address a problem let me know...
> > >> there were lots of them, it's easy for me to lose track :).
> > >>
> > >> - Al
> > >>
> > >>
> > >> ------------------------------------------------------------------------
> > >>
> > >> ------------------------------------------------------------------------
> > >>------ Come build with us! The BlackBerry(R) Developer Conference in SF,
> > >> CA is the only developer event you need to attend this year. Jumpstart
> > >> your developing skills, take BlackBerry mobile applications to market
> > >> and stay ahead of the curve. Join us from November 9 - 12, 2009.
> > >> Register now! http://p.sf.net/sfu/devconference
> > >>
> > >> ------------------------------------------------------------------------
> > >>
> > >> _______________________________________________
> > >> audacity-devel mailing list
> > >> [hidden email]
> > >> https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
> > ---------------------------------------------------------------------------
> > --- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is
> > the only developer event you need to attend this year. Jumpstart your
> > developing skills, take BlackBerry mobile applications to market and stay
> > ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> > http://p.sf.net/sfu/devconference
> > _______________________________________________
> > audacity-devel mailing list
> > [hidden email]
> > https://lists.sourceforge.net/lists/listinfo/audacity-devel
> >
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

On Thursday 15 October 2009 04:17:27 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Wed, 14 Oct 2009 23:50:07 -0600
> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> |
> > On Wednesday 14 October 2009 18:09:36 Martyn Shaw wrote:
> > > >> - Linked label tracks behave exactly the same in repeat as selected
> > > >> ones.
> > >
> > > I'm not sure what you mean here - it does not matter if they are
> > > selected or not? That appears to be what happens. I'm not sure
> > > that's good, but if it's been discussed and decided, well OK. I'd
> > > have made them do things if selected and not if not (more control).
> > > More on that below.
> >
> > It means that if linking is turned on it doesn't matter if they are
> > selected or not. That was something Gale and I discussed. My first
> > patch worked probably the way you envision it working: with linking
> > enabled, labels always are moved/extended so they point to the same audio
> > as before (except that it didn't work right when selection overlapped the
> > end of a label), but if they're selected they can repeat; this is similar
> > to the way wave tracks behave. Gale thought this weakened the meaning of
> > linking, so I changed it in the second patch.
> >
> > On one hand, I like the idea of giving the user more control. On the
> > other, the only reason I would know how to exercise my power is because I
> > just wrote the code.
>
> My sole problem with making labels only repeat if the label
> track is included in the selection is essentially that the user
> might no longer have a clear idea what the "rules of linking"
> are.
>
> Where the effect is one that can be applied to a label, the
> distinction between linking or not is lost if you still have to
> select the label to "apply the effect to it" (which shouldn't be
> necessary with other time-changing effects if they work
> correctly).
>
> If the aim is thought of to "keep audio and labels synchronised"
> (not the same thing as "apply the effect" where repeat is
> concerned) then we are not breaking any rules to force the
> user to select the track to repeat the labels.
>
> I still haven't had a chance to look fully at how the patch
> behaves and all Martyn's comments yet, but as I said before
> I think this is a difficult decision, and I could easily be
> persuaded Repeat is worth making an exception (if it is one).
>
> For example, there is no easy way to make four labels into
> one is there, if what you really wanted was:
> http://dl.getdropbox.com/u/1327769/trackpanel003.png
>
> But if the user wanted four labels, is it intuitive that they have
> select the label track to get it?
>

Of all the ways a user might make that happen, selecting the label track is
about the most intuitive I can think of, because of the analog with wave track
behavior. Unfortunately following that logic would also give us crummy
default behavior: not repeating labels that are completely overlapped by the
selection. I think users will just about always want completely-overlapped
labels to be repeated.

Will users ever actually want new labels created when one end is overlapped?
It might be helpful for longer repeat blocks, where the end of the label
corresponds to a specific point that's not obvious from looking at the
waveform. I think a lot will want the label just to be extended. That said,
I don't think having 4 label there is a big nuisance. If we had a way to
merge contiguous or overlapping labels it would be easy to make it one label
again (not that it's particularly hard to do now).

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

In reply to this post by Al Dimond

Hi Al

Please see my following post as well, covering whether Label tracks
should be automatically selected...

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.

...

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?

...

>>>> - 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!

> 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?

TTFN
Martyn

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Martyn Shaw-2

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

In reply to this post by Al Dimond

Hello there

I am not entirely decided on what the logic should be here, but
reasonably sure...

Al Dimond wrote:

> On Thursday 15 October 2009 04:17:27 Gale Andrews wrote:
>> | From Al Dimond <[hidden email]>
>> | Wed, 14 Oct 2009 23:50:07 -0600
>> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
>> |
>>> On Wednesday 14 October 2009 18:09:36 Martyn Shaw wrote:
>>>>>> - Linked label tracks behave exactly the same in repeat as selected
>>>>>> ones.
>>>> I'm not sure what you mean here - it does not matter if they are
>>>> selected or not? That appears to be what happens. I'm not sure
>>>> that's good, but if it's been discussed and decided, well OK. I'd
>>>> have made them do things if selected and not if not (more control).
>>>> More on that below.
>>> It means that if linking is turned on it doesn't matter if they are
>>> selected or not. That was something Gale and I discussed. My first
>>> patch worked probably the way you envision it working: with linking
>>> enabled, labels always are moved/extended so they point to the same audio
>>> as before (except that it didn't work right when selection overlapped the
>>> end of a label), but if they're selected they can repeat; this is similar
>>> to the way wave tracks behave. Gale thought this weakened the meaning of
>>> linking, so I changed it in the second patch.
>>>
>>> On one hand, I like the idea of giving the user more control. On the
>>> other, the only reason I would know how to exercise my power is because I
>>> just wrote the code.

And I note that you changed your mind on that below :-) (which is
fine) "selecting the label track is about the most intuitive I can
think of"

>> My sole problem with making labels only repeat if the label
>> track is included in the selection is essentially that the user
>> might no longer have a clear idea what the "rules of linking"
>> are.

Where do they get the "rules of linking" from? Experience? The wiki?
Probably from experience (people don't read instructions, in
general, they just 'muck around a bit', from what I've seen).

>> Where the effect is one that can be applied to a label,

How many of them (effects) are there? I can't think of more than
'Repeat'. I don't think any can be applied to just a label.
Obviously ones that change the length of audio should affect the
labels (so they label the same events).

the
>> distinction between linking or not is lost if you still have to
>> select the label to "apply the effect to it" (which shouldn't be
>> necessary with other time-changing effects if they work
>> correctly).

Agreed

>> If the aim is thought of to "keep audio and labels synchronised"
>> (not the same thing as "apply the effect" where repeat is
>> concerned) then we are not breaking any rules to force the
>> user to select the track to repeat the labels.

Agreed

>> I still haven't had a chance to look fully at how the patch
>> behaves and all Martyn's comments yet, but as I said before
>> I think this is a difficult decision, and I could easily be
>> persuaded Repeat is worth making an exception (if it is one).

It isn't, but be persuaded and let's put this one to bed (for now).

TTFN
Martyn

>> For example, there is no easy way to make four labels into
>> one is there, if what you really wanted was:
>> http://dl.getdropbox.com/u/1327769/trackpanel003.png
>>
>> But if the user wanted four labels, is it intuitive that they have
>> select the label track to get it?
>>
>
> Of all the ways a user might make that happen, selecting the label track is
> about the most intuitive I can think of, because of the analog with wave track
> behavior. Unfortunately following that logic would also give us crummy
> default behavior: not repeating labels that are completely overlapped by the
> selection. I think users will just about always want completely-overlapped
> labels to be repeated.
>
> Will users ever actually want new labels created when one end is overlapped?
> It might be helpful for longer repeat blocks, where the end of the label
> corresponds to a specific point that's not obvious from looking at the
> waveform. I think a lot will want the label just to be extended. That said,
> I don't think having 4 label there is a big nuisance. If we had a way to
> merge contiguous or overlapping labels it would be easy to make it one label
> again (not that it's particularly hard to do now).
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> _______________________________________________
> audacity-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/audacity-devel
>

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

In reply to this post by Martyn Shaw-2

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

[awd_cut_fix.patch]

Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.527 diff -u -r1.527 Menus.cpp --- src/Menus.cpp 20 Sep 2009 19:06:04 -0000 1.527 +++ src/Menus.cpp 16 Oct 2009 03:45:12 -0000 @@ -2931,7 +2931,7 @@ void AudacityProject::OnCut() { - TrackListIterator iter(mTracks); + TrackAndGroupIterator iter(mTracks); Track *n = iter.First(); Track *dest; @@ -3003,7 +3003,11 @@ break; } } - n = iter.Next(); + // Wave and Label tracks may need group behavior + if (IsSticky() && (n->GetKind() == Track::Wave || n->GetKind() == Track::Label)) + n = iter.NextGroup(); + else + n = iter.Next(); } msClipLen = (mViewInfo.sel1 - mViewInfo.sel0);

[awd_repeat_paste_fixes_3.patch]

Index: src/WaveTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveTrack.cpp,v retrieving revision 1.169 diff -u -r1.169 WaveTrack.cpp --- src/WaveTrack.cpp 11 Oct 2009 14:55:47 -0000 1.169 +++ src/WaveTrack.cpp 16 Oct 2009 03:40:43 -0000 @@ -438,6 +438,25 @@ } } } + + // AWD, Oct 2009: If the selection ends in whitespace, create a placeholder + // clip representing that whitespace + if (newTrack->GetEndTime() + 1.0 / newTrack->GetRate() < t1 - t0) + { + WaveClip *placeholder = new WaveClip(mDirManager, + newTrack->GetSampleFormat(), newTrack->GetRate()); + placeholder->SetIsPlaceholder(true); + if ( ! placeholder->InsertSilence( + 0, (t1 - t0) - newTrack->GetEndTime()) ) + { + delete placeholder; + } + else + { + placeholder->Offset(newTrack->GetEndTime()); + newTrack->mClips.Append(placeholder); + } + } *dest = newTrack; @@ -518,7 +537,10 @@ // If duration is 0, then it's just a plain paste if (dur == 0.0) { - return Paste(t0, src, tracks, relativeLabels); + if (useHandlePaste) + return HandlePaste(t0, src); + else + return Paste(t0, src, tracks, relativeLabels); } // If provided time warper was NULL, use a default one that does nothing @@ -865,36 +887,55 @@ for( ; t; t = it.Next() ) { if (t->GetKind() == Track::Wave) { + WaveTrack *wt = (WaveTrack *)t; if (t==this) { //paste in the track - if ( !( ((WaveTrack *)t)->HandlePaste(t0, src)) ) return false; + if ( !( wt->HandlePaste(t0, src)) ) return false; if (t->GetLinked()) t=it.Next(); } else { if (! (t->GetSelected()) ) { if ( sel_len > length ) - // if selection is bigger than the content to add then we need to clear the extra length in the group tracks - ((WaveTrack*)t)->HandleClear(t0+length, t0+sel_len, false, false); + // if selection is bigger than the content to add then we + // need to clear the extra length in the group tracks + wt->HandleClear(t0+length, t0+sel_len, false, false); else if (sel_len < length) { - // if selection is smaller than the content to add then we need to add extra silence in the group tracks - TrackFactory *factory = p->GetTrackFactory(); - WaveTrack *tmp = factory->NewWaveTrack( ((WaveTrack*)t)->GetSampleFormat(), ((WaveTrack*)t)->GetRate()); - tmp->InsertSilence(0.0, length-sel_len); - tmp->Flush(); - if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + // if selection is smaller than the content to add then we + // need to add extra space in the group tracks. If the track + // is empty at this point insert whitespace; otherwise, + // silence + if (wt->IsEmpty(t0+sel_len, t0+sel_len)) + { + Track *tmp = NULL; + wt->Cut(t0 + sel_len, wt->GetEndTime()+1.0/wt->GetRate(), + &tmp, false); + wt->HandlePaste(t0 + length, tmp); + delete tmp; + } + else + { + TrackFactory *factory = p->GetTrackFactory(); + WaveTrack *tmp = factory->NewWaveTrack( wt->GetSampleFormat(), wt->GetRate()); + tmp->InsertSilence(0.0, length-sel_len); + tmp->Flush(); + if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + } } } } } else if (t->GetKind() == Track::Label) { LabelTrack *lt = (LabelTrack *)t; - if (relativeLabels && (sel_len != 0.0)) - lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); - else { - if ((length - sel_len) > 0.0) - lt->ShiftLabelsOnInsert(length-sel_len, t0); - else if ((length - sel_len) < 0.0) - lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + if (!t->GetSelected()) + { + if (relativeLabels && (sel_len != 0.0)) + lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); + else { + if ((length - sel_len) > 0.0) + lt->ShiftLabelsOnInsert(length-sel_len, t0); + else if ((length - sel_len) < 0.0) + lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + } } } } @@ -933,17 +974,21 @@ // the only behaviour which is different to what was done before, but it // shouldn't confuse users too much. // - // - If multiple clips should be pasted, these are always pasted as single - // clips, and the current clip is splitted, when necessary. This may seem - // strange at first, but it probably is better than trying to auto-merge - // anything. The user can still merge the clips by hand (which should be - // a simple command reachable by a hotkey or single mouse click). + // - If multiple clips should be pasted, or a single clip that does not fill + // the duration of the pasted track, these are always pasted as single + // clips, and the current clip is splitted, when necessary. This may seem + // strange at first, but it probably is better than trying to auto-merge + // anything. The user can still merge the clips by hand (which should be a + // simple command reachable by a hotkey or single mouse click). // if (other->GetNumClips() == 0) return false; //printf("paste: we have at least one clip\n"); + + bool singleClipMode = (other->GetNumClips() == 1 && + other->GetStartTime() == 0.0); double insertDuration = other->GetEndTime(); WaveClipList::compatibility_iterator it; @@ -952,7 +997,7 @@ // Make room for the pasted data if (editClipCanMove) { - if (other->GetNumClips() > 1) { + if (!singleClipMode) { // We need to insert multiple clips, so split the current clip and // move everything to the right, then try to paste again if (!IsEmpty(t0, GetEndTime())) { @@ -974,7 +1019,7 @@ } } - if (other->GetNumClips() == 1) + if (singleClipMode) { // Single clip mode // printf("paste: checking for single clip mode!\n"); @@ -1054,11 +1099,15 @@ { WaveClip* clip = it->GetData(); - WaveClip* newClip = new WaveClip(*clip, mDirManager); - newClip->Resample(mRate); - newClip->Offset(t0); - newClip->MarkChanged(); - mClips.Append(newClip); + // AWD Oct. 2009: Don't actually paste in placeholder clips + if (!clip->GetIsPlaceholder()) + { + WaveClip* newClip = new WaveClip(*clip, mDirManager); + newClip->Resample(mRate); + newClip->Offset(t0); + newClip->MarkChanged(); + mClips.Append(newClip); + } } return true; } Index: src/LabelTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.cpp,v retrieving revision 1.118 diff -u -r1.118 LabelTrack.cpp --- src/LabelTrack.cpp 29 Sep 2009 00:28:07 -0000 1.118 +++ src/LabelTrack.cpp 16 Oct 2009 03:40:45 -0000 @@ -278,14 +278,14 @@ { for (unsigned int i=0;i<mLabels.GetCount();i++){ // label is after the insert point - if (mLabels[i]->t > pt) { + if (mLabels[i]->t >= pt) { mLabels[i]->t = mLabels[i]->t + length; mLabels[i]->t1 = mLabels[i]->t1 + length; // label is before the insert point - }else if (mLabels[i]->t1 < pt) { + }else if (mLabels[i]->t1 <= pt) { //nothing // insert point is inside the label - }else if (mLabels[i]->t < pt && mLabels[i]->t1 > pt){ + }else{ mLabels[i]->t1 = mLabels[i]->t1 + length; } } @@ -2176,6 +2176,54 @@ return true; } +// This repeats the labels in a time interval a specified number of times. +// Like Paste(), it does not shift existing labels over +// - It assumes that you've already called ShiftLabelsOnInsert(), because +// sometimes with linking enabled that's hard to avoid. +// - It assumes that you inserted the necessary extra time at t1, not t0. +bool LabelTrack::Repeat(double t0, double t1, int n) +{ + // Sanity-check the arguments + if (n < 0 || t1 < t0) return false; + + double tLen = t1 - t0; + + for (unsigned int i = 0; i < mLabels.GetCount(); i++) + { + if (mLabels[i]->t >= t0 && mLabels[i]->t <= t1 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label is completely inside the selection; duplicate it in each + // repeat interval + unsigned int pos = i; // running label insertion position in mLabels + + for (int j = 1; j <= n; j++) + { + LabelStruct *l = new LabelStruct(); + l->t = mLabels[i]->t + j * tLen; + l->t1 = mLabels[i]->t1 + j * tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + } + else if (mLabels[i]->t < t0 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label ends inside the selection; ShiftLabelsOnInsert() hasn't touched + // it, and we need to extend it through to the last repeat interval + mLabels[i]->t1 += n * tLen; + } + + // Other cases have already been handled by ShiftLabelsOnInsert() + } + + return true; +} + bool LabelTrack::Clear(double t0, double t1) { AudacityProject *p = GetActiveProject(); Index: src/LabelTrack.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.h,v retrieving revision 1.51 diff -u -r1.51 LabelTrack.h --- src/LabelTrack.h 12 Sep 2009 06:05:41 -0000 1.51 +++ src/LabelTrack.h 16 Oct 2009 03:40:45 -0000 @@ -117,6 +117,7 @@ virtual bool Copy (double t0, double t1, Track ** dest);// const; virtual bool Clear(double t0, double t1); virtual bool Paste(double t, Track * src); + bool Repeat(double t0, double t1, int n); virtual bool Silence(double t0, double t1); virtual bool InsertSilence(double t, double len); Index: src/WaveClip.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.h,v retrieving revision 1.40 diff -u -r1.40 WaveClip.h --- src/WaveClip.h 9 Oct 2009 14:28:48 -0000 1.40 +++ src/WaveClip.h 16 Oct 2009 03:40:45 -0000 @@ -213,6 +213,10 @@ // Cache of values to colour pixels of Spectrogram - used by TrackArtist SpecPxCache *mSpecPxCache; + // AWD, Oct 2009: for pasting whitespace at the end of selection + bool GetIsPlaceholder() { return mIsPlaceholder; }; + void SetIsPlaceholder(bool val) { mIsPlaceholder = val; }; + protected: wxRect mDisplayRect; @@ -239,6 +243,9 @@ // Cut Lines are nothing more than ordinary wave clips, with the // offset relative to the start of the clip. WaveClipList mCutLines; + + // AWD, Oct. 2009: for whitespace-at-end-of-selection pasting + bool mIsPlaceholder; }; #endif Index: src/WaveClip.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.cpp,v retrieving revision 1.57 diff -u -r1.57 WaveClip.cpp --- src/WaveClip.cpp 9 Oct 2009 14:28:48 -0000 1.57 +++ src/WaveClip.cpp 16 Oct 2009 03:40:46 -0000 @@ -308,6 +308,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = false; } WaveClip::WaveClip(WaveClip& orig, DirManager *projDirManager) @@ -339,6 +340,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = orig.GetIsPlaceholder(); } WaveClip::~WaveClip() Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.527 diff -u -r1.527 Menus.cpp --- src/Menus.cpp 20 Sep 2009 19:06:04 -0000 1.527 +++ src/Menus.cpp 16 Oct 2009 03:40:50 -0000 @@ -3294,6 +3298,10 @@ bool advanceClipboard = true; double srcLength = c->GetEndTime(); + // Keeps track of whether n would be the first WaveTrack in its group to + // receive data from the paste. + bool firstInGroup = true; + while (n && c) { if (n->GetSelected()) { advanceClipboard = true; @@ -3319,7 +3327,11 @@ if (!c){ c = tmpC; while (n && (c->GetKind() != n->GetKind()) ) + { n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; + } if (!n) c = NULL; } @@ -3352,7 +3364,12 @@ ((WaveTrack *) c)->Lock(); if (c->GetKind() == Track::Wave && n && n->GetKind() == Track::Wave) - pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, (WaveTrack*)c); + { + // If not the first in group we set useHandlePaste to true + pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, + (WaveTrack*)c, true, true, NULL, false, !firstInGroup); + firstInGroup = !pastedSomething; + } else pastedSomething = n->Paste(t0, c); @@ -3367,12 +3384,23 @@ if (!((WaveTrack *) n)->IsEmpty(t0, t1)) { ((WaveTrack *) n)->Clear(t0, t1); } + + // firstInGroup should always be false here, unless pasting to + // the first channel failed + if (firstInGroup) + { + pastedSomething = ((WaveTrack *)n)->Paste(t0, c); + firstInGroup = !pastedSomething; + } + else + { + pastedSomething = ((WaveTrack *)n)->HandlePaste(t0, c); + } } else { - ((WaveTrack *) n)->Clear(t0, t1); + n->Clear(t0, t1); + n->Paste(t0, c); } - - n->Paste(t0, c); } if (msClipProject != this && c->GetKind() == Track::Wave) @@ -3385,6 +3413,8 @@ } n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; } // This block handles the cases where our clipboard is smaller Index: src/effects/Repeat.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/effects/Repeat.cpp,v retrieving revision 1.34 diff -u -r1.34 Repeat.cpp --- src/effects/Repeat.cpp 8 Jul 2009 12:09:54 -0000 1.34 +++ src/effects/Repeat.cpp 16 Oct 2009 03:40:50 -0000 @@ -25,7 +25,9 @@ #include "Repeat.h" #include "../ShuttleGui.h" #include "../WaveTrack.h" +#include "../LabelTrack.h" #include "../widgets/TimeTextCtrl.h" +#include "../Project.h" #include <wx/button.h> #include <wx/defs.h> @@ -113,44 +115,55 @@ int nTrack = 0; bool bGoodResult = true; - double maxDestLen = 0.0; // used to change selection to generated bit + double maxDestLen = 0.0; // used to change selection to generated bit + + // Is linking enabled? + AudacityProject *p = GetActiveProject(); + bool isSticky = ( p && p->IsSticky()); TrackListIterator iter(mOutputTracks); - // go to first wavetrack - Track* t; - for (t = iter.First(); t->GetKind() != Track::Wave; t = iter.Next()); - if (!t) - return false; // we only do a "group change" in the first selected track of the group. // Paste call does changes to the group tracks bool first = true; - for (; t && bGoodResult; t = iter.Next()) { + for (Track *t = iter.First(); t && bGoodResult; t = iter.Next()) { if (t->GetKind() == Track::Label) + { + // We repeat labels if linking is enabled and a WaveTrack before this + // has been repeated, or if the label track is selected + if (t->GetSelected() || (isSticky && !first)) + { + LabelTrack* track = (LabelTrack*)t; + + // If this track isn't selected, ShiftLabelsOnInsert() has + // already been called + if (t->GetSelected()) + track->ShiftLabelsOnInsert((mT1 - mT0) * repeatCount, mT1); + + if (!track->Repeat(mT0, mT1, repeatCount)) + { + bGoodResult = false; + break; + } + } first = true; - else if (t->GetKind() == Track::Wave && t->GetSelected()) { + } + else if (t->GetKind() == Track::Wave && t->GetSelected()) + { WaveTrack* track = (WaveTrack*)t; - double trackStart = track->GetStartTime(); - double trackEnd = track->GetEndTime(); - double t0 = mT0 < trackStart? trackStart: mT0; - double t1 = mT1 > trackEnd? trackEnd: mT1; - - if (t1 <= t0) - continue; - - sampleCount start = track->TimeToLongSamples(t0); - sampleCount end = track->TimeToLongSamples(t1); + sampleCount start = track->TimeToLongSamples(mT0); + sampleCount end = track->TimeToLongSamples(mT1); sampleCount len = (sampleCount)(end - start); double tLen = track->LongSamplesToTime(len); - double tc = t0 + tLen; + double tc = mT0 + tLen; if (len <= 0) continue; Track *dest; - track->Copy(t0, t1, &dest); + track->Copy(mT0, mT1, &dest); for(int j=0; j<repeatCount; j++) { if (first) { @@ -182,7 +195,6 @@ if (bGoodResult) { // Select the new bits + original bit -// mT0 = mT1; mT1 = maxDestLen; }

Gale (Audacity Team)

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

| From Al Dimond <[hidden email]>
| Thu, 15 Oct 2009 22:08:45 -0600
| Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> 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.

Agreed. I already had a Windows build with that fix to hand and it
works fine for me, tested with linking on and off, and label track
selected or not. I've marked it as "believed fixed" on the Checklist
and I think we can just commit that.

> 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 [to be] 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.

On the face of it, all that seems reasonable to me. But I've seen very
little feedback about label behaviour in Beta (except the people that
don't understand why deleting a region in one linked audio track
deletes the region in the other). So I can only go on intuition, but I
suspect the main use of labels is with delete and insert, where
linking largely works.

> 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.

Seems to depend a lot then on "fully-overlapped labels always repeat"
being what most people want. It's the behaviour I would have "expected"
but that's only me. Let's see how the latest patch tests out (for me,
that will again have to be a bit later on). Thanks for all your work on it
so far.

Gale

> > 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

Gale (Audacity Team)

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

| From Gale Andrews <[hidden email]>
| Fri, 16 Oct 2009 10:05:35 +0100
| Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!

>
> | From Al Dimond <[hidden email]>
> | Thu, 15 Oct 2009 22:08:45 -0600
> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> > 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.
>
> Agreed. I already had a Windows build with that fix to hand and it
> works fine for me, tested with linking on and off, and label track
> selected or not. I've marked it as "believed fixed" on the Checklist
> and I think we can just commit that.

Looks if I may have spoken too soon (not testing fully enough due
to having to leave, cardinal sin). Cut does not work if only the
lower of two linked audio tracks is selected.

* Ensure linking is on
* Create a 10 seconds tone and duplicate it.
* Select from 4s to 6s in the upper track; CTRL + B,
type a name and ENTER, which leaves the upper
track and label track selected
* Edit > Delete is fine (deletes the region in all tracks)
* Edit > Undo and Edit > Cut is fine also
* Edit > Undo, select 1s to 3s in lower track and Edit > Delete
works as expected
* Edit > Undo, Edit > Cut and nothing happens (same
with Cut Button)
* Edit > Undo, select the region in the upper track only and
Cut works as expected
* Edit > Undo, select the region in both audio tracks and
Cut works as expected

The issue is the same if you click in the label and cut but only the
lower audio track (and the label track) is selected. This scenario
works properly pre-patch (as long as you don't select the label
track, which then cuts too much).

Gale

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

Al Dimond

Re: P3: Labels cannot be repeated ... and more!

Reply Threaded

In reply to this post by Gale (Audacity Team)

I really hate to do this but... version 3a of the patch attached. It doesn't
change repeat behavior at all. Details way down at the bottom.

On Friday 16 October 2009 03:05:35 Gale Andrews wrote:

> | From Al Dimond <[hidden email]>
> | Thu, 15 Oct 2009 22:08:45 -0600
> | Subject: [Audacity-devel] P3: Labels cannot be repeated ... and more!
> |
> > 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.
>
> Agreed. I already had a Windows build with that fix to hand and it
> works fine for me, tested with linking on and off, and label track
> selected or not. I've marked it as "believed fixed" on the Checklist
> and I think we can just commit that.
>

Sounds good.

> > 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 [to be] 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.
>
> On the face of it, all that seems reasonable to me. But I've seen very
> little feedback about label behaviour in Beta (except the people that
> don't understand why deleting a region in one linked audio track
> deletes the region in the other). So I can only go on intuition, but I
> suspect the main use of labels is with delete and insert, where
> linking largely works.
>

I think that all linking behavior, would make a lot more sense to users if
there was a visual indication of track groups in the track panel. Having the
existence of track groups tied to a checkbox in a menu and the existence of a
label track is pretty obscure. In my mind, users would want to then be able
to create and modify track groups independent of label tracks... and there's
no way *that* is going to happen for 2.0. If track groups are disabled for
2.0 then I guess we can worry about their appearance later!

(clip)

> > > > 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".
> >

This is what the new version of the patch is about. The bug is: turn linking
on and "editing a clip can move other clips" off. Create two wave tracks and a
label track forming a track group. Generate some audio in both wave tracks;
the first should have one long clip and the second two short ones with a gap in
between. Try to paste something into the gap in the second track that won't
fit. This inserts silence into the first track that can't be undone (however,
if you do something else and undo it, it undoes the damage). This patch fixes
that by attempting the paste into the requested track before attempting to
adjust grouped tracks.

The reason this has to go in this patch is that it's a HandleGroupPaste()
thing, and basically impossible to separate from the other HandleGroupPaste()
changes.

> > > TTFN
> > > Martyn
> >
> > - Al
>

[awd_repeat_paste_fixes_3a.patch]

Index: src/WaveTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveTrack.cpp,v retrieving revision 1.169 diff -u -r1.169 WaveTrack.cpp --- src/WaveTrack.cpp 11 Oct 2009 14:55:47 -0000 1.169 +++ src/WaveTrack.cpp 16 Oct 2009 18:37:42 -0000 @@ -438,6 +438,25 @@ } } } + + // AWD, Oct 2009: If the selection ends in whitespace, create a placeholder + // clip representing that whitespace + if (newTrack->GetEndTime() + 1.0 / newTrack->GetRate() < t1 - t0) + { + WaveClip *placeholder = new WaveClip(mDirManager, + newTrack->GetSampleFormat(), newTrack->GetRate()); + placeholder->SetIsPlaceholder(true); + if ( ! placeholder->InsertSilence( + 0, (t1 - t0) - newTrack->GetEndTime()) ) + { + delete placeholder; + } + else + { + placeholder->Offset(newTrack->GetEndTime()); + newTrack->mClips.Append(placeholder); + } + } *dest = newTrack; @@ -518,7 +537,10 @@ // If duration is 0, then it's just a plain paste if (dur == 0.0) { - return Paste(t0, src, tracks, relativeLabels); + if (useHandlePaste) + return HandlePaste(t0, src); + else + return Paste(t0, src, tracks, relativeLabels); } // If provided time warper was NULL, use a default one that does nothing @@ -863,38 +900,74 @@ // the present track is in a project with groups but doesn't belong to any of them return HandlePaste(t0, src); + // False return from this function causes its changes to not be pushed to + // the undo stack. So we paste into this track first, so any failure + // (usually from "clips can't move" mode) comes before other changes. + // Failures to paste to the group tracks should not cause this function to + // return false; the result might be OK with the user, and if not he can + // easily undo it + if (!HandlePaste(t0, src)) + { + return false; + } + for( ; t; t = it.Next() ) { if (t->GetKind() == Track::Wave) { + WaveTrack *wt = (WaveTrack *)t; if (t==this) { - //paste in the track - if ( !( ((WaveTrack *)t)->HandlePaste(t0, src)) ) return false; + // This track has already been pasted; if it's a stereo track skip + // over the other channel as well. if (t->GetLinked()) t=it.Next(); } else { if (! (t->GetSelected()) ) { if ( sel_len > length ) - // if selection is bigger than the content to add then we need to clear the extra length in the group tracks - ((WaveTrack*)t)->HandleClear(t0+length, t0+sel_len, false, false); + // if selection is bigger than the content to add then we + // need to clear the extra length in the group tracks + wt->HandleClear(t0+length, t0+sel_len, false, false); else if (sel_len < length) { - // if selection is smaller than the content to add then we need to add extra silence in the group tracks - TrackFactory *factory = p->GetTrackFactory(); - WaveTrack *tmp = factory->NewWaveTrack( ((WaveTrack*)t)->GetSampleFormat(), ((WaveTrack*)t)->GetRate()); - tmp->InsertSilence(0.0, length-sel_len); - tmp->Flush(); - if ( !( ((WaveTrack *)t)->HandlePaste(t0+sel_len, tmp)) ) return false; + // if selection is smaller than the content to add then we + // need to add extra space in the group tracks. If the track + // is empty at this point insert whitespace; otherwise, + // silence + if (wt->IsEmpty(t0+sel_len, t0+sel_len)) + { + // Have to check if clips can move in this case + bool clipsCanMove = true; + gPrefs->Read(wxT("/GUI/EditClipCanMove"), &clipsCanMove); + if (clipsCanMove) + { + Track *tmp = NULL; + wt->Cut(t0 + sel_len, + wt->GetEndTime()+1.0/wt->GetRate(), &tmp, false); + wt->HandlePaste(t0 + length, tmp); + delete tmp; + } + } + else + { + TrackFactory *factory = p->GetTrackFactory(); + WaveTrack *tmp = factory->NewWaveTrack( wt->GetSampleFormat(), wt->GetRate()); + tmp->InsertSilence(0.0, length-sel_len); + tmp->Flush(); + wt->HandlePaste(t0+sel_len, tmp); + } } } } } else if (t->GetKind() == Track::Label) { LabelTrack *lt = (LabelTrack *)t; - if (relativeLabels && (sel_len != 0.0)) - lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); - else { - if ((length - sel_len) > 0.0) - lt->ShiftLabelsOnInsert(length-sel_len, t0); - else if ((length - sel_len) < 0.0) - lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + if (!t->GetSelected()) + { + if (relativeLabels && (sel_len != 0.0)) + lt->ScaleLabels(info->sel0, info->sel1, length/sel_len); + else { + if ((length - sel_len) > 0.0) + lt->ShiftLabelsOnInsert(length-sel_len, t0); + else if ((length - sel_len) < 0.0) + lt->ShiftLabelsOnClear(info->sel0+length, info->sel1); + } } } } @@ -933,17 +1006,21 @@ // the only behaviour which is different to what was done before, but it // shouldn't confuse users too much. // - // - If multiple clips should be pasted, these are always pasted as single - // clips, and the current clip is splitted, when necessary. This may seem - // strange at first, but it probably is better than trying to auto-merge - // anything. The user can still merge the clips by hand (which should be - // a simple command reachable by a hotkey or single mouse click). + // - If multiple clips should be pasted, or a single clip that does not fill + // the duration of the pasted track, these are always pasted as single + // clips, and the current clip is splitted, when necessary. This may seem + // strange at first, but it probably is better than trying to auto-merge + // anything. The user can still merge the clips by hand (which should be a + // simple command reachable by a hotkey or single mouse click). // if (other->GetNumClips() == 0) return false; //printf("paste: we have at least one clip\n"); + + bool singleClipMode = (other->GetNumClips() == 1 && + other->GetStartTime() == 0.0); double insertDuration = other->GetEndTime(); WaveClipList::compatibility_iterator it; @@ -952,7 +1029,7 @@ // Make room for the pasted data if (editClipCanMove) { - if (other->GetNumClips() > 1) { + if (!singleClipMode) { // We need to insert multiple clips, so split the current clip and // move everything to the right, then try to paste again if (!IsEmpty(t0, GetEndTime())) { @@ -974,7 +1051,7 @@ } } - if (other->GetNumClips() == 1) + if (singleClipMode) { // Single clip mode // printf("paste: checking for single clip mode!\n"); @@ -1054,11 +1131,15 @@ { WaveClip* clip = it->GetData(); - WaveClip* newClip = new WaveClip(*clip, mDirManager); - newClip->Resample(mRate); - newClip->Offset(t0); - newClip->MarkChanged(); - mClips.Append(newClip); + // AWD Oct. 2009: Don't actually paste in placeholder clips + if (!clip->GetIsPlaceholder()) + { + WaveClip* newClip = new WaveClip(*clip, mDirManager); + newClip->Resample(mRate); + newClip->Offset(t0); + newClip->MarkChanged(); + mClips.Append(newClip); + } } return true; } Index: src/LabelTrack.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.cpp,v retrieving revision 1.118 diff -u -r1.118 LabelTrack.cpp --- src/LabelTrack.cpp 29 Sep 2009 00:28:07 -0000 1.118 +++ src/LabelTrack.cpp 16 Oct 2009 18:37:43 -0000 @@ -278,14 +278,14 @@ { for (unsigned int i=0;i<mLabels.GetCount();i++){ // label is after the insert point - if (mLabels[i]->t > pt) { + if (mLabels[i]->t >= pt) { mLabels[i]->t = mLabels[i]->t + length; mLabels[i]->t1 = mLabels[i]->t1 + length; // label is before the insert point - }else if (mLabels[i]->t1 < pt) { + }else if (mLabels[i]->t1 <= pt) { //nothing // insert point is inside the label - }else if (mLabels[i]->t < pt && mLabels[i]->t1 > pt){ + }else{ mLabels[i]->t1 = mLabels[i]->t1 + length; } } @@ -2176,6 +2176,54 @@ return true; } +// This repeats the labels in a time interval a specified number of times. +// Like Paste(), it does not shift existing labels over +// - It assumes that you've already called ShiftLabelsOnInsert(), because +// sometimes with linking enabled that's hard to avoid. +// - It assumes that you inserted the necessary extra time at t1, not t0. +bool LabelTrack::Repeat(double t0, double t1, int n) +{ + // Sanity-check the arguments + if (n < 0 || t1 < t0) return false; + + double tLen = t1 - t0; + + for (unsigned int i = 0; i < mLabels.GetCount(); i++) + { + if (mLabels[i]->t >= t0 && mLabels[i]->t <= t1 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label is completely inside the selection; duplicate it in each + // repeat interval + unsigned int pos = i; // running label insertion position in mLabels + + for (int j = 1; j <= n; j++) + { + LabelStruct *l = new LabelStruct(); + l->t = mLabels[i]->t + j * tLen; + l->t1 = mLabels[i]->t1 + j * tLen; + l->title = mLabels[i]->title; + + // Figure out where to insert + while (pos < mLabels.Count() && mLabels[pos]->t < l->t) + pos++; + mLabels.Insert(l, pos); + } + } + else if (mLabels[i]->t < t0 && + mLabels[i]->t1 >= t0 && mLabels[i]->t1 <= t1) + { + // Label ends inside the selection; ShiftLabelsOnInsert() hasn't touched + // it, and we need to extend it through to the last repeat interval + mLabels[i]->t1 += n * tLen; + } + + // Other cases have already been handled by ShiftLabelsOnInsert() + } + + return true; +} + bool LabelTrack::Clear(double t0, double t1) { AudacityProject *p = GetActiveProject(); Index: src/LabelTrack.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/LabelTrack.h,v retrieving revision 1.51 diff -u -r1.51 LabelTrack.h --- src/LabelTrack.h 12 Sep 2009 06:05:41 -0000 1.51 +++ src/LabelTrack.h 16 Oct 2009 18:37:43 -0000 @@ -117,6 +117,7 @@ virtual bool Copy (double t0, double t1, Track ** dest);// const; virtual bool Clear(double t0, double t1); virtual bool Paste(double t, Track * src); + bool Repeat(double t0, double t1, int n); virtual bool Silence(double t0, double t1); virtual bool InsertSilence(double t, double len); Index: src/WaveClip.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.h,v retrieving revision 1.40 diff -u -r1.40 WaveClip.h --- src/WaveClip.h 9 Oct 2009 14:28:48 -0000 1.40 +++ src/WaveClip.h 16 Oct 2009 18:37:43 -0000 @@ -213,6 +213,10 @@ // Cache of values to colour pixels of Spectrogram - used by TrackArtist SpecPxCache *mSpecPxCache; + // AWD, Oct 2009: for pasting whitespace at the end of selection + bool GetIsPlaceholder() { return mIsPlaceholder; }; + void SetIsPlaceholder(bool val) { mIsPlaceholder = val; }; + protected: wxRect mDisplayRect; @@ -239,6 +243,9 @@ // Cut Lines are nothing more than ordinary wave clips, with the // offset relative to the start of the clip. WaveClipList mCutLines; + + // AWD, Oct. 2009: for whitespace-at-end-of-selection pasting + bool mIsPlaceholder; }; #endif Index: src/WaveClip.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/WaveClip.cpp,v retrieving revision 1.57 diff -u -r1.57 WaveClip.cpp --- src/WaveClip.cpp 9 Oct 2009 14:28:48 -0000 1.57 +++ src/WaveClip.cpp 16 Oct 2009 18:37:44 -0000 @@ -308,6 +308,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = false; } WaveClip::WaveClip(WaveClip& orig, DirManager *projDirManager) @@ -339,6 +340,7 @@ mAppendBuffer = NULL; mAppendBufferLen = 0; mDirty = 0; + mIsPlaceholder = orig.GetIsPlaceholder(); } WaveClip::~WaveClip() Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.527 diff -u -r1.527 Menus.cpp --- src/Menus.cpp 20 Sep 2009 19:06:04 -0000 1.527 +++ src/Menus.cpp 16 Oct 2009 18:37:48 -0000 @@ -3294,6 +3298,10 @@ bool advanceClipboard = true; double srcLength = c->GetEndTime(); + // Keeps track of whether n would be the first WaveTrack in its group to + // receive data from the paste. + bool firstInGroup = true; + while (n && c) { if (n->GetSelected()) { advanceClipboard = true; @@ -3319,7 +3327,11 @@ if (!c){ c = tmpC; while (n && (c->GetKind() != n->GetKind()) ) + { n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; + } if (!n) c = NULL; } @@ -3352,7 +3364,12 @@ ((WaveTrack *) c)->Lock(); if (c->GetKind() == Track::Wave && n && n->GetKind() == Track::Wave) - pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, (WaveTrack*)c); + { + // If not the first in group we set useHandlePaste to true + pastedSomething = ((WaveTrack*)n)->ClearAndPaste(t0, t1, + (WaveTrack*)c, true, true, NULL, false, !firstInGroup); + firstInGroup = !pastedSomething; + } else pastedSomething = n->Paste(t0, c); @@ -3367,12 +3384,23 @@ if (!((WaveTrack *) n)->IsEmpty(t0, t1)) { ((WaveTrack *) n)->Clear(t0, t1); } + + // firstInGroup should always be false here, unless pasting to + // the first channel failed + if (firstInGroup) + { + pastedSomething = ((WaveTrack *)n)->Paste(t0, c); + firstInGroup = !pastedSomething; + } + else + { + pastedSomething = ((WaveTrack *)n)->HandlePaste(t0, c); + } } else { - ((WaveTrack *) n)->Clear(t0, t1); + n->Clear(t0, t1); + n->Paste(t0, c); } - - n->Paste(t0, c); } if (msClipProject != this && c->GetKind() == Track::Wave) @@ -3385,6 +3413,8 @@ } n = iter.Next(); + if (n && n->GetKind() == Track::Label) + firstInGroup = true; } // This block handles the cases where our clipboard is smaller Index: src/effects/Repeat.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/effects/Repeat.cpp,v retrieving revision 1.34 diff -u -r1.34 Repeat.cpp --- src/effects/Repeat.cpp 8 Jul 2009 12:09:54 -0000 1.34 +++ src/effects/Repeat.cpp 16 Oct 2009 18:37:48 -0000 @@ -25,7 +25,9 @@ #include "Repeat.h" #include "../ShuttleGui.h" #include "../WaveTrack.h" +#include "../LabelTrack.h" #include "../widgets/TimeTextCtrl.h" +#include "../Project.h" #include <wx/button.h> #include <wx/defs.h> @@ -113,44 +115,55 @@ int nTrack = 0; bool bGoodResult = true; - double maxDestLen = 0.0; // used to change selection to generated bit + double maxDestLen = 0.0; // used to change selection to generated bit + + // Is linking enabled? + AudacityProject *p = GetActiveProject(); + bool isSticky = ( p && p->IsSticky()); TrackListIterator iter(mOutputTracks); - // go to first wavetrack - Track* t; - for (t = iter.First(); t->GetKind() != Track::Wave; t = iter.Next()); - if (!t) - return false; // we only do a "group change" in the first selected track of the group. // Paste call does changes to the group tracks bool first = true; - for (; t && bGoodResult; t = iter.Next()) { + for (Track *t = iter.First(); t && bGoodResult; t = iter.Next()) { if (t->GetKind() == Track::Label) + { + // We repeat labels if linking is enabled and a WaveTrack before this + // has been repeated, or if the label track is selected + if (t->GetSelected() || (isSticky && !first)) + { + LabelTrack* track = (LabelTrack*)t; + + // If this track isn't selected, ShiftLabelsOnInsert() has + // already been called + if (t->GetSelected()) + track->ShiftLabelsOnInsert((mT1 - mT0) * repeatCount, mT1); + + if (!track->Repeat(mT0, mT1, repeatCount)) + { + bGoodResult = false; + break; + } + } first = true; - else if (t->GetKind() == Track::Wave && t->GetSelected()) { + } + else if (t->GetKind() == Track::Wave && t->GetSelected()) + { WaveTrack* track = (WaveTrack*)t; - double trackStart = track->GetStartTime(); - double trackEnd = track->GetEndTime(); - double t0 = mT0 < trackStart? trackStart: mT0; - double t1 = mT1 > trackEnd? trackEnd: mT1; - - if (t1 <= t0) - continue; - - sampleCount start = track->TimeToLongSamples(t0); - sampleCount end = track->TimeToLongSamples(t1); + sampleCount start = track->TimeToLongSamples(mT0); + sampleCount end = track->TimeToLongSamples(mT1); sampleCount len = (sampleCount)(end - start); double tLen = track->LongSamplesToTime(len); - double tc = t0 + tLen; + double tc = mT0 + tLen; if (len <= 0) continue; Track *dest; - track->Copy(t0, t1, &dest); + track->Copy(mT0, mT1, &dest); for(int j=0; j<repeatCount; j++) { if (first) { @@ -182,7 +195,6 @@ if (bGoodResult) { // Select the new bits + original bit -// mT0 = mT1; mT1 = maxDestLen; }

1 2 3