Re: [Audacity-quality] [Audacity-devel] Edit > Labelled regions

[Steve t. F. <ste...@gm...>]

As I wrote on the forum, the issue can be solved with a very minor
change to the code and no changes at all to the current interface.
http://forum.audacityteam.org/viewtopic.php?p=197703#p197703

In brief, the problem is that there are several user cases where
splitting adjacent labelled regions is required (several examples
shown in the forum topic), but "Labelled Regions > Split" does not
split regions if they are touching.

After testing my original patch, Gale and myself noticed that there
are multiple problems if overlapping labelled regions are handled
individually.
Gale also pointed out that there may be some user cases where it is
desirable to not split labels that touch.

My proposal is that "Labelled Regions > Split" should split regions
even if they are touching, but overlapping regions should be treated
as one region.

This proposal would be easy to document and resolves many of the
inconsistencies in the current behaviour. It also provides a solution
for the user cases that drew attention to the current limitation. It
also provides a means to "tie together" multiple labelled regions so
that they behave as one region, by simply adding a label that overlaps
the regions to be joined (examples demonstrated in the forum topic).

It has been proposed that 'at some time in the future', these labelled
regions commands will be replaced with a more powerful means to handle
multiple regions, so it is probably not worth the effort of going to
great lengths for a 'temporary' solution, however the solution that I
offer here requires changing just one character in the code.

I have been thoroughly testing this solution for several days, and
personally I am happy that the modified behaviour is much more
flexible and useful than the current behaviour. The patch is minimally
invasive (it is a trivial change) and there is no significant risk
involved.

Unless/until there is another option on the table to consider, I think
this change should be implemented.
(patch attached)


Steve



