Regular Interval Region Labels

[steve]

Are these use cases smallish numbers?

There are not that many mentions of Regular Interval Labels at all, though I did note one comment that one user was surprised when he was shown it in the Analyze menu, saying that he had not looked there and did not see what it had to do with "analyzing".

I wouldn't remove that. I know people who use that for a special purpose such as the first few files are lead-ins of some sort, indicated by a negative number in the file name.

That was my reasoning for adding that feature initially, but since then I've not heard of anyone using it and I've never used it myself either, so it is not currently included in the new version.
Do I take that to be a request for adding it back in?

Feature request: Split at closest silence.[...] would be better handled in an "advanced sound finder" plug-in rather than in "Regular Interval Labels".

I'm inclined to agree - though it shows again that some people want some kind of combination of silence splitting and equalized length.

OK, so that is on the agenda for "advanced silence finder".

If we wanted choice of separator irrespective of locale I think we'd have to offer it for all effects, shipped or not.

If we ever get version 4 plug-ins then the question should become irrelevant. The only reason that we use text widgets for numeric input is as a workaround for the limitations of the currently available widgets.

So is your latest attachment the one you are now promoting, Steve?

The way that I would put it is that this version is the best that I can currently come up with (with the possible exception of supporting a negative initial number). There are good use cases for every feature in it and I've avoided adding features for which there is no currently known use case.

With the exception of the interval duration, the defaults are the same as for the currently shipped version.

[Gale Andrews]

Are these use cases smallish numbers?

There are not that many mentions of Regular Interval Labels at all, though I did note one comment that one user was surprised when he was shown it in the Analyze menu, saying that he had not looked there and did not see what it had to do with "analyzing".

That relates to my post to -quality about the [email protected] user who could not find how to split at silences. He was expecting it in a "Tools" menu.

I wouldn't remove that. I know people who use that for a special purpose such as the first few files are lead-ins of some sort, indicated by a negative number in the file name.

That was my reasoning for adding that feature initially, but since then I've not heard of anyone using it and I've never used it myself either, so it is not currently included in the new version.
Do I take that to be a request for adding it back in?

I think the "final version" should let you number from a negative number to a positive. Does this user want to label -1, -2, -3, -4 and so on where "-" does not mean a minus sign?

Related to that, I've searched further my inbox and found a couple of people who don't like that adding a number to the label text forces consecutive numbering of the labels. They want a number in fixed text. Meeting that request would need another control, but I think that's a more valid request than disallowing counting from a negative number.

If we wanted choice of separator irrespective of locale I think we'd have to offer it for all effects, shipped or not.

If we ever get version 4 plug-ins then the question should become irrelevant. The only reason that we use text widgets for numeric input is as a workaround for the limitations of the currently available widgets.

So what would version 4 plug-ins use for numeric input? Some built-in effects use text input to enter a number.

So is your latest attachment the one you are now promoting, Steve?

The way that I would put it is that this version is the best that I can currently come up with.

Clearly there is a bug in the currently released version where you don't get the expected number of labels ( http://forum.audacityteam.org/viewtopic ... 86#p233086 ). It's good to see it fixed but my impressions having spent some time with your current effort is that this is quite close to "too complex" for release.

The current choice of placement by "Label interval" or "Number of labels" is worded intuitively. What your options do is tough to work out. User may ask "Is Fit number of labels" the same as the current "Number of labels"? Or may ask "Where is the option to "not fit number of labels" (whatever that might be) I find "fit" confusing.

According to the control "Final Label at:" we seem now to have the concept of always having a final label (rather than "adding" the final label). Yet when placement is by interval, changing from "Final label at start of interval" to "Final label at end of interval" still adds another label. That seems unintuitive to me.

But when we place by number of labels, "final label" means something else (the final label in a fixed number of labels). Changing from "Final label at start of interval" to "Final label at end of interval" moves the labels, and I need to ask for four labels to get three labels and an "extra" label (if I think of it as "extra").

Has anyone asked for options for "% of interval" and "alignment" for region labels? Unless I choose "Left align" (default) then with:
30 seconds tone
Seconds
Fit number of labels
End of interval
3 labels
Regions labels as time duration
Length of region label: 10

