Updated Sound Finder

[steve]

I think that was the final decision but I think it was by fiat

Personally I think that in most situations 0.1 seconds is a reasonable minimum. With smaller values the user may run into problems such as huge numbers of labels and confusion over rounding errors. In what I would expect to be an unusual case, where the user does want to use a smaller value, then they are able to by using text entry. On the whole I'm in favour of 0.1 being the minimum value for the slider.

One problem(/feature??) with the current implementation is that the user can enter high-precision values but they are ignored by a subsequent relaunch of the SF

That is an inevitable consequence of the minimum slider value. If the last used value is outside of the slider range, then on next launch the control will "reset" to the closest slider value.

Although less noticeable the same effect applies to all sliders in all Nyquist plug-ins. For example in Sound Finder, it is possible to enter negative values for the label start/end points. Negative values are valid and may be entered by typing, but the sliders have a range of 0.0 to 1.0, so if a negative value is used, then on next launch the value will revert to 0.0.

So if everyone is happy with this, I'll update Silence Finder in similar fashion.
Is everyone happy?

[Gale Andrews]

I didn't have any errors with the new Sound Finder 23-Sept-10 (can we standardise on months having three character abbreviations)?

Did we decide that we wanted the plug-in to be capable of finer precision, but that the GUI would still have a minimum silence setting of 0.1 seconds?

Yes that was my understanding. Fewer people would be annoyed by having to enter fine values (even every single time) than would be annoyed by hitting HOME and having to arrow right to 0.1.

though I change the text string of the generated label

Do we want that as a feature? As this is now a version 3 plug-in we could have a text input box for a custom label, or label prefix, though we must already be close to the max GUI size for an 800 x 600 display.

I think it's very much worth doing, and I quite like the way Regular Interval Labels does it. If the label text box is empty the number only is produced; if the label text box has text, the text is appended to the number. In line with what Export Multiple now does if you choose a "numbering" option to name the files, I think the numbering should be double digit - "01", "02" etc. for no label text and "01-label text", "02-label text" etc. for label text.

Consistency would be good generally with similar labelling plug-ins. If we prefer that Sound Finder numbers tracks, then I think Silence Finder should do so instead of giving all tracks "S", then the numbering makes more sense if we add the option of label text there too.

Also on consistency I notice the Sound Finder threshold unit is now [dB] so user has to enter the - for a negative value instead of just the number. I think this is reasonable. It's in line with AutoDuck, and out of line with Normalize but people say we should fix that because you get clipping if you actually enter a negative value. Make Silence Finder do the same, obviously.

As for having space for another control in Sound Finder, even if this was a problem we could just remove the help from the ;info line. I committed your "don't allow labels before zero" change to Regular Interval Labels and removed the help from the ;info line and put it in the Manual. I think this is reasonable with version 3 plug-ins that can only be run in current Audacity. While some users may be glad of the extra help, they should really be looking at the Manual.

I also trimmed the licence blurb in "Regular Interval Labels" to "Released under GPL v2" and suggest we standardise on that. Are you happy with Sound Finder/Silence Finder just having "Released under GPL v2" on the ;info line? I don't think they need the blurb about "if too many labels are produced" given the error box covers that. If you think Sound Finder should still say "Adds region labels for detected areas of sound" or similar that would be OK with me.




Gale

[steve]

I quite like the way Regular Interval Labels does it. If the label text box is empty the number only is produced; if the label text box has text, the text is appended to the number.

Regular Interval Labels also has an option of whether to use numbers or just the text. Would we want that? Personally I think that's probably overkill and numbers can be always used.

I think the numbering should be double digit - "01", "02"

That's a bit tricky as it's not directly supported by Nyquist, though it is possible.

"01-label text", "02-label text" etc.

I presume that you mean that the hyphen would be automatically inserted by the plug-in and not require that the user types it?

Consistency would be good generally with similar labelling plug-ins. If we prefer that Sound Finder numbers tracks, then I think Silence Finder should do so instead of giving all tracks "S", then the numbering makes more sense if we add the option of label text there too.

Yes I think we should have consistent labelling between Sound Finder and Silence finder.

can we standardise on months having three character abbreviations)

Is that really necessary? I was anticipating that the date suffix would be removed once the code is finalised - it's just a convenience to have the date to distinguish which version we are talking about.

While some users may be glad of the extra help, they should really be looking at the Manual.

For plug-ins that are bundled with Audacity I agree that any "instructions" in the GUI can be kept very brief (with instructions included in the manual), however I think that a brief description in ;info of what the plug-in does would still be useful. (similar rationale as "Tool Tips").

If you think Sound Finder should still say "Adds region labels for detected areas of sound" or similar

Yes, something like that.

Also on consistency I notice the Sound Finder threshold unit is now [dB] ... I think this is reasonable.

I'm glad that was noticed, (and that you consider it reasonable) - it's always bugged me that some effects use negative dB. However, if we make all Nyquist plug-ins consistent in this respect, then the "Normalize" effect could be up for QA discussion.

