Updated Sound Finder

While adding finer resolution in Sound Finder and preventing “reverse” labels and labels before time=0 it was apparent that the code had a lot of “stuff” hanging over from earlier code. Rather than just adding another “hack” I’ve rewritten much of it, which will hopefully also make it much easier to see what is going on.

As the code changes are substantial I will not be surprised if there needs to be some discussion regarding some of the changes that I’ve made.

(fixed plug-in to follow)

Steve:
I did a quick test of SF1.3 and got some unusual results. I created an artificial test sound that consists of randomly spaced tones mixed with noise at -40 dB. I ran SoundFinder with parameters -30, 0.25, 0.1, 0.1 and “No”. Here’s a screen shot of what I got:
SFScreenShot.png
I can’t attach the project as it is too big, so here is the MP3 export of the audio track:

– Bill

Doh!
I see what I’ve done wrong. Thanks for testing Bill - I’ll put a new version up asap

Sorry about that - two little errors - one was a silly mistake in that I forgot to change the sample rate back to the correct value after testing it with a sample rate of 100 (that was the big “Doh!” :smiley:) The other was an integer value instead of float which produced rounding errors.

[File Updated]

Steve:
Much better!

During the testing phase of these plug-ins, would it be worth putting the version number in the ;info lines (e.g. v1.3.3 20Sept10) so those of us doing the testing are absolutely sure we have the latest version installed? Once the code is finalized that information could be moved to a comment.

[I have 14 different Audacitys on my machine at the moment and there’s always the chance I’ll drop a new plug-in version into the wrong folder!]

– Bill

I only have 3 flavors of 1.3.13 (SVN HEAD-based) I maintain on my machine (of course, I have 4 build configs of the actual HEAD and Unicode Debug/Release versions of my personal builds) and I have sources with built configurations of 1.3.(8, 10 and 12) but I have zipped those up to avoid just what you are describing!

I actually make changes in Steve’s offerings so as to ID them (though I change the text string of the generated label as I have a non-GUI compile which creates 10 or more projects each day). Your suggestion sounds very good…
+1

Yes, good idea using the date - better than using version numbers as I keep forgetting which number I’m up to :smiley:
How about making the distinction in the file name rather than the ;info line? That way makes it easier to compare different versions on the same machine as they are listed according to their name in the Audacity menus.

The last file posted would be “SoundFinder-23-Sept-10.ny” and the plug-in name “SoundFinder-23-Sept-10”.
Or do you prefer SoundFinder-10-09-23 (which keeps them in alphanumeric order).

Steve:
Yes, I think yy-mm-dd is the better format. And yes to also making it the menu name - removes all potential confusion.

– Bill

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?

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.

Oops - just spotted that I’ve not changed the header to say version 3.
Here’s “SoundFinder-23-Sept-10”
SoundFinder-23-Sept-10.ny (5.77 KB)

I think that was the final decision but I think it was by fiat (Gale’s choice with no one wanting to argue the point). It might be a -Quality topic but since I only today found the archive I am not sure. 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–values 0.1+ are remembered (here only talking f.i. about the Min level).

Nice potential feature, but probably not important. I only do it so I know which version of the plug-in did the current job. I have many hundreds of projects “in the can” awaiting human intervention. Whenever I change the plug-in which my “unattended” Audacity uses I change the label (I still keep it a single letter for convenience in deleting the label). I am guessing that when the average user uses SF to demark audio they then use Export Multiple and if labeling is important do the text entry there.

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.

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?

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

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.

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

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.

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

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

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

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.

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”).

Yes, something like that.

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.

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.

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

That was my suggestion yes.

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


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).

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.

-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 and others” or similar.



Thanks



Gale

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?

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
; The GNU General Public License v3.0 - GNU Project - Free Software Foundation .

but I don’t feel strongly about that.



Gale

Regarding the following extracts from “Terms and Conditions of GPL v2” GNU General Public License v2.0 - GNU Project - Free Software Foundation

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:

;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

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 ” at the start of every ;info line (not least for ease of not having to open the file to find it).

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

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

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.