Copy-Paste with multiple audio and label tracks

[Bill Wharrie]

This is complicated, and may not be an error.

This may or may not be related to the Audacity clipboard versus system  
clipboard discussion, so I've started a new thread.

1.3.10-alpha-Nov 3 2009 Mac
Linking off, standard edit commands (not labeled region commands).
Starting with tracks:
audio1/label1/label2/audio2, non-overlapping labels in the label tracks.

Drag a selection through all four tracks spanning both labels.

1) Paste into: audio3/audio4/label3/label4 - note tracks are in  
different order
Result: audio3 <- audio 1, audio4 <- audio1, label3 <- label1, label4  
<- label1

Is this right or wrong? If a user did this, what would they expect? Is  
an attempt to do this a user error? If so, should we document this?  
Would anyone other than someone testing the program even try this?


2) Paste into: audio3/label3/label4/audio4 - now tracks are in the  
same order
Result: audio3 <- audio 1, label3 <- label1, label4 <- label2, audio4  
<- audio2

No issue when the receiving and contributing tracks are in the same  
order.

3) Similar behaviour to case (1) with copy/paste
from audio1/label1/audio2
into audio3/audio4/label2
result: audio3 <- audio1, audio4 <- audio1, label2 <- label1
So it's not a matter of there being two label tracks, it's a matter of  
the track order of the contributing and receiving tracks.

An even simpler case:
4) Copy from label1/audio1
Paste into audio2/label2
result: audio2 <- nothing, label2 <- label1

5) Copy from audio1/label1
Paste into label2/audio2
result: label2 <- nothing, audio2 <- audio1

But ...

6) Copy from audio1/audio2/label1
into audio3/label2/audio4
result: audio3 <- audio1, label2 <- label1, audio4 <- audio2
Contradicting my conclusion in (3). This is the first case I've come  
across where copy/paste into differently-ordered tracks "works". In a  
way this is the inverse of case (3). I find it strange that this case  
works but not case (3).

I could start over and rigourously go through all the permutations of  
audio and label tracks (at least for 2 and 3 tracks), but I don't  
think that would contribute any new information.

Next ... when the number of copied-from tracks is different from the  
number of pasted-to tracks.

-- Bill

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

On Tuesday 03 November 2009 14:25:31 Bill Wharrie wrote:

> This is complicated, and may not be an error.
>
> This may or may not be related to the Audacity clipboard versus
>  system clipboard discussion, so I've started a new thread.
>
> 1.3.10-alpha-Nov 3 2009 Mac
> Linking off, standard edit commands (not labeled region commands).
> Starting with tracks:
> audio1/label1/label2/audio2, non-overlapping labels in the label
>  tracks.
>
> Drag a selection through all four tracks spanning both labels.
>
> 1) Paste into: audio3/audio4/label3/label4 - note tracks are in
> different order
> Result: audio3 <- audio 1, audio4 <- audio1, label3 <- label1,
>  label4 <- label1
>
> Is this right or wrong? If a user did this, what would they expect?
>  Is an attempt to do this a user error? If so, should we document
>  this? Would anyone other than someone testing the program even try
>  this?
>

I don't know whether it's right or wrong.  It isn't new; pasting into
tracks that are in a different order than the source tracks activates
lots of logic in OnPaste() that I haven't taken the time to figure out
yet.  It seems to be pretty good at not just giving up...

I've been thinking about schemes to improve the behavior of Paste when
the clipboard tracks don't line up perfectly with target tracks... if
you have ideas about what correct behavior should be let me hear 'em!

It would be very possible to implement something where, say, the
second target audio track always got the contents of the second
clipboard audio track.  It would be a lot of code but fairly easy to
explain/understand, and could be made quite extensible to new track
types.  If there aren't enough clipboard tracks of a particular type
for the number of target tracks of that type, there are several
possible behaviors:

 - We could insert silence/whitespace into the remaining target tracks
 - We could cycle through the clipboard tracks of that type again
 - We could repeatedly paste the last clipboard track of that type
(current behavior is that all remaining target audio tracks get the
contents of the last clipboard audio track, and all other remaining
target tracks just get adjusted)