"Released under GPL v2" and suggest we standardise on that.

Sounds good to me.

You may have noticed that I've moved the "Credits" into a comment within the plug-in.
Personally I think it is reasonable for to have a credit to the plug-in author in the ;info when the plug-in is entirely, or almost entirely the work of one person, but it becomes rather too cumbersome for collaborative work.


Regarding label text - formatting text is rather messy in Nyquist, so if possible I'd like us to have a clear agreement of how we want the label text before I code it.

[Gale Andrews]

I quite like the way Regular Interval Labels does it. If the label text box is empty the number only is produced; if the label text box has text, the text is appended to the number.

Regular Interval Labels also has an option of whether to use numbers or just the text. Would we want that? Personally I think that's probably overkill and numbers can be always used.

Maybe there is a stronger case for it with Sound/Silence Finder e.g. in compilation albums? But don't feel very strongly.

"01-label text", "02-label text" etc.

I presume that you mean that the hyphen would be automatically inserted by the plug-in and not require that the user types it?

That was my suggestion yes.

can we standardise on months having three character abbreviations)

Is that really necessary? I was anticipating that the date suffix would be removed once the code is finalised - it's just a convenience to have the date to distinguish which version we are talking about.

Certainly not necessary, just less letters to type when referring to the test versions in threads.

For plug-ins that are bundled with Audacity I agree that any "instructions" in the GUI can be kept very brief (with instructions included in the manual), however I think that a brief description in ;info of what the plug-in does would still be useful. (similar rationale as "Tool Tips").

If there is a rationale in built-in effects it seems to be that "instructions" in the GUI are only used where really necessary e.g in Change Pitch/Speed/Tempo where users may interpret those terms differently. I don't see any need for a description in the GUI of Regular Interval Labels given the self-explanatory control wordings. I guess a brief description could be put in the comments, a bit like \brief doxygen comments in built-in effects. Purely on consistency grounds, bundled Nyquist plug-ins would not normally have GUI instructions (LADPSA plug-ins I've seen don't have them either).

Also on consistency I notice the Sound Finder threshold unit is now [dB] ... I think this is reasonable.

I'm glad that was noticed, (and that you consider it reasonable) - it's always bugged me that some effects use negative dB. However, if we make all Nyquist plug-ins consistent in this respect, then the "Normalize" effect could be up for QA discussion.

From -devel discussions I think it's accepted that the amplitude box in Normalize should take positive values,especially given they are now legitimate in 32-bit float. It's not on Bugzilla because I've not had time to add it. Discussion of whether "Normalize" should be called "Amplify" and vice-versa or if they should be combined (and DC offet split out) are of course something else.

You may have noticed that I've moved the "Credits" into a comment within the plug-in.
Personally I think it is reasonable for to have a credit to the plug-in author in the ;info when the plug-in is entirely, or almost entirely the work of one person, but it becomes rather too cumbersome for collaborative work.

-1. To remove authorship from the GUI would be inconsistent with both built-in and LADSPA plug-ins. If there are many authors, I think we would just have "By <main authors> and others" or similar.



Thanks



Gale

[steve]

For simplicity in the interface I'll keep numbers as always part of the label.
(if Nyquist plug-ins had a check-box control I'd probably go for that, but it hasn't)

I agree that Regular Interval Labels is pretty self explanatory without instructions in the GUI, though I think that some Nyquist plug-ins will benefit from brief indications of what they do in the ;info.

Although LADSPA plug-ins do not have instructions in the GUI, in other applications (such as Ardour, Jack Rack, and so on) many of them have a full graphical interface (much like VST plug-ins). However in Audacity, LADSPA plug-ins have a minimal interface that confront the user with nothing more than a column of sliders and no instructions, which can make it very difficult to understand what the plug-in does or how to use it. For example, without going on-line and looking it up there are no clues as to what the "Sinus Wavewrapper" effect does or how to use it. Possibly a better example is the calf compressor - here it is with full graphical interface: http://calf.sourceforge.net/compressor2.png
The old adage about pictures and 1000 words can be well applied to graphical interfaces, but Nyquist GUIs have a very limited vocabulary so a few words of explanation may not be amiss.


I had some concerns regarding the removal of credits from the GUI, but to clarify this point:

"Silence Finder" was written by Alex Brown.
"Sound Finder" was written by Jeremy Brown.
This new version was written by myself, but....
I don't consider myself to be the author as this new version is just a rewrite of Jeremy's algorithm. There are however more changes to the code between this version and Jeremy's version than there are between Jeremy's plug-in and Alex's plug-in.

Jeremy acknowledged Alex as "based on a script by Alex Brown", which I think was probably appropriate as Jeremy's Sound Finder was clearly a modified version of the Silence Finder code, but they provide distinctly different functions in that one marks silence and the other marks sound. So do we keep both names in the ;info, or just Alex, or just Jeremy?

[Gale Andrews]

...Jeremy's Sound Finder was clearly a modified version of the Silence Finder code, but they provide distinctly different functions in that one marks silence and the other marks sound. So do we keep both names in the ;info, or just Alex, or just Jeremy?