the first label is partly behind zero Should labels be allowed behind zero?

If I change the final label to "Start of interval" then labels 1, 2 and 3 attach. Maybe that's useful for some case, but how does the user figure out the options to produce that? This is the basic problem I think. User will find it hard to see what option produces what they want except by trial and error.

One of my mystery shoppers - an occasional user of Regular Interval Labels for internet uploads - said:

"Should not need a degree in math, good reason not to uprate"

He would need better option names and/or extremely user-friendly documentation with lots of example divs, I think.

I've not tested every combination of options or most error message as I have not wrapped my head fully round what the options do yet. I shall have to do that, looking at http://forum.audacityteam.org/viewtopic ... 01#p233801 . Is that documentation still valid?


Gale

[steve]

That relates to my post to -quality about the [email protected] user who could not find how to split at silences. He was expecting it in a "Tools" menu.

We agree about that

I think the "final version" should let you number from a negative number to a positive.

If the feature is being used then I'm happy to include it *hopefully not too difficult to code).

Of course it probably wont suit everyone, for example one person may want:
house-of-the-flying-daggers-01
house-of-the-flying-daggers-02
house-of-the-flying-daggers-03

and another may want:
time -1
time 0
time 1

and another may want:
Dallas Episode 2
Dallas Episode 2
Dallas Episode 2

and someone else might want:
10 minutes before impact
9 minutes before impact
8 minutes before impact

If we try to make all the people happy all of the time we will either need many more controls or some complex regex type syntax. (do you remember the business with "in_d*[13579]$ in_d*[02468]$" for getting ports to work reliably with jackd?). Either way it becomes so complex that no-one is happy.

So what would version 4 plug-ins use for numeric input?

Leland proposed a choice (more widget types): a slider widget (similar to now), or a "numeric text" widget (similar to the "Amplify" effect), or a "time widget" (like in built in generators). Also with greater freedom for where they are placed, so for example you could have 2 "numeric text" boxes on the same line.

but my impressions having spent some time with your current effort is that this is quite close to "too complex" for release.

I think that is a valid concern, though we are probably looking at the effect differently from how most users will.

For the majority of users there will probably be one type of job that they use it for.
For example, if they are just splitting a cassette recording into separate tracks for a CD, then they will probably only ever need to change the "interval" and the "label text" and leave everything else at the default settings. This is in stark contrast to testers and documenters that need to understand every feature.

It is the same as when considering Audacity as a whole. If you need to know and understand every single feature then Audacity is a very complex program. I think that taking a "task based" approach can help to make a complex thing more simple.

As another example, if you regularly need to split a recording into exact time segments, the "Exact Intervals" is THE feature that you need, It doesn't matter if you understand what "Maximum Interval" is. Of course that is the exact opposite of someone that regularly needs to split a recording into sections "no more than a set maximum size".

As I wrote previously, there are several contradictions that crop up between one type of use case and another. It would be much simpler if it could be split into two (or more) different plug-ins, though neither you or I are very keen to do that. The problem is exacerbated by the fact that we can't grey out "redundant" controls.

User may ask "Is Fit number of labels" the same as the current "Number of labels"? Or may ask "Where is the option to "not fit number of labels" (whatever that might be)

I agree that it is difficult to directly compare the new effect with the old, but the only way to completely avoid that is to make the new effect just as cock-eyed as the old one... and yes, what on Earth does "not fit number of labels" mean In the new design, the word "fit" is only used in relevant context.

