Re: [Audacity-quality] Should snapping a region to a label delete the label as well as the region?
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Gale A. <ga...@au...> - 2010-09-11 23:16:07
|
| From Al Dimond <bus...@gm...> | Sat, 11 Sep 2010 12:20:43 -0700 | Subject: [Audacity-quality] Should snapping a region to a label delete the label as well as the region? > On Wednesday, September 08, 2010 23:44:09 Al Dimond wrote: > > I've been experimenting with this. It's not ready to check in yet > > -- one problem is that when you Select All in a label track and > > delete, labels can remain. Generally it's impossible to delete > > point labels at time 0. > > > > We could have label tracks report their beginning/end times > > slightly beyond what they are, to affect how Select All works... > > but I'm not sure we should mess with reporting track length. We > > could special-case it and include point labels at 0 and at > > track-end time when the selection borders them. That's the best > > idea I have right now. > > > > I currently have this sitting in my tree, working as specified above: > point labels bordering the selection aren't included in it unless > they're at time 0 or the very end of the track. Does anyone object to > that behavior? I'll check it in in a few days if there's no comment. Thanks, Al. Is there the same problem with a final point label that's before the end of the track/project - it won't delete after clicking in the label track to select all the labels? Ideally I would still like to select from somewhere before the last label and snap to the last label, but not delete it. Could there be a rule that it's OK to delete the last point label when a selection doesn't transgress it if the selection starts from the first label? I'm not sure why the label at zero won't delete when you select all the labels because the selection must be transgressing it. I don't think the transgression rule should depend on the selection starting from before the label edge otherwise you won't be able to select from a point label part way over the label name and delete it? In other words the deletion trigger is if the selection extends rightwards from the label edge irrespective where it starts from. Hope I'm not missing something obvious. Thanks Gale > > On Tue, Sep 7, 2010 at 10:44 PM, Al Dimond > > > > <bus...@gm...> wrote: > > > On Tuesday, September 07, 2010 21:53:39 Gale Andrews wrote: > > >> Al, > > >> > > >> Thanks for the detailed reply. Although we can never please > > >> everyone, I don't actually recall complaints about the 1.3.8 > > >> behaviour in this regard. > > >> > > >> I guess one reason is that the use cases for point and region > > >> labels are different. A big use case for point labels is doing > > >> track splits, using Analyze > Silence Finder and then trimming > > >> superfluous silence to left of the label. Having the label > > >> disappear when you snap to the label and delete is > > >> understandably irritating in that case, even if you can select > > >> almost to the label, or use Sound Finder instead. > > >> > > >> OTOH I can't think of many great use cases for selecting across > > >> a region label and leaving a point label, even though I > > >> suggested that for possible consistency. Perhaps we're wrong to > > >> consider point and region labels as exactly the same animal? > > > > > > You've convinced me on this point. Well said. Currently most > > > (maybe all?) of the LabelTrack operations are written without > > > explicitly differentiating between point and region labels -- > > > this makes it hard to define desired behavior. > > > > > >> I think another reason 1.3.8 behaviour seemed intuitive here was > > >> that a rule was perceived "delete if selecting across the label, > > >> otherwise not". > > >> > > >> I notice that even now we don't seem to be fully consistent. If > > >> you snap to either a point or region label and cut (including > > >> the label track in the selection), then the paste includes the > > >> label if the label track is included in the selection. But > > >> although the cut when snapping to the point label removes the > > >> label, the cut when snapping to the first edge of the region > > >> label leaves the label behind, so we're pasting something that > > >> wasn't cut. Would there be a problem with not including the > > >> point or region label in the clear or copy unless the region > > >> transgressed a label edge? > > >> > > >> Similarly when we cut a region that goes part way into a region > > >> label, we only cut the part that was inside the label, but we > > >> paste all of the label, which looks odd because the pasted label > > >> is outside the pasted selection. If it were possible in that > > >> case to copy only the truncated part of the label, I think that > > >> might be very useful as a way to "move and split labels". > > > > > > I've noticed some of these problems in the past, and I think the > > > approach you mention here is a good one. I'll make a note to look > > > at this behavior, and some related coding style (it should be > > > possible to split the tests into a function returning an enum > > > specifying the relation between selection and a label -- that > > > would help future-proof the code). Thanks for thinking about > > > this. > > > > > > - Al > > > > > >> Gale > > >> > > >> | From Al Dimond <bus...@gm...> > > >> | Mon, 6 Sep 2010 22:03:23 -0700 > > >> | Subject: [Audacity-quality] Should snapping a region to a > > >> | label delete the label as well as the region? > > >> | > > >> > On Monday, September 06, 2010 00:12:08 ga...@au... > > > > > > wrote: > > >> > > In SVN HEAD, if you drag a selection to a point label then > > >> > > delete with "Sync-Lock" on (or with "Sync-Lock" off but the > > >> > > selection also in the label track), the label is deleted. In > > >> > > 1.3.8 (the previous incarnation of linking) you had to > > >> > > select past the label to delete it. This is perfectly > > >> > > consistent with HEAD deleting the label if you snap to the > > >> > > opposite edge of a region label (which did happen in > > >> > > 1.3.8), but deleting the point label in HEAD seems to be > > >> > > annoying some users. Certainly they don't think it's > > >> > > intuitive). > > >> > > > > >> > > We don't delete a single split line when deleting before it, > > >> > > and leave the right hand split line if deleting in a clip. > > >> > > So how about snapping to a point label retains the label > > >> > > when you delete, and snapping to the opposite edge of a > > >> > > region label reduces the label to a point label (if of > > >> > > course you dragged from somewhere before the label)? > > >> > > > >> > Perhaps. A lot of the LabelTrack primitives have changed since > > >> > 1.3.8, largely to make the code more logical, and some cases > > >> > where selection boundaries and label edges line have probably > > >> > changed behavior. It might help to give these "edge" cases > > >> > some attention generally and decide exactly what the behavior > > >> > should be. > > >> > > > >> > One thing that's important: whenever changes to LabelTrack > > >> > operations are made, the tests for which labels to include > > >> > have to remain consistent. If we don't apply Clear() to a > > >> > point-label when selecting up to its edge, we have to be sure > > >> > not to apply Copy(), SplitDelete(), etc. That is certainly > > >> > possible. There was a recent bug caused by some of the > > >> > operations' tests differing. I remember finishing work on > > >> > that bug satisfied that the tests were all consistent, but, > > >> > of course, I could have missed some things. > > >> > > > >> > This leads to a concern with the second proposal, about > > >> > snapping to the opposite edge. A Copy copies the entire label > > >> > in that case, because there's really no other way to do it. > > >> > Consider a Cut, which is (logically and in the > > >> > implementation) just a Copy followed by a Clear; if the > > >> > result is that the whole label goes to the clipboard, should > > >> > a point label remain in the track also? It seems to me that > > >> > it should not (that leads to some undesirable Cut/Paste > > >> > behavior), and we certainly can't let Cut and Clear have > > >> > different effects. So we basically have to remove the label > > >> > entirely when clearing "across" it. > > >> > > > >> > To me, if clearing "across" a region label doesn't leave > > >> > anything, then clearing "up to" a point label shouldn't leave > > >> > anything either. So by that logic we're kind of stuck with > > >> > current behavior. > > >> > > > >> > I think that if there was no existing behavior to consider > > >> > some people would prefer a point label to remain in these > > >> > cases and others would prefer nothing. We can't make everyone > > >> > happy. The existing behavior exists, is somewhat vetted, and > > >> > can be consistent with regard to issues in the last few > > >> > paragraphs. So I think it should stay as-is. > > >> > > > >> > - Al > > >> > > >> ---------------------------------------------------------------- > > >> --- ----------- This SF.net Dev2Dev email is sponsored by: > > >> > > >> Show off your parallel programming skills. > > >> Enter the Intel(R) Threading Challenge 2010. > > >> http://p.sf.net/sfu/intel-thread-sfd > > >> _______________________________________________ > > >> Audacity-quality mailing list > > >> Aud...@li... > > >> https://lists.sourceforge.net/lists/listinfo/audacity-quality |