I would say "By Jeremy Brown, http://www.jeremy-brown.com, after Alex S.Brown" (only the primary author has the URL attached, assuming we keep the convention not followed in Audacity built-in plug-ins of giving URLs).

David Sky used to include expanded text for GPL in the comments:

; Released under terms of the GNU General Public License version 2
; http://www.gnu.org/copyleft/gpl.html .

but I don't feel strongly about that.



Gale

[steve]

Regarding the following extracts from "Terms and Conditions of GPL v2" http://www.gnu.org/licenses/gpl-2.0.html

If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

each file should have at least the "copyright" line and a pointer to where the full notice is found.

Under these terms it should be made clear that this plug-in is not the original plug-in created by Jeremy Brown but is a derivative work.
Also, if a user wishes to contact the author regarding the script, then Jeremy Brown is possibly not the appropriate person to ask as this is not the code that he wrote.

Perhaps the ;info line should say something like:
"Derived from scripts by Jeremy Brown and Alex S.Brown"

Considering the final extract from GPL v2, I think it would be appropriate to include the expanded text as suggested by David R Sky.
Perhaps this could be included (commented, or perhaps double commented so that it stands out better from the header information) either immediately below the ;info line, or below the last ;control line (if present).

For example:

Code: Select all

;nyquist plug-in
;version 1
;type process
;categories "http://lv2plug.in/ns/lv2core/#FilterPlugin"
;name "Notch Filter..."
;action "Performing Notch Filter..."
;info "Released under GPL v2."

;; By Steve Daulton and Bill Wharrie. September 2010
;; Released under terms of the GNU General Public License version 2
;; http://www.gnu.org/copyleft/gpl.html

;control freq "Frequency" real "Hz" 60 0 10000
;control q "Q (high value for narrow notch)" real "" 1 0.1 20

[Gale Andrews]

Regarding the following extracts from "Terms and Conditions of GPL v2" http://www.gnu.org/licenses/gpl-2.0.html

If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

2. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:
a) You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

each file should have at least the "copyright" line and a pointer to where the full notice is found.

Under these terms it should be made clear that this plug-in is not the original plug-in created by Jeremy Brown but is a derivative work. Also, if a user wishes to contact the author regarding the script, then Jeremy Brown is possibly not the appropriate person to ask as this is not the code that he wrote.

Perhaps the ;info line should say something like:
"Derived from scripts by Jeremy Brown and Alex S.Brown"

I think it's your call if you decide to regard yourself as the primary author or not in the ;info line, depending on the extent of the rewrite. You said before you didn't so regard yourself, but I agree you would probably be the person to contact with queries from where the plug-in stands now. But I think the GPL has to be interpreted reasonably. For example in some Nyquist plug-ins I've made some modification such as changing the default slider values which is noted as a comment but I don't think that makes me the primary author or that my name should be noted in the ;info line.

I prefer "after" to "derived from scripts by", and I think someone has to be there as the primary author. That means "By <primary author>" at the start of every ;info line (not least for ease of not having to open the file to find it).

Considering the final extract from GPL v2, I think it would be appropriate to include the expanded text as suggested by David R Sky.
Perhaps this could be included (commented, or perhaps double commented so that it stands out better from the header information) either immediately below the ;info line, or below the last ;control line (if present).

For example:

Code: Select all

;nyquist plug-in
;version 1
;type process
;categories "http://lv2plug.in/ns/lv2core/#FilterPlugin"
;name "Notch Filter..."
;action "Performing Notch Filter..."
;info "Released under GPL v2."

;; By Steve Daulton and Bill Wharrie. September 2010
;; Released under terms of the GNU General Public License version 2
;; http://www.gnu.org/copyleft/gpl.html

;control freq "Frequency" real "Hz" 60 0 10000
;control q "Q (high value for narrow notch)" real "" 1 0.1 20

Yes, I like the double comment but I'm still very strongly of the view as above that the ;info line must start with the primary author. Either the ;info line says:

;info "By Steve Daulton and Bill Wharrie, September 2010. Released under GPL v2."

and we do away with repeating that as the first double comment - or the first double comment becomes the filename:

;; notch2.ny.

Alternatively, the ;info line is as above but excluding the date, and the first double comment becomes:

;; notch2.ny by Steve Daulton and Bill Wharrie, September 2010.

I think that's closest to current practice in built-in effects.

If you really feel the ;info line should not contain the author(s) then I think you should raise it on -quality, because it would be a major departure from practice in all other effects,



Gale

[steve]

I think it's your call if you decide to regard yourself as the primary author or not in the ;info line, depending on the extent of the rewrite.

The rewrite is extensive but credit for the algorithm goes to Jeremy Brown and Alex S.Brown.

If you really feel the ;info line should not contain the author(s) ....

Not at all, I think give credit where it's due. I also like the 'personal touch' - it's like seeing a signature on a painting.
We only really omitted names from the Notch Filter plug-in for brevity in what is a minimalistic plug-in with a minimalistic interface.