Re: [Audacity-quality] [Audacity-devel] Edit > Labelled regions
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2012-11-28 06:25:16
|
On 28 November 2012 05:06, Gale Andrews <ga...@au...> wrote: > Although I recognise Steve's committed patch (r12049) is "here now", > it still causes Edit > Labeled Regions > Join over touching labels > that have split lines to fail. "Fail" is an emotive word indicates that it is "doing the wrong thing". I'm not convinced that that is the case. If you compare the behaviour of adjoining labels with the behaviour of labels that have a gap between them, then the behaviour is identical. The only time that the behaviour changes is if labels overlap, in which case they are treated as one region. This seems to be consistent with the other labelled region behaviours. Labelled regions are treated individually unless they overlap. > > As Steve and I agreed in the Forum, "If Labeled Regions > Split > splits touching labels, I would think the intuitive thing is for > Labeled Regions > Join to join touching labels so they are no > longer individual clips". > > So unless this regression is regarded as acceptable (i.e. use > Edit > Clip Boundaries > Join instead), we still have more to do, > irrespective if we also need a preference. I don't disagree that it may be possible to improve the behaviour further, but I do disagree that the current "Join" behaviour is a "regression". As I described on the forum, the previous behaviour for Labelled Regions > Join was far from simple: Splits and white space are joined if they are entirely "within" (bounded by) one labelled region or multiple labelled regions that touch or overlap. White space is not rendered to silence if it is only partly bound by a region. Split lines that occur exactly on the end of a separate labelled region are not joined, which is perhaps surprising as... Split lines that occur exactly on the end of a labelled region are joined IF that boundary is shared by another region. Split lines that occur exactly on the end of a labelled region are joined if they are bound by an overlapping region. The current behaviour is that audio clips will be joined if the split or gap is entirely within one labelled region. In other words, labelled regions are treated individually unless they overlap, > > Martyn wrote: >> The only argument for having it the way it was seems to be 'I >> labelled one thing, and want to do something else'. > > :=) You can definitely see it like that, if you regard labels that > touch as still being individual labels. If you regard making labels > touch as making them into one label, then it was consistent the > way it was. > > Martyn wrote: >> We can always revert if a better argument / use case come up. > > The problem is that there are two irreconcilable sets of use > cases, according to whether labels that are not separate are > regarded as one label or multiple labels. > > Treating as multiple labels may have more use cases than > treating as one label, . > > We thought retaining labels when deleting a selection that > touched them had more use cases, then ended up having > to make it a Preference. The "words and sentences" use > case that worked with the previous code isn't hypothetical; > I found someone who was doing it, which I probably > half-recalled. Of course he has workarounds, as Steve had > with the previous code. I think that it is worth keeping in mind that the current workaround for joining multiple labels by adding a label to tie them together (overlap them) is an easy workaround. It also provides a flexible way of handling groups of labels whether they are touching or not. The previous workaround of having to manually select each labelled region one at a time was a pita :=) > > At the moment, we have a halfway-house rule "labels that > exactly touch are still separate labels, but labels that overlap > become one label". I understand this might be pragmatic, but > it still doesn't quite make sense to me logically. If I think labels > that are not separated are still single labels, then I Edit > > Labeled Regions > Copy a single label which has another label > overlapped into it, then paste, why would I not expect a split line > at the boundary where the other label overlaps into it? OK, so it's pragmatic rather than philosophical, but if we did that then we would lose the ability to "tie" multiple labels together, the "words and sentences" user would lose his easy workaround and we would be faced with the problem of what to do with duplicate clipboard data. "why would I not expect a split line at the boundary where the other label overlaps into it?" Because labelled regions are treated individually unless they overlap, If, as with the case of deleting / retaining labels, it becomes evident that users need to be able to choose between the current behaviour and the old behaviour, then I'm sure someone will be able to add that feature, but currently it is an "IF". It has also been suggested that there may be a completely new and better way of handling multiple selections. Steve > > I'm certainly not advocating an alternative behaviour for that - we > have to decide, but I am not clear what the use case is for the > "halfway house". > > > > Gale > |