>
> 2) Paste into: audio3/label3/label4/audio4 - now tracks are in the
> same order
> Result: audio3 <- audio 1, label3 <- label1, label4 <- label2,
>  audio4 <- audio2
>
> No issue when the receiving and contributing tracks are in the same
> order.
>
> 3) Similar behaviour to case (1) with copy/paste
> from audio1/label1/audio2
> into audio3/audio4/label2
> result: audio3 <- audio1, audio4 <- audio1, label2 <- label1
> So it's not a matter of there being two label tracks, it's a matter
>  of the track order of the contributing and receiving tracks.
>
> An even simpler case:
> 4) Copy from label1/audio1
> Paste into audio2/label2
> result: audio2 <- nothing, label2 <- label1
>
> 5) Copy from audio1/label1
> Paste into label2/audio2
> result: label2 <- nothing, audio2 <- audio1
>
> But ...
>
> 6) Copy from audio1/audio2/label1
> into audio3/label2/audio4
> result: audio3 <- audio1, label2 <- label1, audio4 <- audio2
> Contradicting my conclusion in (3). This is the first case I've
>  come across where copy/paste into differently-ordered tracks
>  "works". In a way this is the inverse of case (3). I find it
>  strange that this case works but not case (3).
>
> I could start over and rigourously go through all the permutations
>  of audio and label tracks (at least for 2 and 3 tracks), but I
>  don't think that would contribute any new information.
>
> Next ... when the number of copied-from tracks is different from
>  the number of pasted-to tracks.
>
> -- Bill
>
> -------------------------------------------------------------------
> ----------- 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

[Bill Wharrie]

Damn! I sometimes reply and don't realize I'm not sending to the list.  
Just posting this for all to see.

-- Bill

On 3-Nov-09, at 5:51 PM, Al Dimond wrote:

> On Tuesday 03 November 2009 15:42:47 you wrote:
>> On 3-Nov-09, at 4:57 PM, Al Dimond wrote:
>>> I've been thinking about schemes to improve the behavior of Paste
>>> when the clipboard tracks don't line up perfectly with target
>>> tracks... if you have ideas about what correct behavior should be
>>> let me hear 'em!
>>
>> First, do we even want to attack this in the run-up to 2.0? Or is
>> it a P4 or something, to be ironed out post 2.0?
>>
>> My feeling is that a reasonable user would only want to copy/paste
>> between multiple tracks that line up exactly. We're not seeing
>> these kinds copy/paste issues brought up on the forum AFAIK.
>>
>> I'm beginning to regret I started this. It distracts from the P2s
>> we'd like to clear before Dec 1. If it requires a discussion about
>> what the correct behaviour is, then I say drop it until after 2.0.
>>
>> -- Bill
>>
>
> I think it does require a discussion, and indeed, that discussion will
> chew up list bandwidth.  Waiting sounds fine to me.
>
>  - 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

[James Crook]

Al Dimond wrote:
> I've been thinking about schemes to improve the behavior of Paste when
> the clipboard tracks don't line up perfectly with target tracks... if
> you have ideas about what correct behavior should be let me hear 'em!
>  
For 2.0 we can ignore 'linking on' and have the rule that we treat the
tracks of each kind separately, and if there are more tracks than we are
pasting do nothing to the extra tracks and if fewer don't paste
everything and don't create new tracks (which is what I believe Audacity
currently does for n audio tracks).

It's all a bit of an edge case I think.  The norm will be that the
tracks match up.

With linking on we want to 'do the same' as above within each track
group.  I'll try not to be drawn into further discussion about what to
do with linking on here until we are past 2.0!


--James

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

| From James Crook <[hidden email]>
| Tue, 03 Nov 2009 23:09:23 +0000
| Subject: [Audacity-devel] Copy-Paste with multiple audio and label tracks

> Al Dimond wrote:
> > I've been thinking about schemes to improve the behavior of Paste when
> > the clipboard tracks don't line up perfectly with target tracks... if
> > you have ideas about what correct behavior should be let me hear 'em!
> >  
> For 2.0 we can ignore 'linking on' and have the rule that we treat the
> tracks of each kind separately, and if there are more tracks than we are
> pasting do nothing to the extra tracks and if fewer don't paste
> everything and don't create new tracks (which is what I believe Audacity
> currently does for n audio tracks).

Pasting the first track when we "can't paste everything"  is "OK" but
not much more than that. It doesn't work well for me in that labelled
regions case where selecting none of the audio tracks treats all
of them as selected for the copy.

If the clipboard has contents that came from the track we're pasting
into, should pasting those contents be done rather than slavishly
pasting the first track irrespective? Might be something for after 2.0
though.  



Gale



 

