Thread: [Audacity-quality] Edit > Labelled regions
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2012-09-14 14:44:49
|
What is the correct behaviour for "Edit > Labelled Regions > Split" (and similar) if there are multiple labels that share boundaries? For example, if there are labels: 2 seconds to 3 seconds 3 seconds to 5 seconds 5 seconds to 6 seconds. Assuming that all are included in the selection I would have expected that splits would occur at 2,3,5 and 6 seconds. What I'm seeing on Linux is that labels that share a boundary are treated as one label, so in the above example I get splits only at 2 seconds and 6 seconds. Steve |
From: Gale A. <ga...@au...> - 2012-09-14 18:36:35
|
| From Steve the Fiddle <ste...@gm...> | Fri, 14 Sep 2012 15:44:40 +0100 | Subject: [Audacity-quality] Edit > Labelled regions > What is the correct behaviour for "Edit > Labelled Regions > Split" > (and similar) if there are multiple labels that share boundaries? > For example, if there are labels: > > 2 seconds to 3 seconds > 3 seconds to 5 seconds > 5 seconds to 6 seconds. > > Assuming that all are included in the selection I would have expected > that splits would occur at 2,3,5 and 6 seconds. > What I'm seeing on Linux is that labels that share a boundary are > treated as one label, so in the above example I get splits only at 2 > seconds and 6 seconds. > > Steve Thanks, Steve. Yes, same on Windows. The Manual has nothing to say about the case when labels are joined or overlap, but looking at the other Labeled Region commands such as Silence Audio and Split Cut, treating the labels as one is the only thing that makes sense. So Split in your example perhaps should only split at two and six seconds. I agree that splitting at each label might be the more useful case of the two. Should there be a new command "Split at each" or similar? I thought though that Labeled Regions could be on their way out when we can do selection of multiple non-contiguous labels? Gale |
From: James C. <cr...@in...> - 2012-09-14 20:12:13
|
On 14/09/2012 19:36, Gale Andrews wrote: > | From Steve the Fiddle <ste...@gm...> > | Fri, 14 Sep 2012 15:44:40 +0100 > | Subject: [Audacity-quality] Edit > Labelled regions >> What is the correct behaviour for "Edit > Labelled Regions > Split" >> (and similar) if there are multiple labels that share boundaries? >> For example, if there are labels: >> >> 2 seconds to 3 seconds >> 3 seconds to 5 seconds >> 5 seconds to 6 seconds. >> >> Assuming that all are included in the selection I would have expected >> that splits would occur at 2,3,5 and 6 seconds. >> What I'm seeing on Linux is that labels that share a boundary are >> treated as one label, so in the above example I get splits only at 2 >> seconds and 6 seconds. >> >> Steve > Thanks, Steve. Yes, same on Windows. > > The Manual has nothing to say about the case when labels are > joined or overlap, but looking at the other Labeled Region > commands such as Silence Audio and Split Cut, treating the > labels as one is the only thing that makes sense. I disagree. Cutting labels individually and silencing labels individually make sense. > I thought though that Labeled Regions could be on their way out > when we can do selection of multiple non-contiguous labels? I am not following you here. 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. --James. |
From: Gale A. <ga...@au...> - 2012-09-14 21:28:03
|
| From James Crook <cr...@in...> | Fri, 14 Sep 2012 21:12:09 +0100 | Subject: [Audacity-quality] Edit > Labelled regions > On 14/09/2012 19:36, Gale Andrews wrote: > > | From Steve the Fiddle <ste...@gm...> > > | Fri, 14 Sep 2012 15:44:40 +0100 > > | Subject: [Audacity-quality] Edit > Labelled regions > >> What is the correct behaviour for "Edit > Labelled Regions > Split" > >> (and similar) if there are multiple labels that share boundaries? > >> For example, if there are labels: > >> > >> 2 seconds to 3 seconds > >> 3 seconds to 5 seconds > >> 5 seconds to 6 seconds. > >> > >> Assuming that all are included in the selection I would have expected > >> that splits would occur at 2,3,5 and 6 seconds. > >> What I'm seeing on Linux is that labels that share a boundary are > >> treated as one label, so in the above example I get splits only at 2 > >> seconds and 6 seconds. > >> > >> Steve > > Thanks, Steve. Yes, same on Windows. > > > > The Manual has nothing to say about the case when labels are > > joined or overlap, but looking at the other Labeled Region > > commands such as Silence Audio and Split Cut, treating the > > labels as one is the only thing that makes sense. > I disagree. > > Cutting labels individually and silencing labels individually make sense. All the Labeled Region commands cannot easily offer both treating joined labels as one and treating them individually. If we silence joined labels individually when there is a region spanning them, doesn't that mean that all labels become clips? Do we want that? The audio silenced by Labeled Regions is not currently made into a clip. You can still select one of the labels that has been silenced individually. > > I thought though that Labeled Regions could be on their way out > > when we can do selection of multiple non-contiguous labels? > I am not following you here. I am 99% certain you said that yourself when we last discussed the Labeled Regions feature and found conflicting behaviours. I don't recall the details without searching. > 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. Presumably GUI selection of multiple non-contiguous labels would have an equivalent for VI users in Edit Labels. Gale |
From: James C. <cr...@in...> - 2012-09-15 09:15:14
|
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. >> 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. 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. |
From: Gale A. <ga...@au...> - 2012-09-15 19:27:14
|
| 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. |
From: Steve t. F. <ste...@gm...> - 2012-09-15 21:55:04
|
The behaviour that I would expect (and consider most useful), taking as an example: 10 seconds of audio (0 to 10 seconds) Labels at: 2 seconds to 3 seconds 3 seconds to 5 seconds 5 seconds to 8 seconds Audio track and label track selected from 0 seconds to 10 second. Labelled regions > Cut 2 seconds to 8 seconds is cut and may be pasted into an audio track. Same as selecting and cutting 2 to 8 seconds. Pasted audio is one audio clip of 6 seconds duration Labelled regions > Delete 2 seconds to 8 seconds is deleted but not saved to the clipboard so cannot be pasted into an audio track. Same as selecting from 2 to 8 seconds and deleting. Labelled regions > Split Cut 2 seconds to 8 seconds is cut and may be pasted into an audio track. A gap (white space) remains from 2 to 8 seconds. Pasted audio is 6 seconds total duration as 3 audio clips of durations 1, 2 and 3 seconds. Labelled regions > Split Delete 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. Audio not saved to clipboard. Labelled regions > Silence Audio 2 to 8 seconds is made silence. No splits. (Do we need an option "Labelled regions > Split and Silence"? I don't think so.) Labelled regions > Copy 2 seconds to 8 seconds is copied and may be pasted into an audio track. Same as selecting and copying 2 to 8 seconds. Pasted audio is one clip of 6 seconds duration 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. 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: To aim for a consistent behaviour in which splits are not created unless explicit within the function (Split Cut, Split Delete and Split). If splitting is explicitly stated in the function (Split Cut, Split Delete and Split) then splits occur at each label position. Practical note: any unwanted splits can be easily and quickly rejoined by clicking on them. Steve 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. > > > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2012-09-15 23:03:23
|
| From Steve the Fiddle <ste...@gm...> | Sat, 15 Sep 2012 22:54:56 +0100 | Subject: [Audacity-quality] Edit > Labelled regions > The behaviour that I would expect (and consider most useful), taking > as an example: > > 10 seconds of audio (0 to 10 seconds) > > Labels at: > 2 seconds to 3 seconds > 3 seconds to 5 seconds > 5 seconds to 8 seconds > > Audio track and label track selected from 0 seconds to 10 second. > > Labelled regions > Cut > 2 seconds to 8 seconds is cut and may be pasted into an audio track. > Pasted audio is one audio clip of 6 seconds duration This happens now (and of course the selection length is irrelevant as long as it touches labels one and three). I note Cut and Delete are incompatible with Sync-Locked Tracks, I guess this was one of the things we wanted to fix? > Same as selecting and cutting 2 to 8 seconds. That's my point. How much easier it would be if you could select multiple labels (for example, with the keyboard, TAB into the first label, then CTRL + TAB to add the following labels to the selection). > Labelled regions > Delete > 2 seconds to 8 seconds is deleted but not saved to the clipboard so > cannot be pasted into an audio track. > Same as selecting from 2 to 8 seconds and deleting. > > > Labelled regions > Split Cut > 2 seconds to 8 seconds is cut and may be pasted into an audio track. > A gap (white space) remains from 2 to 8 seconds. > Pasted audio is 6 seconds total duration as 3 audio clips of durations > 1, 2 and 3 seconds. > > > Labelled regions > Split Delete > 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. > Audio not saved to clipboard. > > > Labelled regions > Silence Audio > 2 to 8 seconds is made silence. No splits. But this happens now. And I agree "no splits" is the most useful case. > (Do we need an option "Labelled regions > Split and Silence"? > I don't think so.) I don't think so either (or if we do, we need "Split and *" for all the Labeled Regions commands). > Labelled regions > Copy > 2 seconds to 8 seconds is copied and may be pasted into an audio track. > Same as selecting and copying 2 to 8 seconds. > Pasted audio is one clip of 6 seconds duration > > > 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. > Practical note: any unwanted splits can be easily and quickly rejoined > by clicking on them. That is difficult for visually impaired users as screen readers do not identify clips. > 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? Thanks, 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. |
From: Steve t. F. <ste...@gm...> - 2012-09-16 09:44:40
|
The reason for may original post was for clarification regarding the intended behaviour and to suggest that the current behaviour is flawed. It may or may not be worth considering feature enhancements, but I think that the priority must be to ensure that the current behaviour is correct and documented. If the current behaviour with touching/overlapping regions is intended and is to be retained, then it needs to be in the manual (at present it isn't). I suggest that the behaviour for the "split" options is unintuitive because splits will occur for each label position if they do not touch or overlap, even if they are separated by as little as one sample period, but as soon as they touch the behaviour changes with no persuasive or obvious reason for why it should change. The reason that I think that it is not the current behaviour is not the most useful behaviour is because of an actual user case: I was wanting to split a long recording into individual clips, so I marked each song with a region label, selected "All" (Ctrl+A) and applied "Region Labels > Split". I expected that "Region Labels > Split" would "split at region labels" and was surprised that it did not do so. The function is called "Labelled Regions" (plural) so I would expect it to operate on multiple labelled regions, not on one concatenated region. On 16 September 2012 00:03, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Sat, 15 Sep 2012 22:54:56 +0100 > | Subject: [Audacity-quality] Edit > Labelled regions >> The behaviour that I would expect (and consider most useful), taking >> as an example: >> >> 10 seconds of audio (0 to 10 seconds) >> >> Labels at: >> 2 seconds to 3 seconds >> 3 seconds to 5 seconds >> 5 seconds to 8 seconds >> >> Audio track and label track selected from 0 seconds to 10 second. >> >> Labelled regions > Cut >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. >> Pasted audio is one audio clip of 6 seconds duration > > This happens now (and of course the selection length is irrelevant > as long as it touches labels one and three). > > I note Cut and Delete are incompatible with Sync-Locked Tracks, > I guess this was one of the things we wanted to fix? > > >> Same as selecting and cutting 2 to 8 seconds. > > That's my point. How much easier it would be if you could select > multiple labels (for example, with the keyboard, TAB into the first > label, then CTRL + TAB to add the following labels to the selection). > > >> Labelled regions > Delete >> 2 seconds to 8 seconds is deleted but not saved to the clipboard so >> cannot be pasted into an audio track. >> Same as selecting from 2 to 8 seconds and deleting. >> >> >> Labelled regions > Split Cut >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. >> A gap (white space) remains from 2 to 8 seconds. >> Pasted audio is 6 seconds total duration as 3 audio clips of durations >> 1, 2 and 3 seconds. >> >> >> Labelled regions > Split Delete >> 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. >> Audio not saved to clipboard. >> >> >> Labelled regions > Silence Audio >> 2 to 8 seconds is made silence. No splits. > > But this happens now. And I agree "no splits" is the most useful > case. > > >> (Do we need an option "Labelled regions > Split and Silence"? >> I don't think so.) > > I don't think so either (or if we do, we need "Split and *" for all > the Labeled Regions commands). > > >> Labelled regions > Copy >> 2 seconds to 8 seconds is copied and may be pasted into an audio track. >> Same as selecting and copying 2 to 8 seconds. >> Pasted audio is one clip of 6 seconds duration >> >> >> 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. > > >> Practical note: any unwanted splits can be easily and quickly rejoined >> by clicking on them. > > That is difficult for visually impaired users as screen readers > do not identify clips. That sounds like a 'hypothetical' objection. Is there an actual user case where a visually impaired user would want to split only the outside pair of a series of touching or overlapping regions and not be able to simply select the region that they want to split. > > >> 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. "Labelled Regions > Split Delete" is probably not operating internally on each labelled region, but from a user perspective this makes no difference. Steve > > > Thanks, > > > 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. > > > ------------------------------------------------------------------------------ > How fast is your code? > 3 out of 4 devs don\\\'t know how their code performs in production. > Find out how slow your code is with AppDynamics Lite. > http://ad.doubleclick.net/clk;262219672;13503038;z? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2012-09-16 22:06:50
|
| From Steve the Fiddle <ste...@gm...> | Sun, 16 Sep 2012 10:44:33 +0100 | Subject: [Audacity-quality] Edit > Labelled regions > The reason for may original post was for clarification regarding the > intended behaviour and to suggest that the current behaviour is > flawed. It may or may not be worth considering feature enhancements, > but I think that the priority must be to ensure that the current > behaviour is correct and documented. > > If the current behaviour with touching/overlapping regions is > intended and is to be retained, then it needs to be in the manual (at > present it isn't). I added a ToDo-2 (waiting for the server to reconnect to MySQL). It would also be better if http://manual.audacityteam.org/man/Edit_Menu#labeled had images of multiple labels being affected. Unfortunately the images need to be done by Bill really, otherwise the exact drop shadow settings in whatever image tool he is using have to be faked for every image. Added a ToDo. > I suggest that the behaviour for the "split" options is unintuitive > because splits will occur for each label position if they do not touch > or overlap, even if they are separated by as little as one sample > period, but as soon as they touch the behaviour changes with no > persuasive or obvious reason for why it should change. It depends how you think about it. The Labeled Region function for silence, for example, treats the three joined labels as one. > The reason that I think that it is not the current behaviour is not > the most useful behaviour is because of an actual user case: > > I was wanting to split a long recording into individual clips, so I > marked each song with a region label, selected "All" (Ctrl+A) and > applied "Region Labels > Split". That assumes you wanted labels as well. If you didn't, it would be simpler to just use CTRL + I instead of CTRL + B. >I expected that "Region Labels > > Split" would "split at region labels" and was surprised that it did > not do so. The function is called "Labelled Regions" (plural) so I > would expect it to operate on multiple labelled regions, not on one > concatenated region. In many cases such as a long recording from cassette or CD, user would not want the region labels touching. If you had a number of groups of concatenated labels, plural would still be appropriate. See below. > On 16 September 2012 00:03, Gale Andrews <ga...@au...> wrote: > > > > | From Steve the Fiddle <ste...@gm...> > > | Sat, 15 Sep 2012 22:54:56 +0100 > > | Subject: [Audacity-quality] Edit > Labelled regions > >> The behaviour that I would expect (and consider most useful), taking > >> as an example: > >> > >> 10 seconds of audio (0 to 10 seconds) > >> > >> Labels at: > >> 2 seconds to 3 seconds > >> 3 seconds to 5 seconds > >> 5 seconds to 8 seconds > >> > >> Audio track and label track selected from 0 seconds to 10 second. > >> > >> Labelled regions > Cut > >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. > >> Pasted audio is one audio clip of 6 seconds duration > > > > This happens now (and of course the selection length is irrelevant > > as long as it touches labels one and three). > > > > I note Cut and Delete are incompatible with Sync-Locked Tracks, > > I guess this was one of the things we wanted to fix? > > > > > >> Same as selecting and cutting 2 to 8 seconds. > > > > That's my point. How much easier it would be if you could select > > multiple labels (for example, with the keyboard, TAB into the first > > label, then CTRL + TAB to add the following labels to the selection). > > > > > >> Labelled regions > Delete > >> 2 seconds to 8 seconds is deleted but not saved to the clipboard so > >> cannot be pasted into an audio track. > >> Same as selecting from 2 to 8 seconds and deleting. > >> > >> > >> Labelled regions > Split Cut > >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. > >> A gap (white space) remains from 2 to 8 seconds. > >> Pasted audio is 6 seconds total duration as 3 audio clips of durations > >> 1, 2 and 3 seconds. > >> > >> > >> Labelled regions > Split Delete > >> 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. > >> Audio not saved to clipboard. > >> > >> > >> Labelled regions > Silence Audio > >> 2 to 8 seconds is made silence. No splits. > > > > But this happens now. And I agree "no splits" is the most useful > > case. > > > > > >> (Do we need an option "Labelled regions > Split and Silence"? > >> I don't think so.) > > > > I don't think so either (or if we do, we need "Split and *" for all > > the Labeled Regions commands). > > > > > >> Labelled regions > Copy > >> 2 seconds to 8 seconds is copied and may be pasted into an audio track. > >> Same as selecting and copying 2 to 8 seconds. > >> Pasted audio is one clip of 6 seconds duration > >> > >> > >> 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. > >> 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. |
From: Steve t. F. <ste...@gm...> - 2012-09-17 13:42:39
|
On 16 September 2012 23:06, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Sun, 16 Sep 2012 10:44:33 +0100 > | Subject: [Audacity-quality] Edit > Labelled regions >> The reason for may original post was for clarification regarding the >> intended behaviour and to suggest that the current behaviour is >> flawed. It may or may not be worth considering feature enhancements, >> but I think that the priority must be to ensure that the current >> behaviour is correct and documented. >> >> If the current behaviour with touching/overlapping regions is >> intended and is to be retained, then it needs to be in the manual (at >> present it isn't). > > I added a ToDo-2 (waiting for the server to reconnect to MySQL). > > It would also be better if > http://manual.audacityteam.org/man/Edit_Menu#labeled > > had images of multiple labels being affected. > > Unfortunately the images need to be done by Bill really, otherwise > the exact drop shadow settings in whatever image tool he is using > have to be faked for every image. Added a ToDo. > > >> I suggest that the behaviour for the "split" options is unintuitive >> because splits will occur for each label position if they do not touch >> or overlap, even if they are separated by as little as one sample >> period, but as soon as they touch the behaviour changes with no >> persuasive or obvious reason for why it should change. > > It depends how you think about it. The Labeled Region function > for silence, for example, treats the three joined labels as one. Whether "Labelled Regions > Silence" acts on one label at a time, or treats all touching/overlapping labelled regions as one will make no visible difference for users. The end result in either case is that the entire region is silent. If the option was "Split and Silence" (which it isn't) then there would be a visible difference and I would argue that each of the regions should be split. > > >> The reason that I think that it is not the current behaviour is not >> the most useful behaviour is because of an actual user case: >> >> I was wanting to split a long recording into individual clips, so I >> marked each song with a region label, selected "All" (Ctrl+A) and >> applied "Region Labels > Split". > > That assumes you wanted labels as well. If you didn't, it would be > simpler to just use CTRL + I instead of CTRL + B. I did want the labels as well - they had the song names typed in them. > > >>I expected that "Region Labels > >> Split" would "split at region labels" and was surprised that it did >> not do so. The function is called "Labelled Regions" (plural) so I >> would expect it to operate on multiple labelled regions, not on one >> concatenated region. > > In many cases such as a long recording from cassette or CD, user > would not want the region labels touching. A user *may* not want the region labels touching. It depends whether they want to keep the inter-track spaces or not. If they are just shuffling the track order then they probably will want to keep the spaces. Either way that is not a reason to "merge" the labels for the purposes of "Labelled Regions > operation". > > If you had a number of groups of concatenated labels, plural would > still be appropriate. > > See below. > > >> On 16 September 2012 00:03, Gale Andrews <ga...@au...> wrote: >> > >> > | From Steve the Fiddle <ste...@gm...> >> > | Sat, 15 Sep 2012 22:54:56 +0100 >> > | Subject: [Audacity-quality] Edit > Labelled regions >> >> The behaviour that I would expect (and consider most useful), taking >> >> as an example: >> >> >> >> 10 seconds of audio (0 to 10 seconds) >> >> >> >> Labels at: >> >> 2 seconds to 3 seconds >> >> 3 seconds to 5 seconds >> >> 5 seconds to 8 seconds >> >> >> >> Audio track and label track selected from 0 seconds to 10 second. >> >> >> >> Labelled regions > Cut >> >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. >> >> Pasted audio is one audio clip of 6 seconds duration >> > >> > This happens now (and of course the selection length is irrelevant >> > as long as it touches labels one and three). >> > >> > I note Cut and Delete are incompatible with Sync-Locked Tracks, >> > I guess this was one of the things we wanted to fix? >> > >> > >> >> Same as selecting and cutting 2 to 8 seconds. >> > >> > That's my point. How much easier it would be if you could select >> > multiple labels (for example, with the keyboard, TAB into the first >> > label, then CTRL + TAB to add the following labels to the selection). >> > >> > >> >> Labelled regions > Delete >> >> 2 seconds to 8 seconds is deleted but not saved to the clipboard so >> >> cannot be pasted into an audio track. >> >> Same as selecting from 2 to 8 seconds and deleting. >> >> >> >> >> >> Labelled regions > Split Cut >> >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. >> >> A gap (white space) remains from 2 to 8 seconds. >> >> Pasted audio is 6 seconds total duration as 3 audio clips of durations >> >> 1, 2 and 3 seconds. >> >> >> >> >> >> Labelled regions > Split Delete >> >> 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. >> >> Audio not saved to clipboard. >> >> >> >> >> >> Labelled regions > Silence Audio >> >> 2 to 8 seconds is made silence. No splits. >> > >> > But this happens now. And I agree "no splits" is the most useful >> > case. >> > >> > >> >> (Do we need an option "Labelled regions > Split and Silence"? >> >> I don't think so.) >> > >> > I don't think so either (or if we do, we need "Split and *" for all >> > the Labeled Regions commands). >> > >> > >> >> Labelled regions > Copy >> >> 2 seconds to 8 seconds is copied and may be pasted into an audio track. >> >> Same as selecting and copying 2 to 8 seconds. >> >> Pasted audio is one clip of 6 seconds duration >> >> >> >> >> >> 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? 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? Steve > > >> >> 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. > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2012-09-17 16:42:17
|
| From Steve the Fiddle <ste...@gm...> | Mon, 17 Sep 2012 14:42:31 +0100 | Subject: [Audacity-quality] Edit > Labelled regions > On 16 September 2012 23:06, Gale Andrews <ga...@au...> wrote: > > > > | From Steve the Fiddle <ste...@gm...> > > | Sun, 16 Sep 2012 10:44:33 +0100 > > | Subject: [Audacity-quality] Edit > Labelled regions > >> The reason for may original post was for clarification regarding the > >> intended behaviour and to suggest that the current behaviour is > >> flawed. It may or may not be worth considering feature enhancements, > >> but I think that the priority must be to ensure that the current > >> behaviour is correct and documented. > >> > >> If the current behaviour with touching/overlapping regions is > >> intended and is to be retained, then it needs to be in the manual (at > >> present it isn't). > > > > I added a ToDo-2 (waiting for the server to reconnect to MySQL). > > > > It would also be better if > > http://manual.audacityteam.org/man/Edit_Menu#labeled > > > > had images of multiple labels being affected. > > > > Unfortunately the images need to be done by Bill really, otherwise > > the exact drop shadow settings in whatever image tool he is using > > have to be faked for every image. Added a ToDo. > > > > > >> I suggest that the behaviour for the "split" options is unintuitive > >> because splits will occur for each label position if they do not touch > >> or overlap, even if they are separated by as little as one sample > >> period, but as soon as they touch the behaviour changes with no > >> persuasive or obvious reason for why it should change. > > > > It depends how you think about it. The Labeled Region function > > for silence, for example, treats the three joined labels as one. > > Whether "Labelled Regions > Silence" acts on one label at a time, or > treats all touching/overlapping labelled regions as one will make no > visible difference for users. But it could create an expectation that Split also acts on a group of touching/overlapped labeled regions rather than each region. That was my assumption before all this started. > >> The reason that I think that it is not the current behaviour is not > >> the most useful behaviour is because of an actual user case: > >> > >> I was wanting to split a long recording into individual clips, so I > >> marked each song with a region label, selected "All" (Ctrl+A) and > >> applied "Region Labels > Split". > > > > That assumes you wanted labels as well. If you didn't, it would be > > simpler to just use CTRL + I instead of CTRL + B. > > I did want the labels as well - they had the song names typed in them. Then that is a "use case"! > >>I expected that "Region Labels > > >> Split" would "split at region labels" and was surprised that it did > >> not do so. The function is called "Labelled Regions" (plural) so I > >> would expect it to operate on multiple labelled regions, not on one > >> concatenated region. > > > > In many cases such as a long recording from cassette or CD, user > > would not want the region labels touching. > > A user *may* not want the region labels touching. It depends whether > they want to keep the inter-track spaces or not. If they are just > shuffling the track order then they probably will want to keep the > spaces. Either way that is not a reason to "merge" the labels for the > purposes of "Labelled Regions > operation". It's a reason to suggest the use case you came up with may not be common. See below. > > If you had a number of groups of concatenated labels, plural would > > still be appropriate. > > > > See below. > > > > > >> On 16 September 2012 00:03, Gale Andrews <ga...@au...> wrote: > >> > > >> > | From Steve the Fiddle <ste...@gm...> > >> > | Sat, 15 Sep 2012 22:54:56 +0100 > >> > | Subject: [Audacity-quality] Edit > Labelled regions > >> >> The behaviour that I would expect (and consider most useful), taking > >> >> as an example: > >> >> > >> >> 10 seconds of audio (0 to 10 seconds) > >> >> > >> >> Labels at: > >> >> 2 seconds to 3 seconds > >> >> 3 seconds to 5 seconds > >> >> 5 seconds to 8 seconds > >> >> > >> >> Audio track and label track selected from 0 seconds to 10 second. > >> >> > >> >> Labelled regions > Cut > >> >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. > >> >> Pasted audio is one audio clip of 6 seconds duration > >> > > >> > This happens now (and of course the selection length is irrelevant > >> > as long as it touches labels one and three). > >> > > >> > I note Cut and Delete are incompatible with Sync-Locked Tracks, > >> > I guess this was one of the things we wanted to fix? > >> > > >> > > >> >> Same as selecting and cutting 2 to 8 seconds. > >> > > >> > That's my point. How much easier it would be if you could select > >> > multiple labels (for example, with the keyboard, TAB into the first > >> > label, then CTRL + TAB to add the following labels to the selection). > >> > > >> > > >> >> Labelled regions > Delete > >> >> 2 seconds to 8 seconds is deleted but not saved to the clipboard so > >> >> cannot be pasted into an audio track. > >> >> Same as selecting from 2 to 8 seconds and deleting. > >> >> > >> >> > >> >> Labelled regions > Split Cut > >> >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. > >> >> A gap (white space) remains from 2 to 8 seconds. > >> >> Pasted audio is 6 seconds total duration as 3 audio clips of durations > >> >> 1, 2 and 3 seconds. > >> >> > >> >> > >> >> Labelled regions > Split Delete > >> >> 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. > >> >> Audio not saved to clipboard. > >> >> > >> >> > >> >> Labelled regions > Silence Audio > >> >> 2 to 8 seconds is made silence. No splits. > >> > > >> > But this happens now. And I agree "no splits" is the most useful > >> > case. > >> > > >> > > >> >> (Do we need an option "Labelled regions > Split and Silence"? > >> >> I don't think so.) > >> > > >> > I don't think so either (or if we do, we need "Split and *" for all > >> > the Labeled Regions commands). > >> > > >> > > >> >> Labelled regions > Copy > >> >> 2 seconds to 8 seconds is copied and may be pasted into an audio track. > >> >> Same as selecting and copying 2 to 8 seconds. > >> >> Pasted audio is one clip of 6 seconds duration > >> >> > >> >> > >> >> 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 You can study the original patch there, but I have no idea if Arun is still contactable. > 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 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. |
From: Steve t. F. <ste...@gm...> - 2012-09-17 22:37:38
|
On 17 September 2012 17:42, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Mon, 17 Sep 2012 14:42:31 +0100 > | Subject: [Audacity-quality] Edit > Labelled regions >> On 16 September 2012 23:06, Gale Andrews <ga...@au...> wrote: >> > >> > | From Steve the Fiddle <ste...@gm...> >> > | Sun, 16 Sep 2012 10:44:33 +0100 >> > | Subject: [Audacity-quality] Edit > Labelled regions >> >> The reason for may original post was for clarification regarding the >> >> intended behaviour and to suggest that the current behaviour is >> >> flawed. It may or may not be worth considering feature enhancements, >> >> but I think that the priority must be to ensure that the current >> >> behaviour is correct and documented. >> >> >> >> If the current behaviour with touching/overlapping regions is >> >> intended and is to be retained, then it needs to be in the manual (at >> >> present it isn't). >> > >> > I added a ToDo-2 (waiting for the server to reconnect to MySQL). >> > >> > It would also be better if >> > http://manual.audacityteam.org/man/Edit_Menu#labeled >> > >> > had images of multiple labels being affected. >> > >> > Unfortunately the images need to be done by Bill really, otherwise >> > the exact drop shadow settings in whatever image tool he is using >> > have to be faked for every image. Added a ToDo. >> > >> > >> >> I suggest that the behaviour for the "split" options is unintuitive >> >> because splits will occur for each label position if they do not touch >> >> or overlap, even if they are separated by as little as one sample >> >> period, but as soon as they touch the behaviour changes with no >> >> persuasive or obvious reason for why it should change. >> > >> > It depends how you think about it. The Labeled Region function >> > for silence, for example, treats the three joined labels as one. >> >> Whether "Labelled Regions > Silence" acts on one label at a time, or >> treats all touching/overlapping labelled regions as one will make no >> visible difference for users. > > But it could create an expectation that Split also acts on a group > of touching/overlapped labeled regions rather than each region. > > That was my assumption before all this started. > > >> >> The reason that I think that it is not the current behaviour is not >> >> the most useful behaviour is because of an actual user case: >> >> >> >> I was wanting to split a long recording into individual clips, so I >> >> marked each song with a region label, selected "All" (Ctrl+A) and >> >> applied "Region Labels > Split". >> > >> > That assumes you wanted labels as well. If you didn't, it would be >> > simpler to just use CTRL + I instead of CTRL + B. >> >> I did want the labels as well - they had the song names typed in them. > > Then that is a "use case"! > > >> >>I expected that "Region Labels > >> >> Split" would "split at region labels" and was surprised that it did >> >> not do so. The function is called "Labelled Regions" (plural) so I >> >> would expect it to operate on multiple labelled regions, not on one >> >> concatenated region. >> > >> > In many cases such as a long recording from cassette or CD, user >> > would not want the region labels touching. >> >> A user *may* not want the region labels touching. It depends whether >> they want to keep the inter-track spaces or not. If they are just >> shuffling the track order then they probably will want to keep the >> spaces. Either way that is not a reason to "merge" the labels for the >> purposes of "Labelled Regions > operation". > > It's a reason to suggest the use case you came up with may not > be common. > > See below. > >> > If you had a number of groups of concatenated labels, plural would >> > still be appropriate. >> > >> > See below. >> > >> > >> >> On 16 September 2012 00:03, Gale Andrews <ga...@au...> wrote: >> >> > >> >> > | From Steve the Fiddle <ste...@gm...> >> >> > | Sat, 15 Sep 2012 22:54:56 +0100 >> >> > | Subject: [Audacity-quality] Edit > Labelled regions >> >> >> The behaviour that I would expect (and consider most useful), taking >> >> >> as an example: >> >> >> >> >> >> 10 seconds of audio (0 to 10 seconds) >> >> >> >> >> >> Labels at: >> >> >> 2 seconds to 3 seconds >> >> >> 3 seconds to 5 seconds >> >> >> 5 seconds to 8 seconds >> >> >> >> >> >> Audio track and label track selected from 0 seconds to 10 second. >> >> >> >> >> >> Labelled regions > Cut >> >> >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. >> >> >> Pasted audio is one audio clip of 6 seconds duration >> >> > >> >> > This happens now (and of course the selection length is irrelevant >> >> > as long as it touches labels one and three). >> >> > >> >> > I note Cut and Delete are incompatible with Sync-Locked Tracks, >> >> > I guess this was one of the things we wanted to fix? >> >> > >> >> > >> >> >> Same as selecting and cutting 2 to 8 seconds. >> >> > >> >> > That's my point. How much easier it would be if you could select >> >> > multiple labels (for example, with the keyboard, TAB into the first >> >> > label, then CTRL + TAB to add the following labels to the selection). >> >> > >> >> > >> >> >> Labelled regions > Delete >> >> >> 2 seconds to 8 seconds is deleted but not saved to the clipboard so >> >> >> cannot be pasted into an audio track. >> >> >> Same as selecting from 2 to 8 seconds and deleting. >> >> >> >> >> >> >> >> >> Labelled regions > Split Cut >> >> >> 2 seconds to 8 seconds is cut and may be pasted into an audio track. >> >> >> A gap (white space) remains from 2 to 8 seconds. >> >> >> Pasted audio is 6 seconds total duration as 3 audio clips of durations >> >> >> 1, 2 and 3 seconds. >> >> >> >> >> >> >> >> >> Labelled regions > Split Delete >> >> >> 2 seconds to 8 seconds is cut leaving a gap (white space) from 2 to 8 seconds. >> >> >> Audio not saved to clipboard. >> >> >> >> >> >> >> >> >> Labelled regions > Silence Audio >> >> >> 2 to 8 seconds is made silence. No splits. >> >> > >> >> > But this happens now. And I agree "no splits" is the most useful >> >> > case. >> >> > >> >> > >> >> >> (Do we need an option "Labelled regions > Split and Silence"? >> >> >> I don't think so.) >> >> > >> >> > I don't think so either (or if we do, we need "Split and *" for all >> >> > the Labeled Regions commands). >> >> > >> >> > >> >> >> Labelled regions > Copy >> >> >> 2 seconds to 8 seconds is copied and may be pasted into an audio track. >> >> >> Same as selecting and copying 2 to 8 seconds. >> >> >> Pasted audio is one clip of 6 seconds duration >> >> >> >> >> >> >> >> >> 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 study the original patch there, but I have no idea if Arun > is still contactable. He doesn't appear to have been active in the last 6 years as far as I can tell. > > >> 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 > > 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. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2012-09-17 23:36:48
|
| 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 ? > >> 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? 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. |
From: Steve t. F. <ste...@gm...> - 2012-09-18 01:05:22
|
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. > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Gale A. <ga...@au...> - 2012-11-18 01:14:40
|
| 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. |
From: Steve t. F. <ste...@gm...> - 2012-11-18 17:07:19
|
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 |
From: Gale A. <ga...@au...> - 2012-11-18 18:51:05
|
| From Steve the Fiddle <ste...@gm...> | Sun, 18 Nov 2012 17:07:11 +0000 | Subject: [Audacity-quality] [Audacity-devel] Edit > Labelled regions > 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 [just to -quality] Unless someone wants otherwise, I suggest continuing on the Forum (where we already have a topic where I had replied in more detail). If there are broader issues which labeled regions are a part of, it might need a Wiki Proposal. Yes overlapping labels is one of the "inconsistent behaviours" I had in mind. Gale > 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 |
From: Steve t. F. <ste...@gm...> - 2012-11-21 19:47:06
Attachments:
labelled-regions-split-2.patch
|
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 |
From: Gale A. <ga...@au...> - 2012-11-21 21:11:17
|
| From Steve the Fiddle <ste...@gm...> | Wed, 21 Nov 2012 19:46:58 +0000 | Subject: [Audacity-quality] [Audacity-devel] Edit > Labelled regions >[...] Unless/until there is another option on the table to consider, I think > this change should be implemented. There is another option on the table (proposed by me in the Forum topic) which is a Labeled Regions preference to "treat joined or overlapped labels as one label". This would be fairly analogous to the recently added "Retain labels" Interface preference where there were conflicting use cases to support. For fairly easy access, it could be in the Labeled Regions menus as a checkable menu item, rather than a preference. It could then also have a shortcut. > All labelled regions are treated separately unless overlapping. This still seems messy for the currently supported use cases of treating joined labels as one. Under your previous idea I could make an extra label track to do what I really wanted to do. What about the label track proliferation for people who work with lots of label tracks? I haven't tried your patch yet to see which of the current "inconsistencies" may be resolved. I'm just pointing out that there is another option to consider. I'm not sure if that option would require "great lengths", but I am guessing not. Gale > 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. |
From: Steve t. F. <ste...@gm...> - 2012-11-21 21:54:29
|
On 21 November 2012 21:10, Gale Andrews <ga...@au...> wrote: > > | From Steve the Fiddle <ste...@gm...> > | Wed, 21 Nov 2012 19:46:58 +0000 > | Subject: [Audacity-quality] [Audacity-devel] Edit > Labelled regions >>[...] Unless/until there is another option on the table to consider, I think >> this change should be implemented. > > There is another option on the table (proposed by me in the Forum > topic) which is a Labeled Regions preference to "treat joined or > overlapped labels as one label". > > This would be fairly analogous to the recently added "Retain labels" > Interface preference where there were conflicting use cases to > support. > > For fairly easy access, it could be in the Labeled Regions menus as a > checkable menu item, rather than a preference. It could then also > have a shortcut. I agree that is another possibility, but I prefer treating labelled regions independently unless overlapping as a solution: 1) It is more powerful and flexible in that users may choose which labelled regions they want to be linked and which to not be linked (whereas a menu option would be "all or none") 2) The code change is already available and I've tried, tested and like it. (a bird in the hand :=) 3) With the alternative proposal of a menu choice, we would still need to decide exactly how to deal with touching and overlapping regions. We have discovered that there is a problem in treating overlapping regions on a one-by-one basis, so we would probably end up with the behaviour that I am proposing as one choice, and the current pre-patched behaviour as the other choice. 4) My patch does not exclude the possibility of a menu choice. There could still be a menu choice between the patched behaviour and the current pre-patched behaviour if it were thought necessary. > > >> All labelled regions are treated separately unless overlapping. > > This still seems messy for the currently supported use cases of > treating joined labels as one. Under your previous idea I could > make an extra label track to do what I really wanted to do. What > about the label track proliferation for people who work with lots > of label tracks? This is about the (hypothetical?) case of someone that labels each word in a voice recording with adjoining region labels, but leaves gaps between sentences so that they can split the sentences and not the words? The thing that strikes me about that user case, is why would anyone actually do that? I don't see that anyone would expect that to work, so it seems more like a fortuitous accident that is beneficial in one fringe case. There are several ways that this user case could still work with the proposed patch: 1) The user can "link" sentences or phrases (or any combination of words, sentences and phrases) by adding a label (to the same or another label track) that links the words/phrases that they want to link. 2) I'm not sure why in this user case they made the word labels touch - they probably did not need to do that. 3) If they only want to split sentences, then they could use one label for the whole sentence. With this user case, the user currently needs to remember to ensure that each word label is touching the next word label, but that the labels do not touch between sentences. With the proposed patch they do not need to remember to do that as labels are treated the same whether touching or not. The "one" exception is that overlapping labels are treated as one continuous labelled region (and this is an easy to document design feature not an accident). > > I haven't tried your patch yet to see which of the current > "inconsistencies" may be resolved. I'm just pointing out that > there is another option to consider. I'm not sure if that option > would require "great lengths", but I am guessing not. > Is there a reason why we cannot implement the current patch now and add a choice later if it proves to be necessary? Steve > > > > > Gale > > > >> 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 |
From: Gale A. <ga...@au...> - 2012-11-28 05:06:13
|
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. 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. 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. 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? 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 |
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 > |
From: James C. <cr...@in...> - 2012-09-16 13:47:45
|
On 15/09/2012 20:24, Gale Andrews 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. Assume I am being obtuse, because it probably is the case. I think the wires got crossed somewhere, and we're (probably) both agreeing in general terms. As a general rule we shouldn't have every possible combination of option as a menu item with a single step - e.g. we don't offer "apply echo effect and put result in a new track" as a single step menu item. I have a feeling we might be heading in that direction with silence and clips and all that, which is why I said anything at all. I'm dropping out of this conversation here as I am not sure exactly what is being talked about. I trust the group process to do the right thing without me. --James. |
From: Gale A. <ga...@au...> - 2012-09-16 17:50:03
|
| From James Crook <cr...@in...> | Sun, 16 Sep 2012 14:47:35 +0100 | Subject: [Audacity-quality] Edit > Labelled regions > On 15/09/2012 20:24, Gale Andrews 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. > Assume I am being obtuse, because it probably is the case. I think the > wires got crossed somewhere, and we're (probably) both agreeing in > general terms. > > As a general rule we shouldn't have every possible combination of option > as a menu item with a single step - e.g. we don't offer "apply echo > effect and put result in a new track" as a single step menu item. I > have a feeling we might be heading in that direction with silence and > clips and all that, which is why I said anything at all. Thanks, James. I (think) we are agreeing in general terms. A menu proliferation problem is what I had in mind when I said Labeled Regions couldn't do anything else for silencing than they do now. Gale > I'm dropping out of this conversation here as I am not sure exactly what > is being talked about. I trust the group process to do the right thing > without me. > > --James. |