Cut removes too much audio
|
|
| 1 2 |
Bill Wharrie
|
I have just tested the fix for this bug on Mac, using Audacity 1.3.10-
alpha-Oct 19 2009 (Unicode). Generate two audio tracks with 30-second chirps Add a label track Select 3 seconds and add label at selection, name the label Linking is on Test #1 Select arbitrary 3 second region spanning both audio tracks and the label track, but not including the labeled region. Edit > Cut removes 3 seconds Edit > Delete removes 3 seconds Edit > Split Delete remove 3 seconds. The Labeled Region commands are disabled in the Edit menu. Fine so far. Test #2 Click on the label to select it, then press enter. Both audio tracks and the label track are selected. Edit > Labeled Regions > Cut: removes 6 seconds from both tracks Edit > Labeled Regions > Delete: same. Not so good - still removing too much audio. Test #3 Shift-click on the top audio track to unselect it. Edit > Labeled Regions > Cut: removes 3 seconds from both tracks Edit > Labeled Regions > Delete: same Edit > Cut: same Edit > Delete: same Not so good - cuts/deletes from a track that is not selected. Now, this may be the design behaviour, and makes sense in a way. With linking on, selecting the label should select all tracks above the label track (at least up to but not including any label track that may be above it). But that is not shown to the user. To show this ... Test #4 Create a new audio track below the label track Fill it with 30 seconds of tone Click on the track panel of the third audio track to select it. Click on the label and press enter At this point the selection is shown extending from the label track down in to the third audio track. Edit > Cut: removes 3 seconds from all three tracks Edit > Delete: same Again, not so good - cuts/deletes audio from tracks that are not selected. Edit > Labeled Regions > Cut: removes 3 seconds from bottom track only Edit > Labeled Regions > Delete: same Strange (says the naive user); I thought that label made a track group with the audio tracks above it, and I used the "Labeled Regions" commands, so why is it acting on the track that is not part of the group? Test #5 With the above track arrangement (audio/audio/label/audio), click in the track panel of the label track, then click on the label, then press enter The selection spans all four tracks (shouldn't it just include the tracks in the group?) Edit > Labeled Regions > Cut: removes 6 seconds from first two audio tracks and 3 seconds from the bottom audio track Edit > Labeled Regions > Delete: does the same Edit > Cut: removes 3 seconds from all three tracks Edit > Delete: removes 3 seconds from all three tracks I think that's enough tests for now. If anyone can think of other scenarios that would be useful to test, let me know. -- 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 Monday 19 October 2009 08:12:09 Bill Wharrie wrote:
> I have just tested the fix for this bug on Mac, using Audacity 1.3.10- > alpha-Oct 19 2009 (Unicode). > I'm working on Linux with CVS head. > Generate two audio tracks with 30-second chirps > Add a label track > Select 3 seconds and add label at selection, name the label > Linking is on > > Test #1 > Select arbitrary 3 second region spanning both audio tracks and the > label track, but not including the labeled region. > Edit > Cut removes 3 seconds > Edit > Delete removes 3 seconds > Edit > Split Delete remove 3 seconds. > The Labeled Region commands are disabled in the Edit menu. > > Fine so far. > Works here also. > Test #2 > Click on the label to select it, then press enter. Both audio tracks > and the label track are selected. > Edit > Labeled Regions > Cut: removes 6 seconds from both tracks > Edit > Labeled Regions > Delete: same. > > Not so good - still removing too much audio. > OK. Oddly, I never even knew this command existed. I'll check what it does. Whatever it is, it appears to be doing it completely wrong. > Test #3 > Shift-click on the top audio track to unselect it. > Edit > Labeled Regions > Cut: removes 3 seconds from both tracks > Edit > Labeled Regions > Delete: same > Edit > Cut: same > Edit > Delete: same > > Not so good - cuts/deletes from a track that is not selected. > > Now, this may be the design behaviour, and makes sense in a way. With > linking on, selecting the label should select all tracks above the > label track (at least up to but not including any label track that may > be above it). But that is not shown to the user. To show this ... > Yeah, that's what's supposed to happen. It would be nice if track groups were displayed more clearly, and I think the official devs are planning to disable track groups in 2.0 because of all the confusion surrounding them. > Test #4 > Create a new audio track below the label track > Fill it with 30 seconds of tone > Click on the track panel of the third audio track to select it. > Click on the label and press enter > > At this point the selection is shown extending from the label track > down in to the third audio track. > > Edit > Cut: removes 3 seconds from all three tracks > Edit > Delete: same > > Again, not so good - cuts/deletes audio from tracks that are not > selected. > Again, this is what's supposed to happen. That's what track grouping means. You have a (label) track in the group selected, and the third, non-grouped track is selected also, so every track in the group plus the non-grouped one have audio removed. > Edit > Labeled Regions > Cut: removes 3 seconds from bottom track only > Edit > Labeled Regions > Delete: same > > Strange (says the naive user); I thought that label made a track group > with the audio tracks above it, and I used the "Labeled Regions" > commands, so why is it acting on the track that is not part of the > group? > Because that track is selected. > Test #5 > With the above track arrangement (audio/audio/label/audio), click in > the track panel of the label track, then click on the label, then > press enter > > The selection spans all four tracks > (shouldn't it just include the tracks in the group?) I don't know. Some comments about this and the "Edit -> Labeled Regions" commands below. > Edit > Labeled Regions > Cut: removes 6 seconds from first two audio > tracks and 3 seconds from the bottom audio track > Edit > Labeled Regions > Delete: does the same > Edit > Cut: removes 3 seconds from all three tracks > Edit > Delete: removes 3 seconds from all three tracks > Right. It again appears that the "Labeled Regions" commands don't understand track groups and make weird mistakes. > I think that's enough tests for now. If anyone can think of other > scenarios that would be useful to test, let me know. > > -- Bill > It looks like the "Labeled Regions" commands and the behavior when you select a label are designed around non-linked mode. Here's what I gather: If you have other tracks selected, selecting a label will (a) change the selection region to the width of the label and (b) select the label track. "Labeled Regions" commands will act on the other selected tracks but not the label track. If you have no other tracks selected, selecting a label selects that label's time-region in all tracks, and the "Labeled Regions" commands work on every track except the label track. All this behavior is great if linking is turned off. In linked mode, even if these things worked exactly the same as in non-linked mode, it wouldn't make a lot of sense. I have some idea of what the code looks like, but I think before I change anything we should have some idea of what the behavior should be. Here is my proposal: 1. The "Labeled Regions" commands should act the same as in non-linked mode, except that when audio is deleted from a track it should also be removed from all grouped tracks, including the label track itself. 2. Label selection behavior should be the same as in non-linked mode, except that when you select a label and no other tracks are selected it should only select all the tracks in its group. If anyone has other ideas chime in. In the meantime I'll work on implementing this behavior. - 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
|
On Monday 19 October 2009 10:33:33 Al Dimond wrote:
... > > Test #4 > > Create a new audio track below the label track > > Fill it with 30 seconds of tone > > Click on the track panel of the third audio track to select it. > > Click on the label and press enter > > > > At this point the selection is shown extending from the label track > > down in to the third audio track. > > > > Edit > Cut: removes 3 seconds from all three tracks > > Edit > Delete: same > > > > Again, not so good - cuts/deletes audio from tracks that are not > > selected. > > Again, this is what's supposed to happen. That's what track grouping > means. You have a (label) track in the group selected, and the third, > non-grouped track is selected also, so every track in the group plus the > non-grouped one have audio removed. > > > Edit > Labeled Regions > Cut: removes 3 seconds from bottom track only > > Edit > Labeled Regions > Delete: same > > > > Strange (says the naive user); I thought that label made a track group > > with the audio tracks above it, and I used the "Labeled Regions" > > commands, so why is it acting on the track that is not part of the > > group? > > Because that track is selected. > That was a bad answer on my part. I'm conflicted as to what *should* happen in this scenario, using the logic at the bottom of my last message. ... > > It looks like the "Labeled Regions" commands and the behavior when you > select a label are designed around non-linked mode. Here's what I gather: > If you have other tracks selected, selecting a label will (a) change the > selection region to the width of the label and (b) select the label track. > "Labeled Regions" commands will act on the other selected tracks but not > the label track. If you have no other tracks selected, selecting a label > selects that label's time-region in all tracks, and the "Labeled Regions" > commands work on every track except the label track. > > All this behavior is great if linking is turned off. In linked mode, even > if these things worked exactly the same as in non-linked mode, it wouldn't > make a lot of sense. I have some idea of what the code looks like, but I > think before I change anything we should have some idea of what the > behavior should be. Here is my proposal: > > 1. The "Labeled Regions" commands should act the same as in non-linked > mode, except that when audio is deleted from a track it should also be > removed from all grouped tracks, including the label track itself. > Also, if no other tracks are selected, it should just act on all the tracks in its group instead of on all the tracks, similar to the rule for selection. But what if there are other tracks selected, just not in the label track's group? Should it then act on all the tracks in its group as well? I can see the case where it does being really confusing, right on the surface. You have a label track and a track below it selected, use "Cut labeled regions", and not only is audio removed from a bunch of non-selected tracks, but it's also copied to the clipboard (whereas if one of the grouped tracks had been selected only its audio would have been copied). However, if it doesn't act on all those tracks, then the label itself would be cleared if nothing else was selected, but not cleared if a track in another group was selected. And that's kind of weird, too. > 2. Label selection behavior should be the same as in non-linked mode, > except that when you select a label and no other tracks are selected it > should only select all the tracks in its group. > > If anyone has other ideas chime in. In the meantime I'll work on > implementing this behavior. > > - 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 |
||||||||||||||||
|
Bill Wharrie
|
In reply to this post
by Bill Wharrie
Some javascript/style in this post has been disabled (why?)
OK, I just did all these tests again with linking off:On 19-Oct-09, at 10:12 AM, Bill Wharrie wrote:
I should have been clearer here. All three tracks are selected because they were already selected from Test #1
With linking off these two commands behave properly - 3 seconds of audio is removed and the label remains.
With linking off, in all cases 3 seconds of audio is removed from the selected track only. The Labeled Regions commands leave the label, the standard commands remove the label.
With linking off, 3 seconds of audio is removed from the bottom track only. The Labeled Regions commands leave the label, the standard commands remove the label.
With linking off, 3 seconds of audio is removed from all 3 audio tracks. The Labeled Regions commands leave the label, the standard commands remove the label. So, I think we can conclude that it is the interaction of linking/grouping and the Labelled Region commands that is the problem. Getting rid of the Labelled Regions commands would seem to prevent users from encountering this bug, and leave the rest of the good things about linking. This still leave the question of how linking is actually supposed to behave. -- 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 |
||||||||||||||||
|
Bill Wharrie
|
In reply to this post
by Al Dimond
On 19-Oct-09, at 12:56 PM, Al Dimond wrote: > On Monday 19 October 2009 10:33:33 Al Dimond wrote: > > ... > >>> Test #4 >>> Create a new audio track below the label track >>> Fill it with 30 seconds of tone >>> Click on the track panel of the third audio track to select it. >>> Click on the label and press enter >>> >>> At this point the selection is shown extending from the label track >>> down in to the third audio track. >>> >>> Edit > Cut: removes 3 seconds from all three tracks >>> Edit > Delete: same >>> >>> Again, not so good - cuts/deletes audio from tracks that are not >>> selected. >> >> Again, this is what's supposed to happen. That's what track grouping >> means. You have a (label) track in the group selected, and the third, >> non-grouped track is selected also, so every track in the group >> plus the >> non-grouped one have audio removed. >> >>> Edit > Labeled Regions > Cut: removes 3 seconds from bottom track >>> only >>> Edit > Labeled Regions > Delete: same >>> >>> Strange (says the naive user); I thought that label made a track >>> group >>> with the audio tracks above it, and I used the "Labeled Regions" >>> commands, so why is it acting on the track that is not part of the >>> group? >> >> Because that track is selected. >> > > That was a bad answer on my part. I'm conflicted as to what *should* > happen in > this scenario, using the logic at the bottom of my last message. > > ... > >> >> It looks like the "Labeled Regions" commands and the behavior when >> you >> select a label are designed around non-linked mode. Here's what I >> gather: >> If you have other tracks selected, selecting a label will (a) >> change the >> selection region to the width of the label and (b) select the label >> track. >> "Labeled Regions" commands will act on the other selected tracks >> but not >> the label track. If you have no other tracks selected, selecting a >> label >> selects that label's time-region in all tracks, and the "Labeled >> Regions" >> commands work on every track except the label track. Yes, I've confirmed this. The "Labeled Regions" commands (at least Cut and Delete) leave the label, whereas the "standard" cut and delete remove the label. >> >> All this behavior is great if linking is turned off. In linked >> mode, even >> if these things worked exactly the same as in non-linked mode, it >> wouldn't >> make a lot of sense. I have some idea of what the code looks like, >> but I >> think before I change anything we should have some idea of what the >> behavior should be. Here is my proposal: >> >> 1. The "Labeled Regions" commands should act the same as in non- >> linked >> mode, except that when audio is deleted from a track it should also >> be >> removed from all grouped tracks, including the label track itself. >> > That's fine, but in this case the user should be prevented from "breaking" a selection across a linked group. More on this below. > Also, if no other tracks are selected, it should just act on all the > tracks in > its group instead of on all the tracks, similar to the rule for > selection. Yes, and the user should see that - i.e. the on-screen selection should extend only to the grouped tracks. > > But what if there are other tracks selected, just not in the label > track's > group? Should it then act on all the tracks in its group as well? > I can see > the case where it does being really confusing, right on the > surface. You have > a label track and a track below it selected, use "Cut labeled > regions", and > not only is audio removed from a bunch of non-selected tracks, but > it's also > copied to the clipboard (whereas if one of the grouped tracks had been > selected only its audio would have been copied). However, if it > doesn't act > on all those tracks, then the label itself would be cleared if > nothing else > was selected, but not cleared if a track in another group was > selected. And > that's kind of weird, too. Head starts to spin, right? :-) We're mixing "linking" with "labeled regions". As I understand it, the point of the "labeled regions" commands is that they leave the label alone. So let's accept that and concentrate on what "linking" means, and its implications. > >> 2. Label selection behavior should be the same as in non-linked mode, >> except that when you select a label and no other tracks are >> selected it >> should only select all the tracks in its group. Yes. And, again, the user should see that. >> >> If anyone has other ideas chime in. In the meantime I'll work on >> implementing this behavior. What does it mean to have a track group? 1) For consistency, if there is a selection in one track of a group, that selection should extend to all tracks in the group, and exclude tracks outside the group (unless the user explicitly adds them?). 1a) Clicking in the track panel of a track group selects all tracks in the group and deselects any previously-selected tracks. 1b) Dragging a selection in one track of a group extends that selection to all tracks in the group and deselects any previously- selected tracks. 1c) Shift-clicking on the track panel of a track in a group to deselect that track is an error - needs an explanatory warning dialog. Similarly, using the arrow keys to give focus to a track in a group then pressing enter to deselect that track is an error. The question remains as to whether the label track should be included in these selections. Probably yes, since it is technically part of the group. This would emphasize that one is dealing with a group. 2) Clicking on a label below a track group selects only the tracks in the group and deselects any previously-selected tracks. Perhaps we could allow shift-clicking on a label to include any previously- selected tracks, but that might introduce too many complications. Instead the user could drag the wanted track into the group. But then we have to watch for that situation and extend the selection to the track that is now part of the group. UI suggestion: when a track group is selected, outline the group with an orange (for example) border. That way the user explicitly sees the group. Or perhaps the yellow "focus" border could go around the group. The question remains as to whether the user should be allowed to change this focus with the keyboard (almost certainly yes, for VI users at least), and what the implications are of moving focus outside the group. This is a question of whether the user should be allowed to add tracks outside the group to the selection. The way groups behave now is inconsistent, I believe, from a naive user's perspective. If those tracks are a group, why don't all operations operate on all tracks in the group all the time? And why can I make a selection in one track of a group, leaving out the other tracks in the group? If I want to do this I'll turn linking off. Why are tracks outside the group included in selections and acted on? I'm going to give this a rest for a while and let it percolate in the back of my mind. I'll probably be back in a while with more observations. :-) Meanwhile, I eagerly await others' thoughts. -- 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 Monday 19 October 2009 12:09:24 Bill Wharrie wrote:
> On 19-Oct-09, at 12:56 PM, Al Dimond wrote: > > On Monday 19 October 2009 10:33:33 Al Dimond wrote: > > > > ... > > > >>> Test #4 > >>> Create a new audio track below the label track > >>> Fill it with 30 seconds of tone > >>> Click on the track panel of the third audio track to select it. > >>> Click on the label and press enter > >>> > >>> At this point the selection is shown extending from the label track > >>> down in to the third audio track. > >>> > >>> Edit > Cut: removes 3 seconds from all three tracks > >>> Edit > Delete: same > >>> > >>> Again, not so good - cuts/deletes audio from tracks that are not > >>> selected. > >> > >> Again, this is what's supposed to happen. That's what track grouping > >> means. You have a (label) track in the group selected, and the third, > >> non-grouped track is selected also, so every track in the group > >> plus the > >> non-grouped one have audio removed. > >> > >>> Edit > Labeled Regions > Cut: removes 3 seconds from bottom track > >>> only > >>> Edit > Labeled Regions > Delete: same > >>> > >>> Strange (says the naive user); I thought that label made a track > >>> group > >>> with the audio tracks above it, and I used the "Labeled Regions" > >>> commands, so why is it acting on the track that is not part of the > >>> group? > >> > >> Because that track is selected. > > > > That was a bad answer on my part. I'm conflicted as to what *should* > > happen in > > this scenario, using the logic at the bottom of my last message. > > > > ... > > > >> It looks like the "Labeled Regions" commands and the behavior when > >> you > >> select a label are designed around non-linked mode. Here's what I > >> gather: > >> If you have other tracks selected, selecting a label will (a) > >> change the > >> selection region to the width of the label and (b) select the label > >> track. > >> "Labeled Regions" commands will act on the other selected tracks > >> but not > >> the label track. If you have no other tracks selected, selecting a > >> label > >> selects that label's time-region in all tracks, and the "Labeled > >> Regions" > >> commands work on every track except the label track. > > Yes, I've confirmed this. The "Labeled Regions" commands (at least Cut > and Delete) leave the label, whereas the "standard" cut and delete > remove the label. > > >> All this behavior is great if linking is turned off. In linked > >> mode, even > >> if these things worked exactly the same as in non-linked mode, it > >> wouldn't > >> make a lot of sense. I have some idea of what the code looks like, > >> but I > >> think before I change anything we should have some idea of what the > >> behavior should be. Here is my proposal: > >> > >> 1. The "Labeled Regions" commands should act the same as in non- > >> linked > >> mode, except that when audio is deleted from a track it should also > >> be > >> removed from all grouped tracks, including the label track itself. > > That's fine, but in this case the user should be prevented from > "breaking" a selection across a linked group. More on this below. > > > Also, if no other tracks are selected, it should just act on all the > > tracks in > > its group instead of on all the tracks, similar to the rule for > > selection. > > Yes, and the user should see that - i.e. the on-screen selection > should extend only to the grouped tracks. > I don't know what you mean, here. I don't think the "Labeled Regions" commands affect which tracks appear selected, whether linking is enabled or not. If you select a label, then deselect all the other tracks and perform a "Labeled Region" operation, currently it operates on all of them but doesn't show them as selected. Are you proposing that this be changed? That after the operation is complete, all the tracks acted on should be selected? I think that might be a nice change. > > But what if there are other tracks selected, just not in the label > > track's > > group? Should it then act on all the tracks in its group as well? > > I can see > > the case where it does being really confusing, right on the > > surface. You have > > a label track and a track below it selected, use "Cut labeled > > regions", and > > not only is audio removed from a bunch of non-selected tracks, but > > it's also > > copied to the clipboard (whereas if one of the grouped tracks had been > > selected only its audio would have been copied). However, if it > > doesn't act > > on all those tracks, then the label itself would be cleared if > > nothing else > > was selected, but not cleared if a track in another group was > > selected. And > > that's kind of weird, too. > > Head starts to spin, right? :-) > > We're mixing "linking" with "labeled regions". > > As I understand it, the point of the "labeled regions" commands is > that they leave the label alone. So let's accept that and concentrate > on what "linking" means, and its implications. > The "labeled regions" commands don't act on label tracks, which is fine. But the point of linked-mode is that the timelines stay synchronized. In order for that to happen, when you cut a selection from one track in a group you have to clear it from the other tracks. The other group tracks, including the label track, are cleared but not copied to the clipboard. So the "labeled region" command doesn't operate directly on the label track, but group behavior dictates that the label track must be edited. Similarly, when you paste or repeat, selected tracks get additional audio and grouped tracks (including label tracks) get silence or whitespace inserted. > >> 2. Label selection behavior should be the same as in non-linked mode, > >> except that when you select a label and no other tracks are > >> selected it > >> should only select all the tracks in its group. > > Yes. And, again, the user should see that. > Yes. > >> If anyone has other ideas chime in. In the meantime I'll work on > >> implementing this behavior. > > What does it mean to have a track group? > > 1) For consistency, if there is a selection in one track of a group, > that selection should extend to all tracks in the group, and exclude > tracks outside the group (unless the user explicitly adds them?). > 1a) Clicking in the track panel of a track group selects all tracks in > the group and deselects any previously-selected tracks. > 1b) Dragging a selection in one track of a group extends that > selection to all tracks in the group and deselects any previously- > selected tracks. > 1c) Shift-clicking on the track panel of a track in a group to > deselect that track is an error - needs an explanatory warning dialog. > Similarly, using the arrow keys to give focus to a track in a group > then pressing enter to deselect that track is an error. > > The question remains as to whether the label track should be included > in these selections. Probably yes, since it is technically part of the > group. This would emphasize that one is dealing with a group. > This is where my point above comes in. The point of grouping is not that every action done to one must be done to all -- just that their timelines are changed together. There are important differences between a track being selected and being grouped. It's possible that this definition of grouping is too complicated. It certainly complicates the code (pretty much every operation that can insert or remove audio has to explicitly account for grouping, and the fact that many of them don't yet is the reason there are so many weird bugs with linking turned on). And my explanation above about why label tracks have to be changed when grouped tracks change... that ain't simple either. Something like what you're talking about, where grouping was handled entirely by manipulating the selection, would be easier for users and programmers to understand. It would be less powerful, and the difficulty is that for some operations the loss of power would be insignificant, and for others it would be very significant. > 2) Clicking on a label below a track group selects only the tracks in > the group and deselects any previously-selected tracks. Perhaps we > could allow shift-clicking on a label to include any previously- > selected tracks, but that might introduce too many complications. > Instead the user could drag the wanted track into the group. But then > we have to watch for that situation and extend the selection to the > track that is now part of the group. > > UI suggestion: when a track group is selected, outline the group with > an orange (for example) border. That way the user explicitly sees the > group. In my opinion we do need something like this -- some visual indicator that something new has been created when a user goes from two wave tracks to two wave tracks and a label track. Maybe a different-colored group indicator for each group. My understanding is that grouping will probably be disabled for 2.0 and that post-2.0 we'll revisit the whole concept, maybe even considering a change in definition. > Or perhaps the yellow "focus" border could go around the group. > The question remains as to whether the user should be allowed to > change this focus with the keyboard (almost certainly yes, for VI > users at least), and what the implications are of moving focus outside > the group. This is a question of whether the user should be allowed to > add tracks outside the group to the selection. > I think the user has to be able to select a group along with non-grouped tracks, because otherwise it's hard to keep an entire project synchronized. > The way groups behave now is inconsistent, I believe, from a naive > user's perspective. If those tracks are a group, why don't all > operations operate on all tracks in the group all the time? And why > can I make a selection in one track of a group, leaving out the other > tracks in the group? If I want to do this I'll turn linking off. Why > are tracks outside the group included in selections and acted on? > > I'm going to give this a rest for a while and let it percolate in the > back of my mind. I'll probably be back in a while with more > observations. :-) > > Meanwhile, I eagerly await others' thoughts. > This whole discussion is, to me, very useful feedback on grouping. I've been wandering in the dark to some degree with changes to grouping behavior, not really knowing what people want out of track groups. Thanks for testing. > -- Bill > > - 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 |
||||||||||||||||
|
Bill Wharrie
|
Some javascript/style in this post has been disabled (why?)
On 19-Oct-09, at 3:15 PM, Al Dimond wrote:
Less powerful in what way?
I can't help thinking of how Pro Tools handles this. I'm not saying Pro Tools is the be-all and end-all, it's just what I've been exposed to. Pro Tools has track groups, but no labels. (Well, it has one label track at the top of the edit window, but that label track is not tied to any particular audio track.) Track groups are created by selecting the desired tracks and saying "Group Tracks". The group is given a name and a colour. The waveforms don't change colour, but (as I recall) there is a little dot in the track panel that indicates that the tracks are part of a group. The group can be enabled and disabled. The indicator in the track panel goes away if the group is disabled. There's a panel in the edit window that lists all your groups. Enabled groups are highlighted. You can enable and disable groups by clicking on their names in this panel. When a group is enabled any editing you do in one track affects the other tracks in the group. Groups can overlap. You can have your "Drum" group that just has the drum tracks, and your "Rhythm Bed" group that includes the drum tracks plus the bass and rhythm guitar. Disclaimer: it's been over a year since I've sat in front of a Pro Tools system, so my memory may be a little hazy on some of the details. Also, this was Pro Tools 6LE, and they're up to version 8 now. So my thinking now (and I reserve the right to change my mind), is that it is perhaps a mistake to tie groups to labels. Let groups be a thing unto themselves, that can include label tracks if you want. Carefully define what a group is and what it does, then implement that. What do Audacity's users want? Is Audacity relentlessly marching down the road to becoming a digital audio workstation? Will it then be too complex for people who want to digitize their LPs or make podcasts? If people outgrow Audacity, there's always Ardour. But, as you say, this is a bigger discussion best left until after 2.0 is released. Just had to get this off my chest.
------------------------------------------------------------------------------ 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 Monday 19 October 2009 14:15:07 Bill Wharrie wrote:
[snip] > What I meant was, if a command is going to act on all tracks in a > group, then the user should see those tracks selected before the > action takes place. If a user chooses Cut, and audio is cut from > tracks that do not show a selection, isn't that bad UI behaviour? > Perhaps (I am far from a UI expert, and I think if I was I wouldn't flatly call that behavior "bad" even if I didn't want it). But the "Labeled Regions" commands don't have any control over what's selected going in. They can't show the user what's going to happen. No command can. If it's indeed bad to remove audio from non-selected tracks (leaving grouping considerations aside), then the command should do nothing when it's executed with only a label track selected. [snip] > > This is where my point above comes in. The point of grouping is > > not that > > every action done to one must be done to all -- just that their > > timelines are > > changed together. There are important differences between a > > track being > > selected and being grouped. > > But in order to keep the timelines synchronized, whatever you do to > one track in the group *must* be done to the others. If you cut > something from one track it must be cut from all tracks in order to > keep everything after the cut in sync. If you don't want this to > happen, turn off the group. > Not quite. If you cut something from one track you have to *clear* something from the others. If you paste something into one track you have to *make room* in the others. > > Something > > like what you're > > talking about, where grouping was handled entirely by > > manipulating the selection, would be easier for users and > > programmers to understand. It would > > be less powerful, and the difficulty is that for some operations > > the loss of > > power would be insignificant, and for others it would be very > > significant. > > Less powerful in what way? > In grouping as you describe it, where selection of one grouped track forced selection of all other grouped tracks, it wouldn't be possible to: - Cut or copy from one grouped track to the clipboard. If the selection extended to all tracks all the tracks' audio would go to the clipboard. - Paste into just one (or, perhaps, just a handful) of the grouped tracks. If all the tracks were selected all would have to receive audio. - Repeat just one of the grouped tracks. As it is, you can do these things to tracks in a group and the other tracks in the group are only modified as necessary to keep the timelines synchronized -- by deleting audio (or whitespace) or adding silence (or whitespace). Making them possible would require a first- class and a second-class selection, which is what we currently have with grouping (it's just really poorly reflected in the UI). I'm not intending to shoot down your proposal; it might be that on balance these things are not very important and that we'd be better off implementing grouping by forcing selections. I just thought I should mention the implication that there would then be no distinction between a grouped track and a selected one, and that that does lead to a loss in power. [snip] > So my thinking now (and I reserve the right to change my mind), is > that it is perhaps a mistake to tie groups to labels. > Let groups be a thing unto themselves, that can include label tracks > if you > want. Carefully define what a group is and what it does, then > implement that. > I agree with this. The situation we have right now in the code is very far from that. There has been a little discussion about changing how some things are represented internally after 2.0, and having a better definition of track groups could be another driver for that process. > What do Audacity's users want? Is Audacity relentlessly marching > down the road to becoming a digital audio workstation? Will it > then be too complex for people who want to digitize their LPs or > make podcasts? If people outgrow Audacity, there's always Ardour. > > But, as you say, this is a bigger discussion best left until after > 2.0 is released. Just had to get this off my chest. > Agreed here as well. Hopefully post-2.0 we can come up with something for track groups that helps more people than it confuses. - 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
|
Following the discussion with Bill, here is a patch. It is very
limited in scope, addressing only what is unequivocally a bug: that too much audio is deleted for "Labeled Regions->Cut" and "Labeled Regions->Delete" when linking is enabled. Specifically, when one of these menu items is chosen with nothing selected, it still applies to all tracks in all cases, and the behavior when a label is selected remains exactly the same. I think there will be plenty of ideas about how to reconcile "Labeled Regions" functions and linking/track groups post-2.0, I just want to make sure that what's definitely a bug gets fixed for beta users. - Al On Monday 19 October 2009 15:07:48 Al Dimond wrote: > On Monday 19 October 2009 14:15:07 Bill Wharrie wrote: > > [snip] > > > What I meant was, if a command is going to act on all tracks in a > > group, then the user should see those tracks selected before the > > action takes place. If a user chooses Cut, and audio is cut from > > tracks that do not show a selection, isn't that bad UI behaviour? > > Perhaps (I am far from a UI expert, and I think if I was I wouldn't > flatly call that behavior "bad" even if I didn't want it). But the > "Labeled Regions" commands don't have any control over what's > selected going in. They can't show the user what's going to > happen. No command can. If it's indeed bad to remove audio from > non-selected tracks (leaving grouping considerations aside), then > the command should do nothing when it's executed with only a label > track selected. > > [snip] > > > > This is where my point above comes in. The point of grouping > > > is not that > > > every action done to one must be done to all -- just that their > > > timelines are > > > changed together. There are important differences between a > > > track being > > > selected and being grouped. > > > > But in order to keep the timelines synchronized, whatever you do > > to one track in the group *must* be done to the others. If you > > cut something from one track it must be cut from all tracks in > > order to keep everything after the cut in sync. If you don't want > > this to happen, turn off the group. > > Not quite. If you cut something from one track you have to *clear* > something from the others. If you paste something into one track > you have to *make room* in the others. > > > > Something > > > like what you're > > > talking about, where grouping was handled entirely by > > > manipulating the selection, would be easier for users and > > > programmers to understand. It would > > > be less powerful, and the difficulty is that for some > > > operations the loss of > > > power would be insignificant, and for others it would be very > > > significant. > > > > Less powerful in what way? > > In grouping as you describe it, where selection of one grouped > track forced selection of all other grouped tracks, it wouldn't be > possible to: > > - Cut or copy from one grouped track to the clipboard. If the > selection extended to all tracks all the tracks' audio would go to > the clipboard. > > - Paste into just one (or, perhaps, just a handful) of the grouped > tracks. If all the tracks were selected all would have to receive > audio. > > - Repeat just one of the grouped tracks. > > As it is, you can do these things to tracks in a group and the > other tracks in the group are only modified as necessary to keep > the timelines synchronized -- by deleting audio (or whitespace) or > adding silence (or whitespace). Making them possible would > require a first- class and a second-class selection, which is what > we currently have with grouping (it's just really poorly reflected > in the UI). > > I'm not intending to shoot down your proposal; it might be that on > balance these things are not very important and that we'd be better > off implementing grouping by forcing selections. I just thought I > should mention the implication that there would then be no > distinction between a grouped track and a selected one, and that > that does lead to a loss in power. > > [snip] > > > So my thinking now (and I reserve the right to change my mind), > > is that it is perhaps a mistake to tie groups to labels. > > Let groups be a thing unto themselves, that can include label > > tracks if you > > want. Carefully define what a group is and what it does, then > > implement that. > > I agree with this. The situation we have right now in the code is > very far from that. There has been a little discussion about > changing how some things are represented internally after 2.0, and > having a better definition of track groups could be another driver > for that process. > > > What do Audacity's users want? Is Audacity relentlessly marching > > down the road to becoming a digital audio workstation? Will it > > then be too complex for people who want to digitize their LPs or > > make podcasts? If people outgrow Audacity, there's always > > Ardour. > > > > But, as you say, this is a bigger discussion best left until > > after 2.0 is released. Just had to get this off my chest. > > Agreed here as well. Hopefully post-2.0 we can come up with > something for track groups that helps more people than it > confuses. > > - Al > [awd_cutlabels_fix.patch] Index: src/Project.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Project.h,v retrieving revision 1.167 diff -u -r1.167 Project.h --- src/Project.h 20 Sep 2009 19:06:06 -0000 1.167 +++ src/Project.h 19 Oct 2009 22:28:55 -0000 @@ -249,7 +249,7 @@ void Rewind(bool shift); void SkipEnd(bool shift); void SetStop(bool bStopped); - void EditByLabel( WaveTrack::EditFunction action ); + void EditByLabel( WaveTrack::EditFunction action, bool groupIteration ); void EditClipboardByLabel( WaveTrack::EditDestFunction action ); bool IsSticky(); bool GetStickyFlag() { return mStickyFlag; }; Index: src/Project.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Project.cpp,v retrieving revision 1.463 diff -u -r1.463 Project.cpp --- src/Project.cpp 15 Oct 2009 19:56:52 -0000 1.463 +++ src/Project.cpp 19 Oct 2009 22:28:58 -0000 @@ -3843,7 +3904,10 @@ //Executes the edit function on all selected wave tracks with //regions specified by selected labels //If No tracks selected, function is applied on all tracks -void AudacityProject::EditByLabel( WaveTrack::EditFunction action ) +//If the function deletes audio, groupIteration should probably be set to true, +// so it won't delete too many times. +void AudacityProject::EditByLabel( WaveTrack::EditFunction action, + bool groupIteration ) { Regions regions; @@ -3851,7 +3915,7 @@ if( regions.GetCount() == 0 ) return; - TrackListIterator iter( mTracks ); + TrackAndGroupIterator iter( mTracks ); Track *n; bool allTracks = true; @@ -3867,13 +3931,27 @@ //Apply action on wavetracks starting from //labeled regions in the end. This is to correctly perform //actions like 'Delete' which collapse the track area. - for( n = iter.First(); n; n = iter.Next() ) + n = iter.First(); + while (n) + { if( n->GetKind() == Track::Wave && ( allTracks || n->GetSelected() ) ) { WaveTrack *wt = ( WaveTrack* )n; for( int i = ( int )regions.GetCount() - 1; i >= 0; i-- ) ( wt->*action )( regions.Item( i )->start, regions.Item( i )->end ); + + // Tracks operated on may need group iteration + if (IsSticky() && groupIteration) + n = iter.NextGroup(); + else + n = iter.Next(); } + else + { + // Tracks not operated on need normal iteration + n = iter.Next(); + } + } //delete label regions for( unsigned int i = 0; i < regions.GetCount(); i++ ) @@ -3883,7 +3961,9 @@ //Executes the edit function on all selected wave tracks with //regions specified by selected labels //If No tracks selected, function is applied on all tracks -//functions copy the edited regions to clipboard, possibly in multiple tracks +//Functions copy the edited regions to clipboard, possibly in multiple tracks +//This probably should not be called if *action() changes the timeline, because +// the copy needs to happen by track, and the timeline change by group. void AudacityProject::EditClipboardByLabel( WaveTrack::EditDestFunction action ) { Regions regions; Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.530 diff -u -r1.530 Menus.cpp --- src/Menus.cpp 18 Oct 2009 19:58:17 -0000 1.530 +++ src/Menus.cpp 19 Oct 2009 22:29:01 -0000 @@ -3653,10 +3653,14 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; + // Because of grouping the copy may need to operate on different tracks than + // the clear, so we do these actions separately. + EditClipboardByLabel( &WaveTrack::Copy ); + if( gPrefs->Read( wxT( "/GUI/EnableCutLines" ), ( long )0 ) ) - EditClipboardByLabel( &WaveTrack::CutAndAddCutLine ); + EditByLabel( &WaveTrack::ClearAndAddCutLine, true ); else - EditClipboardByLabel( &WaveTrack::Cut ); + EditByLabel( &WaveTrack::Clear, true ); msClipProject = this; @@ -3701,7 +3705,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Clear ); + EditByLabel( &WaveTrack::Clear, true ); PushState( _( "Deleted labeled regions" ), _( "Delete Labels" ) ); @@ -3713,7 +3717,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::SplitDelete ); + EditByLabel( &WaveTrack::SplitDelete, false ); PushState( _( "Split Deleted labeled regions" ), _( "Split Delete Labels" ) ); @@ -3725,7 +3729,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Silence ); + EditByLabel( &WaveTrack::Silence, false ); PushState( _( "Silenced labeled regions" ), _( "Silence Labels" ) ); @@ -3737,7 +3741,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Split ); + EditByLabel( &WaveTrack::Split, false ); PushState( _( "Split labeled regions" ), _( "Split Labels" ) ); @@ -3749,7 +3753,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Join ); + EditByLabel( &WaveTrack::Join, false ); PushState( _( "Joined labeled regions" ), _( "Join Labels" ) ); @@ -3761,7 +3765,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Disjoin ); + EditByLabel( &WaveTrack::Disjoin, false ); PushState( _( "Detached labeled regions" ), _( "Detach Labels" ) ); ------------------------------------------------------------------------------ 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)
|
In reply to this post
by Al Dimond
| From Al Dimond <[hidden email]> | Mon, 19 Oct 2009 13:15:16 -0600 | Subject: [Audacity-devel] Cut removes too much audio > On Monday 19 October 2009 12:09:24 Bill Wharrie wrote: > > On 19-Oct-09, at 12:56 PM, Al Dimond wrote: > > >> .... 2. Label selection behavior should be the same as in non-linked mode, > > >> except that when you select a label and no other tracks are selected it > > >> should only select all the tracks in its group. > > > > Yes. And, again, the user should see that. > > > > Yes. Defensible, but confusing? I like linking behaviour to be different to non-linking as regards actions on tracks and labels, but I'm not sure about selection behaviour. What about the scenario: Audio track Audio track Label track Audio track Label track ? > > What does it mean to have a track group? > > > > 1) For consistency, if there is a selection in one track of a group, > > that selection should extend to all tracks in the group, and exclude > > tracks outside the group (unless the user explicitly adds them?). > > 1a) Clicking in the track panel of a track group selects all tracks in > > the group and deselects any previously-selected tracks. > > 1b) Dragging a selection in one track of a group extends that > > selection to all tracks in the group and deselects any previously- > > selected tracks. > > 1c) Shift-clicking on the track panel of a track in a group to > > deselect that track is an error - needs an explanatory warning dialog. > > Similarly, using the arrow keys to give focus to a track in a group > > then pressing enter to deselect that track is an error. > > > > The question remains as to whether the label track should be included > > in these selections. Probably yes, since it is technically part of the > > group. This would emphasize that one is dealing with a group. > > > > This is where my point above comes in. The point of grouping is not that > every action done to one must be done to all -- just that their timelines are > changed together. There are important differences between a track being > selected and being grouped. > > It's possible that this definition of grouping is too complicated. It > certainly complicates the code (pretty much every operation that can insert or > remove audio has to explicitly account for grouping, and the fact that many of > them don't yet is the reason there are so many weird bugs with linking turned > on). And my explanation above about why label tracks have to be changed when > grouped tracks change... that ain't simple either. Something like what you're > talking about, where grouping was handled entirely by manipulating the > selection, would be easier for users and programmers to understand. It would > be less powerful, and the difficulty is that for some operations the loss of > power would be insignificant, and for others it would be very significant. Bill, first thanks for checking the fix against labelled regions. I didn't check labelled regions fully enough, given we'd decided they didn't seem to be the cause of the bug as you first thought. My reaction to what Bill suggests is that this is too mechanistic and restrictive, and we cannot have all manner of errors flying around for actions that work when linking is off (and which basic concept - selection with the keyboard - appears to work well). I do think (as a very experienced user) Bill is sounding confusions that many users will have when and if linking gets into a stable release. If it does, I've completely changed my mind now about it being on by default; I think it must be off, unless it is restricted to a group defined as a single audio track above a label track, and possibly restricted to operating on delete and insert operations as well. I think putting it in a stable release with restrictions like that while we figure what to do is a definite option, because I honestly believe this feature is getting to be a logjam way in excess of its usefulness, and is going to carry on diverting developer time from more important things post 2.0. These might include insulating different parts of the code from each other, real time effects, panning envelopes, scrubbing, dynamically adjustable loops, proper cross-fading and other ways generally of making it easier to find/manipulate the audio you want. Putting linking in like this would give us some basic, understandable functionality while we took stock. Taking stock should include a serious look at how other multi-track professional apps handle labelling. Or do they - is it a feature for single-track apps? Similarly, disabling labelled regions altogether while linking is on should be considered. I haven't fully taken in everything that's been written fully, but would we lose much by doing this? If people want to leave the label behind when cutting, turn linking off? I don't believe visual ways of indicating tracks are grouped will help that much, it's only helpful when you understand what the concept means in the first place. > ... This whole discussion is, to me, very useful feedback on grouping. I've been > wandering in the dark to some degree with changes to grouping behavior, not > really knowing what people want out of track groups. I appreciate all the thought you're giving to this, Al. The trouble is, I think once you get into multiple linked tracks with multiple clips, and doing things like speeding up some of the tracks or clips, the permutations become so great that no solution that satisfies everyone is possible. 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 |
||||||||||||||||
|
Gale (Audacity Team)
|
In reply to this post
by Al Dimond
| From Al Dimond <[hidden email]> | Mon, 19 Oct 2009 10:33:33 -0600 | Subject: [Audacity-devel] Cut removes too much audio > On Monday 19 October 2009 08:12:09 Bill Wharrie wrote: > > I have just tested the fix for this bug on Mac, using Audacity 1.3.10- > > alpha-Oct 19 2009 (Unicode). > > > Test #4 > > Create a new audio track below the label track > > Fill it with 30 seconds of tone > > Click on the track panel of the third audio track to select it. > > Click on the label and press enter > > > > At this point the selection is shown extending from the label track > > down in to the third audio track. > > > > Edit > Cut: removes 3 seconds from all three tracks > > Edit > Delete: same > > > > Again, not so good - cuts/deletes audio from tracks that are not > > selected. > > > > Again, this is what's supposed to happen. That's what track grouping means. > You have a (label) track in the group selected, and the third, non-grouped > track is selected also, so every track in the group plus the non-grouped one > have audio removed. > > > Edit > Labeled Regions > Cut: removes 3 seconds from bottom track only > > Edit > Labeled Regions > Delete: same > > > > Strange (says the naive user); I thought that label made a track group > > with the audio tracks above it, and I used the "Labeled Regions" > > commands, so why is it acting on the track that is not part of the > > group? > > > > I'm conflicted as to what *should* happen in this scenario, using the > logic at the bottom of my last message. FWIW, I think the current behaviour is probably correct, if labelled regions are just acting on the region. > > Test #5 > > With the above track arrangement (audio/audio/label/audio), click in > > the track panel of the label track, then click on the label, then > > press enter > > > > The selection spans all four tracks > > (shouldn't it just include the tracks in the group?) As per comments in my other post, I think the selection probably should span all tracks. 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 |
||||||||||||||||
|
Gale (Audacity Team)
|
In reply to this post
by Al Dimond
| From Al Dimond <[hidden email]> | Mon, 19 Oct 2009 16:40:18 -0600 | Subject: [Audacity-devel] Cut removes too much audio > Following the discussion with Bill, here is a patch. It is very > limited in scope, addressing only what is unequivocally a bug: that > too much audio is deleted for "Labeled Regions->Cut" and "Labeled > Regions->Delete" when linking is enabled. Specifically, when one of > these menu items is chosen with nothing selected, it still applies to > all tracks in all cases, and the behavior when a label is selected > remains exactly the same. I think there will be plenty of ideas about > how to reconcile "Labeled Regions" functions and linking/track groups > post-2.0, I just want to make sure that what's definitely a bug gets > fixed for beta users. Thanks, Al. Seems to work well for me on XP. The only things I noticed were behaviour discrepancies which were already there pre-patch, but may as well be decided: * With linking on or off, the Edit > Labeled regions actions which remove audio aren't consistent as to whether they leave the selection region behind or not. Cut removes the region; the rest retain it. On balance, I'd think removing it is better. * If you only select the label track in an AUDIO track AUDIO track LABEL track scenario, then use the Edlt > Labeled region commands that remove audio, the audio is removed from both tracks, whether linking is on or not (when linking is on, the label is deleted too, which seems fine if labelled regions are to be enabled when linking is on). But when linking is off and only the label track is selected, I'd have thought the Labeled Region commands would be greyed, as there are no regions to be removed. Maybe that was a pragmatic decision at the time, but makes even less sense to me now we have grouping. Gale > On Monday 19 October 2009 15:07:48 Al Dimond wrote: > > On Monday 19 October 2009 14:15:07 Bill Wharrie wrote: > > > > [snip] > > > > > What I meant was, if a command is going to act on all tracks in a > > > group, then the user should see those tracks selected before the > > > action takes place. If a user chooses Cut, and audio is cut from > > > tracks that do not show a selection, isn't that bad UI behaviour? > > > > Perhaps (I am far from a UI expert, and I think if I was I wouldn't > > flatly call that behavior "bad" even if I didn't want it). But the > > "Labeled Regions" commands don't have any control over what's > > selected going in. They can't show the user what's going to > > happen. No command can. If it's indeed bad to remove audio from > > non-selected tracks (leaving grouping considerations aside), then > > the command should do nothing when it's executed with only a label > > track selected. > > > > [snip] > > > > > > This is where my point above comes in. The point of grouping > > > > is not that > > > > every action done to one must be done to all -- just that their > > > > timelines are > > > > changed together. There are important differences between a > > > > track being > > > > selected and being grouped. > > > > > > But in order to keep the timelines synchronized, whatever you do > > > to one track in the group *must* be done to the others. If you > > > cut something from one track it must be cut from all tracks in > > > order to keep everything after the cut in sync. If you don't want > > > this to happen, turn off the group. > > > > Not quite. If you cut something from one track you have to *clear* > > something from the others. If you paste something into one track > > you have to *make room* in the others. > > > > > > Something > > > > like what you're > > > > talking about, where grouping was handled entirely by > > > > manipulating the selection, would be easier for users and > > > > programmers to understand. It would > > > > be less powerful, and the difficulty is that for some > > > > operations the loss of > > > > power would be insignificant, and for others it would be very > > > > significant. > > > > > > Less powerful in what way? > > > > In grouping as you describe it, where selection of one grouped > > track forced selection of all other grouped tracks, it wouldn't be > > possible to: > > > > - Cut or copy from one grouped track to the clipboard. If the > > selection extended to all tracks all the tracks' audio would go to > > the clipboard. > > > > - Paste into just one (or, perhaps, just a handful) of the grouped > > tracks. If all the tracks were selected all would have to receive > > audio. > > > > - Repeat just one of the grouped tracks. > > > > As it is, you can do these things to tracks in a group and the > > other tracks in the group are only modified as necessary to keep > > the timelines synchronized -- by deleting audio (or whitespace) or > > adding silence (or whitespace). Making them possible would > > require a first- class and a second-class selection, which is what > > we currently have with grouping (it's just really poorly reflected > > in the UI). > > > > I'm not intending to shoot down your proposal; it might be that on > > balance these things are not very important and that we'd be better > > off implementing grouping by forcing selections. I just thought I > > should mention the implication that there would then be no > > distinction between a grouped track and a selected one, and that > > that does lead to a loss in power. > > > > [snip] > > > > > So my thinking now (and I reserve the right to change my mind), > > > is that it is perhaps a mistake to tie groups to labels. > > > Let groups be a thing unto themselves, that can include label > > > tracks if you > > > want. Carefully define what a group is and what it does, then > > > implement that. > > > > I agree with this. The situation we have right now in the code is > > very far from that. There has been a little discussion about > > changing how some things are represented internally after 2.0, and > > having a better definition of track groups could be another driver > > for that process. > > > > > What do Audacity's users want? Is Audacity relentlessly marching > > > down the road to becoming a digital audio workstation? Will it > > > then be too complex for people who want to digitize their LPs or > > > make podcasts? If people outgrow Audacity, there's always > > > Ardour. > > > > > > But, as you say, this is a bigger discussion best left until > > > after 2.0 is released. Just had to get this off my chest. > > > > Agreed here as well. Hopefully post-2.0 we can come up with > > something for track groups that helps more people than it > > confuses. > > > > - 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
|
New patch!
On Wednesday 21 October 2009 00:29:45 Gale Andrews wrote: > | From Al Dimond <[hidden email]> > | Mon, 19 Oct 2009 16:40:18 -0600 > | Subject: [Audacity-devel] Cut removes too much audio > | > > Following the discussion with Bill, here is a patch. It is very > > limited in scope, addressing only what is unequivocally a bug: > > that too much audio is deleted for "Labeled Regions->Cut" and > > "Labeled Regions->Delete" when linking is enabled. Specifically, > > when one of these menu items is chosen with nothing selected, it > > still applies to all tracks in all cases, and the behavior when a > > label is selected remains exactly the same. I think there will > > be plenty of ideas about how to reconcile "Labeled Regions" > > functions and linking/track groups post-2.0, I just want to make > > sure that what's definitely a bug gets fixed for beta users. > > Thanks, Al. Seems to work well for me on XP. > > The only things I noticed were behaviour discrepancies which were > already there pre-patch, but may as well be decided: > > * With linking on or off, the Edit > Labeled regions actions which > remove audio aren't consistent as to whether they leave the > selection region behind or not. Cut removes the region; the > rest retain it. On balance, I'd think removing it is better. > leave the selection except Cut and Delete. It really does look bad when the selection is left after a Delete, so I took it out in that case and left the rest. Cut and Delete, I think, are significantly different from the others, in than they remove audio from the timeline. > * If you only select the label track in an > > AUDIO track > AUDIO track > LABEL track > > scenario, then use the Edlt > Labeled region commands that > remove audio, the audio is removed from both tracks, whether > linking is on or not (when linking is on, the label is deleted > too, which seems fine if labelled regions are to be enabled when > linking is on). > > But when linking is off and only the label track is selected, > I'd have thought the Labeled Region commands would be greyed, as > there are no regions to be removed. Maybe that was a pragmatic > decision at the time, but makes even less sense to me now we have > grouping. > tracks are selected as if all wave tracks are selected. I'm mostly indifferent on whether this is a good idea or not and Bill dislikes it. If you dislike it, too, I'll get rid of it. Remembering that we might not have grouping in stable releases for a while, it might be a good idea to keep this as-is. The patch also changes a behavior than Bill mentioned in the off-list thread, and that we agree is wrong: these commands operated on labels that are in unselected label tracks. With the patch they don't. - Al [awd_cutlabels_fix_2.patch] Index: src/Project.h =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Project.h,v retrieving revision 1.167 diff -u -r1.167 Project.h --- src/Project.h 20 Sep 2009 19:06:06 -0000 1.167 +++ src/Project.h 21 Oct 2009 16:53:55 -0000 @@ -249,7 +249,7 @@ void Rewind(bool shift); void SkipEnd(bool shift); void SetStop(bool bStopped); - void EditByLabel( WaveTrack::EditFunction action ); + void EditByLabel( WaveTrack::EditFunction action, bool groupIteration ); void EditClipboardByLabel( WaveTrack::EditDestFunction action ); bool IsSticky(); bool GetStickyFlag() { return mStickyFlag; }; Index: src/Project.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Project.cpp,v retrieving revision 1.463 diff -u -r1.463 Project.cpp --- src/Project.cpp 15 Oct 2009 19:56:52 -0000 1.463 +++ src/Project.cpp 21 Oct 2009 16:53:58 -0000 @@ -3801,7 +3862,7 @@ //determine labelled regions for( n = iter.First(); n; n = iter.Next() ) - if( n->GetKind() == Track::Label ) + if( n->GetKind() == Track::Label && n->GetSelected() ) { LabelTrack *lt = ( LabelTrack* )n; for( int i = 0; i < lt->GetNumLabels(); i++ ) @@ -3843,7 +3904,10 @@ //Executes the edit function on all selected wave tracks with //regions specified by selected labels //If No tracks selected, function is applied on all tracks -void AudacityProject::EditByLabel( WaveTrack::EditFunction action ) +//If the function deletes audio, groupIteration should probably be set to true, +// so it won't delete too many times. +void AudacityProject::EditByLabel( WaveTrack::EditFunction action, + bool groupIteration ) { Regions regions; @@ -3851,7 +3915,7 @@ if( regions.GetCount() == 0 ) return; - TrackListIterator iter( mTracks ); + TrackAndGroupIterator iter( mTracks ); Track *n; bool allTracks = true; @@ -3867,13 +3931,27 @@ //Apply action on wavetracks starting from //labeled regions in the end. This is to correctly perform //actions like 'Delete' which collapse the track area. - for( n = iter.First(); n; n = iter.Next() ) + n = iter.First(); + while (n) + { if( n->GetKind() == Track::Wave && ( allTracks || n->GetSelected() ) ) { WaveTrack *wt = ( WaveTrack* )n; for( int i = ( int )regions.GetCount() - 1; i >= 0; i-- ) ( wt->*action )( regions.Item( i )->start, regions.Item( i )->end ); + + // Tracks operated on may need group iteration + if (IsSticky() && groupIteration) + n = iter.NextGroup(); + else + n = iter.Next(); } + else + { + // Tracks not operated on need normal iteration + n = iter.Next(); + } + } //delete label regions for( unsigned int i = 0; i < regions.GetCount(); i++ ) @@ -3883,7 +3961,9 @@ //Executes the edit function on all selected wave tracks with //regions specified by selected labels //If No tracks selected, function is applied on all tracks -//functions copy the edited regions to clipboard, possibly in multiple tracks +//Functions copy the edited regions to clipboard, possibly in multiple tracks +//This probably should not be called if *action() changes the timeline, because +// the copy needs to happen by track, and the timeline change by group. void AudacityProject::EditClipboardByLabel( WaveTrack::EditDestFunction action ) { Regions regions; Index: src/Menus.cpp =================================================================== RCS file: /cvsroot/audacity/audacity-src/src/Menus.cpp,v retrieving revision 1.530 diff -u -r1.530 Menus.cpp --- src/Menus.cpp 18 Oct 2009 19:58:17 -0000 1.530 +++ src/Menus.cpp 21 Oct 2009 16:54:01 -0000 @@ -3653,10 +3653,14 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; + // Because of grouping the copy may need to operate on different tracks than + // the clear, so we do these actions separately. + EditClipboardByLabel( &WaveTrack::Copy ); + if( gPrefs->Read( wxT( "/GUI/EnableCutLines" ), ( long )0 ) ) - EditClipboardByLabel( &WaveTrack::CutAndAddCutLine ); + EditByLabel( &WaveTrack::ClearAndAddCutLine, true ); else - EditClipboardByLabel( &WaveTrack::Cut ); + EditByLabel( &WaveTrack::Clear, true ); msClipProject = this; @@ -3701,7 +3705,9 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Clear ); + EditByLabel( &WaveTrack::Clear, true ); + + mViewInfo.sel1 = mViewInfo.sel0 = 0.0; PushState( _( "Deleted labeled regions" ), _( "Delete Labels" ) ); @@ -3713,7 +3719,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::SplitDelete ); + EditByLabel( &WaveTrack::SplitDelete, false ); PushState( _( "Split Deleted labeled regions" ), _( "Split Delete Labels" ) ); @@ -3725,7 +3731,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Silence ); + EditByLabel( &WaveTrack::Silence, false ); PushState( _( "Silenced labeled regions" ), _( "Silence Labels" ) ); @@ -3737,7 +3743,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Split ); + EditByLabel( &WaveTrack::Split, false ); PushState( _( "Split labeled regions" ), _( "Split Labels" ) ); @@ -3749,7 +3755,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Join ); + EditByLabel( &WaveTrack::Join, false ); PushState( _( "Joined labeled regions" ), _( "Join Labels" ) ); @@ -3761,7 +3767,7 @@ if( mViewInfo.sel0 >= mViewInfo.sel1 ) return; - EditByLabel( &WaveTrack::Disjoin ); + EditByLabel( &WaveTrack::Disjoin, false ); PushState( _( "Detached labeled regions" ), _( "Detach Labels" ) ); ------------------------------------------------------------------------------ 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 Al Dimond <[hidden email]> | Wed, 21 Oct 2009 11:49:35 -0600 | Subject: [Audacity-devel] Cut removes too much audio > On Wednesday 21 October 2009 00:29:45 Gale Andrews wrote: > > | From Al Dimond <[hidden email]> > > | Mon, 19 Oct 2009 16:40:18 -0600 > > | Subject: [Audacity-devel] Cut removes too much audio > > | > > > Following the discussion with Bill, here is a patch. It is very > > > limited in scope, addressing only what is unequivocally a bug: > > > that too much audio is deleted for "Labeled Regions->Cut" and > > > "Labeled Regions->Delete" when linking is enabled. Specifically, > > > when one of these menu items is chosen with nothing selected, it > > > still applies to all tracks in all cases, and the behavior when a > > > label is selected remains exactly the same. I think there will > > > be plenty of ideas about how to reconcile "Labeled Regions" > > > functions and linking/track groups post-2.0, I just want to make > > > sure that what's definitely a bug gets fixed for beta users. > > > > Thanks, Al. Seems to work well for me on XP. > > > > The only things I noticed were behaviour discrepancies which were > > already there pre-patch, but may as well be decided: > > > > * With linking on or off, the Edit > Labeled regions actions which > > remove audio aren't consistent as to whether they leave the > > selection region behind or not. Cut removes the region; the > > rest retain it. On balance, I'd think removing it is better. > > I checked what the normal versions of these commands do; all of them > leave the selection except Cut and Delete. It really does look bad > when the selection is left after a Delete, so I took it out in that > case and left the rest. Cut and Delete, I think, are significantly > different from the others, in than they remove audio from the timeline. Shorten the timeline, yes. Good decision, I think. Thanks. > > * If you only select the label track in an > > > > AUDIO track > > AUDIO track > > LABEL track > > > > scenario, then use the Edlt > Labeled region commands that > > remove audio, the audio is removed from both tracks, whether > > linking is on or not (when linking is on, the label is deleted > > too, which seems fine if labelled regions are to be enabled when > > linking is on). > > > > But when linking is off and only the label track is selected, > > I'd have thought the Labeled Region commands would be greyed, as > > there are no regions to be removed. Maybe that was a pragmatic > > decision at the time, but makes even less sense to me now we have > > grouping. > > > > Regardless of linking, these commands treat the case where no wave > tracks are selected as if all wave tracks are selected. I'm mostly > indifferent on whether this is a good idea or not and Bill dislikes it. > If you dislike it, too, I'll get rid of it. Remembering that we might > not have grouping in stable releases for a while, it might be a good > idea to keep this as-is. If you have linking on, select across the label, so only the label track is selected, then Edit > Labeled Regions > Cut, you are still going to lose the label. If the idea of labelled regions is that you operate on the regions without affecting the label, then that suggests to me either that labelled regions are greyed when linking is on, or that they give user a way to enforce keeping the label when deleting without turning linking off. If you have linking off and carry out the above, then you keep the label but remove the audio. You can do the same with more steps and maybe less intuitively by clicking in the label and ENTER twice before the cut. Maybe if people have got used to doing it with Labeled Regions, it should stay? > The patch also changes a behavior than Bill mentioned in the off-list > thread, and that we agree is wrong: these commands operated on labels > that are in unselected label tracks. With the patch they don't. OK, you mean "operated on audio tracks above unselected label tracks"? The idea is that labels are not affected when linking is off, isn't it? This seems to work fine with a single label track with linking off, but in this scenario with only the bottom of two label tracks selected: http://www.gaclrecords.org.uk/lab_reg1.PNG if I use the Labeled Region > Cut command, I'm not clear why audio is removed from the audio track above the non-selected label track: http://www.gaclrecords.org.uk/lab_reg2.PNG This is on the basis that if the bottom label track wasn't selected either, the Labeled Region commands would be greyed. 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 |
||||||||||||||||
|
Bill Wharrie
|
Some javascript/style in this post has been disabled (why?)
On 22-Oct-09, at 5:07 AM, Gale Andrews wrote: [snip]
Here's a picture of what I found and Al has corrected: [Sorry, but my smugmug gallery is the only facility I have for posting screen shots.] This "gallery" has the before and after pictures. The command issued was "Edit > Labeled Regions > Split Cut". Note that in the before picture, the first label track has been selected by clicking on its track panel - the second label track is not selected. Despite this, audio is cut from the region defined by the label in the second audio track (the label called "Three") which is not selected. I can't test Al's patch until is shows up in the nightly builds, but my understanding is that after the patch it applied, in the above situation, audio would still be cut from all three audio tracks, but only from the regions defined by the labels "One" and "Two". Explicitly including an audio track by shift-clicking on its track panel would cause the command to operate only on that audio track (putting aside for the moment the issue of whether the command should "operate" on the label track - that is, remove or not remove the label).
Yes. If no label track is included in the selection (no label track is selected), then the labeled regions commands are greyed. Al wrote (defining the rules for labeled regions behaviour):
-- 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
|
In reply to this post
by Gale (Audacity Team)
On Thursday 22 October 2009 03:07:44 Gale Andrews wrote:
> If you have linking on, select across the label, so only the label > track is selected, then Edit > Labeled Regions > Cut, you are > still going to lose the label. If the idea of labelled regions is > that you operate on the regions without affecting the label, then > that suggests to me either that labelled regions are greyed when > linking is on, or that they give user a way to enforce keeping the > label when deleting without turning linking off. > > If you have linking off and carry out the above, then you keep the > label but remove the audio. You can do the same with more steps > and maybe less intuitively by clicking in the label and ENTER > twice before the cut. Maybe if people have got used to doing it > with Labeled Regions, it should stay? > I think the idea of "labeled regions" commands is that you operate only over the regions where a label exists. They don't operate on label tracks -- only Delete and Cut could be meaningfully applied, and Cut would put a label track on the clipboard, which makes pasting a lot more complicated and likely to fail if the receiving tracks aren't set up perfectly. In Bill's message he spelled out the rules, as I stated them off-list, for "labeled regions" behavior. The major rule of linking that when audio is inserted into or removed from a track's timeline, other tracks in the group are adjusted to match. That is, tracks that are not directly operated on can be affected by edits in other tracks. Following the two sets of rules to their conclusions, to me, is better than breaking timeline-synchronization in linked mode. The resulting behavior should definitely be mentioned in the manual, and if it ends up in a release of any sort I'll update that section. Ultimately labels, linking, and the "labeled regions" commands are fairly advanced -- adding special cases to the rules would only make them more complicated. ------------------------------------------------------------------------------ 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 Al Dimond <[hidden email]> | Thu, 22 Oct 2009 12:04:52 -0600 | Subject: [Audacity-devel] Cut removes too much audio > On Thursday 22 October 2009 03:07:44 Gale Andrews wrote: > > If you have linking on, select across the label, so only the label > > track is selected, then Edit > Labeled Regions > Cut, you are > > still going to lose the label. If the idea of labelled regions is > > that you operate on the regions without affecting the label, then > > that suggests to me either that labelled regions are greyed when > > linking is on, or that they give user a way to enforce keeping the > > label when deleting without turning linking off. > > > > If you have linking off and carry out the above, then you keep the > > label but remove the audio. You can do the same with more steps > > and maybe less intuitively by clicking in the label and ENTER > > twice before the cut. Maybe if people have got used to doing it > > with Labeled Regions, it should stay? > > > > I think the idea of "labeled regions" commands is that you operate > only over the regions where a label exists. They don't operate on > label tracks -- only Delete and Cut could be meaningfully applied, and > Cut would put a label track on the clipboard, which makes pasting a > lot more complicated and likely to fail if the receiving tracks aren't > set up perfectly. My example of "selecting across the label" was given not because Labeled Regions should act on labels, but because I think it is likely people may use that as a way of selecting the labeled region in all tracks, rather than clicking on the label. It may be a reason not to prevent labeled regions' current behaviour of selecting the region in all tracks when no tracks are selected. > In Bill's message he spelled out the rules, as I stated them off-list, > for "labeled regions" behavior. The major rule of linking that when > audio is inserted into or removed from a track's timeline, other > tracks in the group are adjusted to match. That is, tracks that are > not directly operated on can be affected by edits in other tracks. > Following the two sets of rules to their conclusions, to me, is better > than breaking timeline-synchronization in linked mode. The resulting > behavior should definitely be mentioned in the manual, and if it ends > up in a release of any sort I'll update that section. Ultimately > labels, linking, and the "labeled regions" commands are fairly > advanced -- adding special cases to the rules would only make them > more complicated. I only skim-read your off-list correspondence. I can support your view of "leaving as is", but IMO Labeled Regions is incompatible with grouping. Either grouping (when turned on) breaks the rules of Labeled Regions (as now); or Labeled Regions break the rules of grouping (which could be argued as pragmatic). 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 |
||||||||||||||||
|
Bill Wharrie
|
Some javascript/style in this post has been disabled (why?)
On 22-Oct-09, at 3:46 PM, Gale Andrews wrote: [snip]
Gale: I don't see how the two are incompatible. Labelled regions commands are enabled when the appropriate conditions are met, and operate only on labelled regions. When linking is off, they operate only on the selected audio tracks (putting aside for the moment the special case where they operate on all audio tracks when no audio tracks are selected). When linking is on, a selection in one track of a group implies a selection (at least for the deletion or insertion of audio so that the tracks stay in sync) in the other tracks of the group. This currently works in the simple case where a user clicks on a label to select its region. See: - third and fourth images -- 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 |
||||||||||||||||
|
Gale (Audacity Team)
|
In reply to this post
by Bill Wharrie
| From Bill Wharrie <[hidden email]> | Thu, 22 Oct 2009 10:31:24 -0400 | Subject: [Audacity-devel] Cut removes too much audio > On 22-Oct-09, at 5:07 AM, Gale Andrews wrote: > [snip] > > > > | From Al Dimond <[hidden email]> > > | Wed, 21 Oct 2009 11:49:35 -0600 > > | Subject: [Audacity-devel] Cut removes too much audio > >> On Wednesday 21 October 2009 00:29:45 Gale Andrews wrote: > > > >> The patch also changes a behavior than Bill mentioned in the off-list > >> thread, and that we agree is wrong: these commands operated on labels > >> that are in unselected label tracks. With the patch they don't. > > > > OK, you mean "operated on audio tracks above unselected label tracks"? > > The idea is that labels are not affected when linking is off, isn't > > it? > > > > This seems to work fine with a single label track with linking off, > > but > > in this scenario with only the bottom of two label tracks selected: > > http://www.gaclrecords.org.uk/lab_reg1.PNG > > > > if I use the Labeled Region > Cut command, I'm not clear why audio is > > removed from the audio track above the non-selected label track: > > http://www.gaclrecords.org.uk/lab_reg2.PNG > > > That's not exactly the behaviour Al is taking about. What you > demonstrate there is, I believe, correct. The selection exists in > audio tracks 2 and 3 (audio tracks 2 and 2 are selected), so the > command acts on those regions. This is with linking off. Sorry, not had chance to get to this yet. I've come to the conclusion in: http://www.gaclrecords.org.uk/lab_reg1.PNG that you're correct, because if you include the first label track in the selection, you can see the selection is inside the label, so relates to the area defined by the bottom label. > I haven't yet considered the behaviour when linking is on. With linking on, Edit > Labeled Regions > Cut does the same as Edit > Cut, whether the first label track is selected or not. I still have a problem here in that "same" means truncating the label in the first label track, and removing it in the second, when Labeled Regions was supposed to retain the label. Why would you use Labeled Regions in this case with linking on, if it does the same as the normal Edit menu commands? Why not let it be more powerful and keep to its own rules, or disable it when linking is on? This looks like a confusing half way house to me. > Here's a picture of what I found and Al has corrected: > > http://billw.smugmug.com/Other/Audacit/10051269_98fUd#689016050_uzyhP > > [Sorry, but my smugmug gallery is the only facility I have for posting > screen shots.] > > This "gallery" has the before and after pictures. The command issued > was "Edit > Labeled Regions > Split Cut". Note that in the before > picture, the first label track has been selected by clicking on its > track panel - the second label track is not selected. Despite this, > audio is cut from the region defined by the label in the second audio > track (the label called "Three") which is not selected. > > I can't test Al's patch until is shows up in the nightly builds, but > my understanding is that after the patch it applied, in the above > situation, audio would still be cut from all three audio tracks, but > only from the regions defined by the labels "One" and "Two". Yes I can confirm that now happens as per Al's fix. Thanks. > Explicitly including an audio track by shift-clicking on its track > panel would cause the command to operate only on that audio track > (putting aside for the moment the issue of whether the command should > "operate" on the label track - that is, remove or not remove the label). That's fine. > Al wrote (defining the rules for labeled regions behaviour): > > > > 0. "Labeled Regions" commands are available whenever a label is fully > > overlapped by the selection in a selected label track. > > > > 1. "Labeled Regions" commands are applied to selected wave tracks, in > > the regions spanned by labels fully overlapped by the selection. > > > > 2. If no wave track is selected, all wave tracks are considered > > selected. That's OK, just leaves my misgivings about labeled regions and grouping. Thanks to both of you for the thought given to it. 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
|
On Sunday 25 October 2009 04:20:25 Gale Andrews wrote:
> Sorry, not had chance to get to this yet. > > I've come to the conclusion in: > http://www.gaclrecords.org.uk/lab_reg1.PNG > > that you're correct, because if you include the first label track > in the selection, you can see the selection is inside the label, > so relates to the area defined by the bottom label. > > > I haven't yet considered the behaviour when linking is on. > > With linking on, Edit > Labeled Regions > Cut does the same as > Edit > Cut, whether the first label track is selected or not. I > still have a problem here in that "same" means truncating the > label in the first label track, and removing it in the second, > when Labeled Regions was supposed to retain the label. The point of labeled regions commands is not "retain labels". Labeled regions commands simply act on wave tracks, which means, with linking off, that labels are retained even when audio is deleted. This is an effect of the way the commands work, but not their purpose. The purpose is that they act only in regions where the selection overlaps a label. This allows you to make what would otherwise be complicated changes with just a couple clicks, regardless of whether labels are retained or not. For example, if you have all your guitar solos labeled you could select the label track and the guitar track and split-delete out the guitar solos so you could practice along. I think that the name of the submenu points to this as the commands' purpose -- it would not make any less sense to call them "labeled regions" commands if Cut and Delete removed the label. Meanwhile, the purpose of linking is that tracks in a group stay synchronized. That's why it's there. De-synchronizing the tracks in a group, including label tracks, breaks it. > Why would you use Labeled Regions in this case with linking on, if > it does the same as the normal Edit menu commands? It only does the same thing as the normal edit menu commands if your selection region exactly overlaps exactly one label. So, yes, in this specific case they do the same thing but this is a fairly trivial case for the command. > Why not let it be more powerful and keep to its own rules, Because the rules of linking are still important. I don't know of any other command that deliberately breaks them. > or disable it when linking is on? Because it still makes many of the same operations easier. > This looks like a confusing half way house to me. I wouldn't mind having Labeled Regions->Delete/Cut operate on the selected label tracks when linking is off -- I think the commands are useful whether they directly act on label tracks or not. It might be more consistent that way. - 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 |
||||||||||||||||
| Free Embeddable Forum Powered by Nabble | Help |