On 18 November 2012 17:07, Steve the Fiddle <ste...@gm...> wrote:
> Thanks for looking at it Gale.
> The patch has a more serious flaw which is somewhat surprising
> behaviour with overlapping labels.
> Perhaps we should discus on -quality (or on the forum) what behaviours
> we actually want and how they may be clearly represented to the user.
>
> Steve
>
> On 18 November 2012 01:14, Gale Andrews <ga...@au...> wrote:
>>
>> | From Steve the Fiddle <ste...@gm...>
>> | Wed, 14 Nov 2012 03:53:00 +0000
>> | Subject: [Audacity-devel] [Audacity-quality] Edit > Labelled regions
>>> Whilst not wanting to get in the way of a superior way of handling
>>> multiple selections, there seems to be an easy fix to make "Labelled
>>> Regions > Split" and "Labelled Regions > Split Cut" split labelled
>>> regions as is suggested by the name. Patch attached.
>>>
>>>
>>> Steve
>>
>> Thanks, Steve.
>>
>> Just as a quick response, I don't think forcing the removal of
>> surplus labels on everyone is the best answer. In any case,
>> the current patch causes Edit > Labeled Regions > Join to
>> fail (AFAICT).
>>
>> Even post-patch there are still a few possibly inconsistent
>> behaviours e.g. when pasting split lines in different cases.
>>
>> I suspect working in a Preference somehow may be a better
>> solution.
>>
>>
>>
>> Gale
>>
>>
>>> On 18 September 2012 02:05, Steve the Fiddle <ste...@gm...> wrote:
>>> > On 18 September 2012 00:36, Gale Andrews <ga...@au...> wrote:
>>> >>
>>> >> | From Steve the Fiddle <ste...@gm...>
>>> >> | Mon, 17 Sep 2012 23:37:31 +0100
>>> >> | Subject: [Audacity-quality] Edit > Labelled regions
>>> >>> On 17 September 2012 17:42, Gale Andrews <ga...@au...> wrote:
>>> >>> [...]
>>> >>> >> >> >> Labelled regions > Split
>>> >>> >> >> >> Splits at each label position creating 5 clips:
>>> >>> >> >> >> 0 to 2, 2 to 3, 3 to 5, 5 to 8 and 8 to 10 seconds.
>>> >>> >> >> >
>>> >>> >> >> > I'm not convinced I would want that to happen in all cases, so
>>> >>> >> >> > the question (if we want Labeled Regions at all in the longer
>>> >>> >> >> > term) is if we want an extra command for each Split function
>>> >>> >> >> > that adds splits to joined or overlapping labels.
>>> >>> >> >>
>>> >>> >> >> If you want to apply just one pair of splits it is just as easy to
>>> >>> >> >> select the (one) region that you want to split and press Ctrl+I. I
>>> >>> >> >> don't see much reason to use "Edit menu > Labelled Regions > Split"
>>> >>> >> >> for such a simple operation.
>>> >>> >> >>
>>> >>> >> >> Unless there is a good reason (user case) to do so then I see no
>>> >>> >> >> reason to extend (complicate) the menu with unnecessary options.
>>> >>> >> >
>>> >>> >> > We don't want to introduce a regression if there is a good
>>> >>> >> > use case to only split at the borders of a concatenated
>>> >>> >> > group of labels. You may need to ask the person who
>>> >>> >> > designed the feature.
>>> >>> >>
>>> >>> >> Who was that? How do I find out?
>>> >>> >
>>> >>> > Just do some searching:
>>> >>> > http://audacity.238276.n2.nabble.com/Edit-functions-for-Labeled-Regions-td249688.html
>>> >>>
>>> >>> Thanks. I thought that there may be some way to who committed what code.
>>> >>
>>> >> You can check "Blame" in Tortoise SVN on Windows.
>>> >>
>>> >> On Linux, maybe svn-grep:
>>> >> http://blog.kotowicz.net/2010/05/grep-subversion-log-messages-with-svn.html ?
>>> >
>>> > Thanks - it didn't help in this case, but it seems to work quite well
>>> > if you know the right word to search for in the log messages.
>>> >
>>> >>
>>> >>
>>> >>> >> Perhaps it was an oversight rather than an intended feature (or even "a bug").
>>> >>> >> I raised this question on -quality because I don't know if it is
>>> >>> >> intended or not. If it is intended, then I'd like to suggest changing
>>> >>> >> the feature as a feature request/enhancement. If it is not intended
>>> >>> >> then I'll put it onto Bugzilla. Can anyone clarify?
>>> >>> >
>>> >>> > It's speculation but I would assume it to be intended. After all, the
>>> >>> > user did join or overlap the labels. As you point out, if you keep the
>>> >>> > labels one sample, apart you can retain individual splits.
>>> >>>
>>> >>> If I'd only wanted to split one section, I'd only have created one label.
>>> >>> I created multiple labels because I wanted to split into multiple parts.
>>> >>>
>>> >>> I know there are workarounds, and I know that it is not a common case,
>>> >>> but that's no reason to not fix it. Unless there is a user case to
>>> >>> justify the current behaviour (and no user case has been put forward)
>>> >>> then my assumption is that it is a bug.
>>> >>>
>>> >>> Steve
>>> >>
>>> >> So there is no consensus on the assumptions. Did you look at the
>>> >> code to see what it is trying to do?
>>> >
>>> > I don't know C/C++ so I can't be sure, but as far as I can tell:
>>> >
>>> > The "Region Labels > operation" feature originally provided options
>>> > for Delete, Split Delete, Silence, Join and "Disjoin".
>>> > "Disjoin" was later renamed as "Detach at Silences" and the other
>>> > options were added.
>>> >
>>> > The problem appears to arise from the fact that the original code was
>>> > not designed to handle "Split Copy" or "Split" so there was no need to
>>> > retain the positions of touching or overlapping regions. For the
>>> > supported functions it was easier to "remove unnecessary regions" so
>>> > as to avoid applying the same operation twice to the same region (the
>>> > relevant code is in Project.cpp around line 4114).
>>> >
>>> > It looks to me like this was overlooked when "Split" and "Split Copy"
>>> > were added.
>>> >
>>> > Steve
>>> >
>>> >>
>>> >> Off the top of my head, suppose you are labelling words in a
>>> >> transcription. Then you want to split the sentence (not each
>>> >> word)?
>>> >>
>>> >> If we want both uses cases, then we have to add a menu
>>> >> item.
>>> >>
>>> >>
>>> >>
>>> >> Gale
>>> >>
>>> >>
>>> >>> > If we are only arguing about "Split" then personally I can live
>>> >>> > with one extra menu item to cover your use case, rather than
>>> >>> > change the current behaviour.
>>> >>> >
>>> >>> > Did you have any comments about my other questions -
>>> >>> >
>>> >>> >>> "Labelled Regions > Split Cut" may not split at all labelled positions.
>>> >>> >>> "Labelled Region > Split" may not split at all labelled positions.
>>> >>> >>
>>> >>> >> Are you talking about the repeatable "problem" that split lines
>>> >>> >> do not occur at label joins or overlaps?
>>> >>> >>
>>> >>> >> Or a moonphase problem of some sort as yet undescribed?
>>> >>> >>
>>> >>> >> What about the paste after "Split Cut"?  If the paste is into another
>>> >>> >> clip then split lines are only added at the outer boundaries of the
>>> >>> >> paste. Is this OK for you? I think this behaviour is expected for a
>>> >>> >> paste that was not from a Labeled Regions operation.
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> >
>>> >>> > Gale
>>> >>> >
>>> >>> >
>>> >>> >> >> >> Labelled regions > Join
>>> >>> >> >> >> Not applicable in this example, but the same behaviour as now:
>>> >>> >> >> >> Any white space gaps that are entirely within 2 to 8 seconds will join.
>>> >>> >> >> >>
>>> >>> >> >> >>
>>> >>> >> >> >> Labelled regions > Detach at silences
>>> >>> >> >> >> Any silence between 2 to 8 second will be removed and replaced with white space.
>>> >>> >> >> >>
>>> >>> >> >> >>
>>> >>> >> >> >> Summary:
>>> >>> >> >> >> 1 To aim for a consistent behaviour in which splits are not created
>>> >>> >> >> >> unless explicit within the function (Split Cut, Split Delete and
>>> >>> >> >> >> Split).
>>> >>> >> >> >> 2 If splitting is explicitly stated in the function (Split Cut, Split
>>> >>> >> >> >> Delete and Split) then splits occur at each label position.
>>> >>> >> >> >
>>> >>> >> >> > OK (with reservations about 2) but can you identify which of the
>>> >>> >> >> > above functions are not actually working now?
>>> >>> >> >>
>>> >>> >> >>
>>> >>> >> >> "Labelled Regions > Split Cut" may not split at all labelled positions.
>>> >>> >> >> "Labelled Region > Split" may not split at all labelled positions.
>>> >>> >> >
>>> >>> >> > Are you talking about the repeatable "problem" that split lines
>>> >>> >> > do not occur at label joins or overlaps?
>>> >>> >> >
>>> >>> >> > Or a moonphase problem of some sort as yet undescribed?
>>> >>> >> >
>>> >>> >> > What about the paste after "Split Cut"?  If the paste is into another
>>> >>> >> > clip then split lines are only added at the outer boundaries of the
>>> >>> >> > paste. Is this OK for you? I think this behaviour is expected for a
>>> >>> >> > paste that was not from a Labeled Regions operation.
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >> "Labelled Regions > Split Delete" is probably not operating internally
>>> >>> >> >> on each labelled region, but from a user perspective this makes no
>>> >>> >> >> difference.
>>> >>> >> >
>>> >>> >> > Does this matter since we do not affect the labels, only their
>>> >>> >> > audio?
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >
>>> >>> >> > Gale
>>> >>> >> >
>>> >>> >> >
>>> >>> >> >> >> On 15 September 2012 20:24, Gale Andrews <ga...@au...> wrote:
>>> >>> >> >> >> >
>>> >>> >> >> >> > | From James Crook <cr...@in...>
>>> >>> >> >> >> > | Sat, 15 Sep 2012 10:15:10 +0100
>>> >>> >> >> >> > | Subject: [Audacity-quality] Edit > Labelled regions
>>> >>> >> >> >> >> On 14/09/2012 22:27, Gale Andrews wrote:
>>> >>> >> >> >> >>
>>> >>> >> >> >> >> > If we silence joined labels individually when there is a region
>>> >>> >> >> >> >> > spanning them, doesn't that mean that all labels become clips?
>>> >>> >> >> >> >> No.
>>> >>> >> >> >> >
>>> >>> >> >> >> > Sorry if I am being obtuse, but I am still not grasping what you
>>> >>> >> >> >> > are driving at.
>>> >>> >> >> >> >
>>> >>> >> >> >> > I can see the case for Labeled Regions > Split creating split
>>> >>> >> >> >> > lines at each joined or overlapped label.
>>> >>> >> >> >> >
>>> >>> >> >> >> > But if a user does Edit > Labeled Regions > Silence Audio
>>> >>> >> >> >> > over a group of joined labels "individually", but we don't
>>> >>> >> >> >> > mark each label with a split line, what is the difference with
>>> >>> >> >> >> > what happens now?
>>> >>> >> >> >> >
>>> >>> >> >> >> > If you are just asking for what I was asking for - ability to
>>> >>> >> >> >> > silence chosen labels from a run of joined labels - I don't see
>>> >>> >> >> >> > an easy mechanism to do that from Edit > Labeled Regions
>>> >>> >> >> >> > without a second cascade.
>>> >>> >> >> >> >
>>> >>> >> >> >> > To me, this would be better done with modified clicks or Labels
>>> >>> >> >> >> > Editor.
>>> >>> >> >> >> >
>>> >>> >> >> >> >
>>> >>> >> >> >> >> >> A label is a labeled region.  If we have selection of multiple
>>> >>> >> >> >> >> >> non-contiguous labels I hear that as meaning the same thing
>>> >>> >> >> >> >> >> as selection of multiple non-contiguous labeled regions.
>>> >>> >> >> >> >> > It is similar, but the GUI way of doing it is would be more flexible
>>> >>> >> >> >> >> > and faster (if supported by a right-click menu).  For example, I
>>> >>> >> >> >> >> > can then select labels 1, 3 and 7 of seven labels for silencing.
>>> >>> >> >> >> >> > With Labeled Regions I get all seven labels silenced.
>>> >>> >> >> >> >> My picture of multiple selections is that I can drag to select labels 1
>>> >>> >> >> >> >> to 6, then ctrl-click label 4 and ctrl-click label 7 and have labels
>>> >>> >> >> >> >> 1,2,3,5,6,7 selected.
>>> >>> >> >> >> >
>>> >>> >> >> >> > Or, select one label then CTRL-click the next ones to be included
>>> >>> >> >> >> > in the selection.
>>> >>> >> >> >> >
>>> >>> >> >> >> > One problem is that currently, CTRL-click a label plays the audio
>>> >>> >> >> >> > of that label, which could be useful in some circumstances but not
>>> >>> >> >> >> > others.
>>> >>> >> >> >> >
>>> >>> >> >> >> > So we might have to use SHIFT-click as we do when including
>>> >>> >> >> >> > tracks in the selection.
>>> >>> >> >> >> >
>>> >>> >> >> >> >
>>> >>> >> >> >> >
>>> >>> >> >> >> >
>>> >>> >> >> >> > Gale
>>> >>> >> >> >> >
>>> >>> >> >> >> >
>>> >>> >> >> >> >
>>> >>> >> >> >> >> If I now apply an effect or silence the selected labels there is no
>>> >>> >> >> >> >> doubt in my mind as to what happens to the audio.  We don't, for
>>> >>> >> >> >> >> example, get an echo applied twice to a region because it is in label 2
>>> >>> >> >> >> >> and label 3 and those labels overlap.
>>> >>> >> >> >> >>
>>> >>> >> >> >> >> The one case I see an ambiguity is duplicate selected labels (or
>>> >>> >> >> >> >> equivalently paste, since copy followed by paste should do the same as
>>> >>> >> >> >> >> duplicate).  There is a version of duplicate that applies the
>>> >>> >> >> >> >> duplication at the audio level and there is a version of duplicate that
>>> >>> >> >> >> >> applies the duplication at the label level.  The difference is clear
>>> >>> >> >> >> >> when labels overlap.  With overlapping labels I would usually want
>>> >>> >> >> >> >> duplication at the label level, and the overlapping clips causing new
>>> >>> >> >> >> >> audio tracks to be made so that the clips are independent.
>>> >>> >> >> >> >>
>>> >>> >> >> >> >>
>>> >>> >> >> >> >>
>>> >>> >> >> >> >> --James.
>>
>>
>> ------------------------------------------------------------------------------
>> Monitor your physical, virtual and cloud infrastructure from a single
>> web console. Get in-depth insight into apps, servers, databases, vmware,
>> SAP, cloud infrastructure, etc. Download 30-day Free Trial.
>> Pricing starts from $795 for 25 servers or applications!
>> http://p.sf.net/sfu/zoho_dev2dev_nov
>> _______________________________________________
>> Audacity-quality mailing list
>> Aud...@li...
>> https://lists.sourceforge.net/lists/listinfo/audacity-quality