According to the control "Final Label at:" we seem now to have the concept of always having a final label (

I would slightly reword that. We now have a concept of always having a final "interval" (which is in keeping with the name of the plug-in "Regular Interval Labels"). The last label is either at the start of that final interval, or at the end of that final interval. "Sometimes an extra label" no longer occurs.

In the shipped version, 4 of the 9 controls "sometimes" do something and "sometimes" don't. I've tried to get away from that paradigm.

Has anyone asked for options for "% of interval" and "alignment" for region labels

Yes. Me
For the type of thing that I would use regular interval labels for they are very useful features.

then with:
...
...
the first label is partly behind zero

Yes it is, but that is not how I would use it.

Lets say that we have a recording that has some unwanted "events" occurring at regular intervals (there was a recent example that you may recall, when we drifted off into a discussion about copyright and TOS). I would begin the selection on the middle of the first event, and end the selection on the middle of the final event. Then as long as choose either the right interval, or the right number of labels, I can neatly bracket each event within a region label. (massively quicker than any way of doing that before now).

Should labels be allowed behind zero?

No.
I can't think of any reasonable need for that, but also there are a number of problems that it could cause, such as creating "phantom" files with Export Multiple. Labels before zero would tend to get lost, be difficult to retrieve, and "invisible". I think we made the right decision to disallow labels before zero.
For region labels to extend before zero is probably not very useful, but does not have the problem of being completely hidden.

I've not tested every combination of options or most error message as I have not wrapped my head fully round what the options do yet.

I agree that is a problem. We are trying to cater for many diverse and in some ways contradictory needs, all within one plug-in. The plug-in could be simplified by disregarding some users and commenting out some features, or by splitting it into two plug-ins (as we have done with the sound and silence finders), but neither is ideal.

looking at viewtopic.php?p=233801#p233801 . Is that documentation still valid?

Yes. There is no change in those features, just more features added. If you leave the "region" at zero (point labels) then they behave identically (that version only has point labels).

[Gale Andrews]

I think the "final version" should let you number from a negative number to a positive.

If the feature is being used then I'm happy to include it *hopefully not too difficult to code).

Of course it probably wont suit everyone, for example one person may want:
and another may want:
and another may want:
Dallas Episode 2
Dallas Episode 2
Dallas Episode 2
and someone else might want:

It's hard to know when only small numbers of people comment, but I suggest two controls to manage the produced label text are probably reasonable. Even that is one control less than now.

I can see the argument that putting a number in the text shouldn't force ordering to occur. It doesn't in Export Multiple.

I think that taking a "task based" approach can help to make a complex thing more simple.

Yes but that is where the name we choose for the label placement methods is important and where it is IMO non-obvious that having chosen a label placement method, then the choice made in the "Final label at:" control may be directly relevant to the task too.

Really, the "Final label at:" control has taken more importance than the current "Adjust label interval" control, but that may not be obvious to users familiar with the current meaning of "Final label". I would rather use another term for "Final label" if we could, to make clear it is not the same as the current "final label".

User may ask "Is Fit number of labels" the same as the current "Number of labels"?

In the new design, the word "fit" is only used in relevant context.

If this choice is identical to that in the current effect as I believe then I think it is better to drop the word "fit". Since we agree "not fitting" makes little sense, adding "fit" sows confusion.

According to the control "Final Label at:" we seem now to have the concept of always having a final label

I would slightly reword that. We now have a concept of always having a final "interval" (which is in keeping with the name of the plug-in "Regular Interval Labels").

The control name implies there will always be a "final label" but it may not be clear what we mean by a "final" label given what it means now.

Some feedback from my other regular "shopper".

What does closest and maximum mean. If the intervals are <regular> how can they be other than exact? Is it the same kind of interval.

The last label is either at the start of that final interval, or at the end of that final interval. "Sometimes an extra label" no longer occurs.

When placement is by interval, changing from "Final label at start of interval" to "Final label at end of interval" does add "another" label that looks suspiciously like what the final label does now.

In the shipped version, 4 of the 9 controls "sometimes" do something and "sometimes" don't. I've tried to get away from that paradigm.

I somewhat agree but we also agree the new effect is more complex than the old, maybe to the point of being a concern.

In practice, controls sometimes applying and other times not doesn't seem to cause much user confusion. If this was C++ (or Nyquist where controls could grey) the behaviour could be part of the design.

Has anyone asked for options for "% of interval" and "alignment" for region labels

Yes. Me
For the type of thing that I would use regular interval labels for they are very useful features.

FWIW I almost suggested "% of interval" for region length, then thought it would not be used much.

What is the use case for the centre and left align differentiation ? My guess is that an extra control for label text production might be more widely useful than the region label alignment.

Lets say that we have a recording that has some unwanted "events" occurring at regular intervals (there was a recent example that you may recall, when we drifted off into a discussion about copyright and TOS). I would begin the selection on the middle of the first event, and end the selection on the middle of the final event. Then as long as choose either the right interval, or the right number of labels, I can neatly bracket each event within a region label. (massively quicker than any way of doing that before now).

+1 to at least one control for region labels.

But why select from the middle of the first and to middle of the last "unwelcome event"? I tried this with a 5 minute DTMF, assuming the tone was "unwelcome".


Gale

[steve]

It's hard to know when only small numbers of people comment

Indeed

but I suggest two controls to manage the produced label text are probably reasonable. Even that is one control less than now.

I'm not sure how that would work.
We could have one control for label text and one for label number, but where does the number go in relation to the text?

The new version is quite elegant, though it does not cover every possible variation, in that you can have:

text + number
number + text
text only
number only
text + number + text

all with just one control, and no special syntax.

If we have two controls, one for numbering and one for the text, then how do we specify where the text goes without adding another control?

If we want more functionality (ie. non-incrementing numbers), then one possibility would be to use a "magic character" to indicate a "counting number".
For example:

house-of-the-flying-daggers-01, where the number is incremented, enter:
house-of-the-flying-daggers-#01

where the "#" is not printed, but indicates that "01" should be incremented.

While this provides more functionality, and is not really hard to understand, it is not at all intuitive and requires looking in the manual.

[steve]

I would rather use another term for "Final label" if we could, to make clear it is not the same as the current "final label".

Such as?

[steve]

Re. "Fit number of labels"

If this choice is identical to that in the current effect as I believe then I think it is better to drop the word "fit". Since we agree "not fitting" makes little sense, adding "fit" sows confusion.

OK. That is a simple change.
"Fit number of labels" becomes "Number of labels".

[steve]

but it may not be clear what we mean by a "final" label given what it means now.

sadly my "rewriting history pen" has run out of ink.
I'd rather get it right now and for the future than worry about it conflicting with the past. The alternative is that we live with our mistakes forever and push those mistakes onto new and future users.

Some feedback from my other regular "shopper".

What does closest and maximum mean. If the intervals are <regular> how can they be other than exact? Is it the same kind of interval.

I'm not sure if you mean that rhetorically. I think I explained that quite clearly here: http://forum.audacityteam.org/viewtopic ... 01#p233801

As in the old version, "Fit closest interval" may give intervals larger or smaller than the size specified by the user (whichever is closest).
However, I imagine that there will be cases where the user wants the label intervals to be no more than a specified duration, for example if they want to fit a long recording on low capacity media (Anyone still use cassettes? More modern examples could include embedded systems or hardware samplers), or if they want to upload somewhere where there is a file size limit. In other words, the interval specified by the user is the maximum interval.

To cater for this case, an additional "Label placement method" option could be added: "Maximum interval".
In this case, the largest interval to fit the selection, less than the specified interval, will be used.

As an example, If the selection is 10 seconds and the specified interval is 3 seconds.
"Fit closest interval" will produce intervals of 3.333 seconds (the closest exact fit to 3 seconds)
"Maximum Interval" will produce intervals of 2.5 seconds (the largest exact fit less than 3 seconds)

[steve]

When placement is by interval, changing from "Final label at start of interval" to "Final label at end of interval" does add "another" label that looks suspiciously like what the final label does now.

On the other hand, if we forget about the problems with the old (currently shipped) version, then it makes sense. When the user specifies the number of labels then they (always) get the number of labels specified. When they specify the exact label interval then they (always) get the specified interval. When they specify the maximum interval that will fit then they (always) get the maximum interval that will fit.

I would love to be able to keep functionality and make it more simple, but this is the simplest, most consistent way of doing it that I have come up with. The only ways that I can think of simplifying the interface are to reduce the functionality, which then becomes a question of "what do we cut out?".

[steve]

But why select from the middle of the first and to middle of the last "unwelcome event"? I tried this with a 5 minute DTMF, assuming the tone was "unwelcome".

Yes that can work with DTMF tones, but that is a "special case" in that not only are the "unwelcome" sounds precisely placed, but they are all exactly the same length. If there is some variation in either the length or position of the events to be labelled, then we may want to "bracket" the events with a little allowance either side.