> > This may or may not be related to the Audacity clipboard versus
> >  system clipboard discussion, so I've started a new thread.
> >
> > 1.3.10-alpha-Nov 3 2009 Mac
> > Linking off, standard edit commands (not labeled region commands).
> > Starting with tracks:
> > audio1/label1/label2/audio2, non-overlapping labels in the label
> >  tracks.
> >
> > Drag a selection through all four tracks spanning both labels.
> >
> > 1) Paste into: audio3/audio4/label3/label4 - note tracks are in
> > different order
> > Result: audio3 <- audio 1, audio4 <- audio1, label3 <- label1,
> >  label4 <- label1
> >
> > Is this right or wrong? If a user did this, what would they expect?
> >  Is an attempt to do this a user error? If so, should we document
> >  this? Would anyone other than someone testing the program even try
> >  this?
> >
>
> I don't know whether it's right or wrong.  It isn't new; pasting into
> tracks that are in a different order than the source tracks activates
> lots of logic in OnPaste() that I haven't taken the time to figure out
> yet.  It seems to be pretty good at not just giving up...
>
> I've been thinking about schemes to improve the behavior of Paste when
> the clipboard tracks don't line up perfectly with target tracks... if
> you have ideas about what correct behavior should be let me hear 'em!
>
> It would be very possible to implement something where, say, the
> second target audio track always got the contents of the second
> clipboard audio track.  It would be a lot of code but fairly easy to
> explain/understand, and could be made quite extensible to new track
> types.  If there aren't enough clipboard tracks of a particular type
> for the number of target tracks of that type, there are several
> possible behaviors:
>
>  - We could insert silence/whitespace into the remaining target tracks
>  - We could cycle through the clipboard tracks of that type again
>  - We could repeatedly paste the last clipboard track of that type
> (current behavior is that all remaining target audio tracks get the
> contents of the last clipboard audio track, and all other remaining
> target tracks just get adjusted)
>
> >
> > 2) Paste into: audio3/label3/label4/audio4 - now tracks are in the
> > same order
> > Result: audio3 <- audio 1, label3 <- label1, label4 <- label2,
> >  audio4 <- audio2
> >
> > No issue when the receiving and contributing tracks are in the same
> > order.
> >
> > 3) Similar behaviour to case (1) with copy/paste
> > from audio1/label1/audio2
> > into audio3/audio4/label2
> > result: audio3 <- audio1, audio4 <- audio1, label2 <- label1
> > So it's not a matter of there being two label tracks, it's a matter
> >  of the track order of the contributing and receiving tracks.
> >
> > An even simpler case:
> > 4) Copy from label1/audio1
> > Paste into audio2/label2
> > result: audio2 <- nothing, label2 <- label1
> >
> > 5) Copy from audio1/label1
> > Paste into label2/audio2
> > result: label2 <- nothing, audio2 <- audio1
> >
> > But ...
> >
> > 6) Copy from audio1/audio2/label1
> > into audio3/label2/audio4
> > result: audio3 <- audio1, label2 <- label1, audio4 <- audio2
> > Contradicting my conclusion in (3). This is the first case I've
> >  come across where copy/paste into differently-ordered tracks
> >  "works". In a way this is the inverse of case (3). I find it
> >  strange that this case works but not case (3).
> >
> > I could start over and rigourously go through all the permutations
> >  of audio and label tracks (at least for 2 and 3 tracks), but I
> >  don't think that would contribute any new information.
> >
> > Next ... when the number of copied-from tracks is different from
> >  the number of pasted-to tracks.
> >
> > -- Bill

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Al Dimond]

On Wednesday 04 November 2009 00:04:48 Gale Andrews wrote:

> | From James Crook <[hidden email]>
> | Tue, 03 Nov 2009 23:09:23 +0000
> | Subject: [Audacity-devel] Copy-Paste with multiple audio and
> | label tracks
> |
> > Al Dimond wrote:
> > > I've been thinking about schemes to improve the behavior of
> > > Paste when the clipboard tracks don't line up perfectly with
> > > target tracks... if you have ideas about what correct behavior
> > > should be let me hear 'em!
> >
> > For 2.0 we can ignore 'linking on' and have the rule that we
> > treat the tracks of each kind separately, and if there are more
> > tracks than we are pasting do nothing to the extra tracks and if
> > fewer don't paste everything and don't create new tracks (which
> > is what I believe Audacity currently does for n audio tracks).
>
> Pasting the first track when we "can't paste everything"  is "OK"
>  but not much more than that. It doesn't work well for me in that
>  labelled regions case where selecting none of the audio tracks
>  treats all of them as selected for the copy.
>
> If the clipboard has contents that came from the track we're
>  pasting into, should pasting those contents be done rather than
>  slavishly pasting the first track irrespective? Might be something
>  for after 2.0 though.
>

I'd rather leave the big part of this discussion for later, but I'd
like to note that I like Copy and Paste to be essentially separated
from eachother (communicating only through clipboard contents, which
they handle essentially mechanically), and would rather have tracks
pasted from the clipboard in the order copied (or, perhaps, in the
order copied among track types).

Some of this is because I want OnPaste() to have a straightforward
implementation, but I think a straightforward implementation has
indirect benefits to the user -- the more we try to add intelligence to
Paste in particular cases, the harder it becomes to correctly specify
the behavior for all cases, the harder it is to describe it in the
manual, and the harder it will be for users to discover its logic on
their own.

I understand what you're saying about the labeled regions case, and I
agree that pasting the audio from the matching track is ideal for that
case.  But I wouldn't want to do that unless it fit into a logical
scheme for pasting N clipboard tracks to M target tracks.  (Matching
tracks is somewhat complicated by the fact that users could paste from
different projects, and could change the order of tracks between a copy
and a paste -- it's, again, not hard to deal with that in the case of
pasting to a single track, but it is hard to figure out what to do
pasting to multiple tracks).

 - Al

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel

[Gale (Audacity Team)]

| From Al Dimond <[hidden email]>
| Wed, 4 Nov 2009 08:34:38 -0700
| Subject: [Audacity-devel] Copy-Paste with multiple audio and label tracks
|  > On Wednesday 04 November 2009 00:04:48 Gale Andrews wrote:

> > | From James Crook <[hidden email]>
> > | Tue, 03 Nov 2009 23:09:23 +0000
> > | Subject: [Audacity-devel] Copy-Paste with multiple audio and
> > | label tracks
> > |
> > > Al Dimond wrote:
> > > > I've been thinking about schemes to improve the behavior of
> > > > Paste when the clipboard tracks don't line up perfectly with
> > > > target tracks... if you have ideas about what correct behavior
> > > > should be let me hear 'em!
> > >
> > > For 2.0 we can ignore 'linking on' and have the rule that we
> > > treat the tracks of each kind separately, and if there are more
> > > tracks than we are pasting do nothing to the extra tracks and if
> > > fewer don't paste everything and don't create new tracks (which
> > > is what I believe Audacity currently does for n audio tracks).
> >
> > Pasting the first track when we "can't paste everything"  is "OK"
> >  but not much more than that. It doesn't work well for me in that
> >  labelled regions case where selecting none of the audio tracks
> >  treats all of them as selected for the copy.
> >
> > If the clipboard has contents that came from the track we're
> >  pasting into, should pasting those contents be done rather than
> >  slavishly pasting the first track irrespective? Might be something
> >  for after 2.0 though.
> >
>
> I'd rather leave the big part of this discussion for later, but I'd
> like to note that I like Copy and Paste to be essentially separated
> from eachother (communicating only through clipboard contents, which
> they handle essentially mechanically), and would rather have tracks
> pasted from the clipboard in the order copied (or, perhaps, in the
> order copied among track types).
>
> Some of this is because I want OnPaste() to have a straightforward
> implementation, but I think a straightforward implementation has
> indirect benefits to the user -- the more we try to add intelligence to
> Paste in particular cases, the harder it becomes to correctly specify
> the behavior for all cases, the harder it is to describe it in the
> manual, and the harder it will be for users to discover its logic on
> their own.
>
> I understand what you're saying about the labeled regions case, and I
> agree that pasting the audio from the matching track is ideal for that
> case.  But I wouldn't want to do that unless it fit into a logical
> scheme for pasting N clipboard tracks to M target tracks.  (Matching
> tracks is somewhat complicated by the fact that users could paste from
> different projects, and could change the order of tracks between a copy
> and a paste -- it's, again, not hard to deal with that in the case of
> pasting to a single track, but it is hard to figure out what to do
> pasting to multiple tracks).

I wouldn't argue with any of that. I feel the same dilemma with linking
behaviour (the most user-friendly solution may not be best in
particular cases, taking a longer view).



Gale


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
audacity-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/audacity-devel