FUZZ BuStEr PLUG-IN

<>

Thanks for another contribution dondiego929. I hope you don’t mind if I make a few comments:

I think that you will need to give some basic instructions if this plug-in is to be useful to anyone else. As it stands it is not at all clear what it does or how it should be used.
Some reasonable default values would also be helpful as the current defaults just produce silence.

For the code to be usable/adaptable by others, it would help a great deal if the code were more readable. Although some languages of the '70’s could only use upper case and had limited capability for structured programming, over the last 20 years or so it has generally been found to be easier on the eyes to write in lower case or camel case rather than upper case. There are also good reasons to avoid GOTO (GO) constructs in favour of hierarchical program flow structures such as if…then…else…endif, switch, or case, or simply calling a function.

As one author put it:

The current limitation to sample rates of 44100Hz can be removed if you change;

(setq sl (/ len 44100))

To

(setq sl (/ len *sound-srate*))

or

(setq sl (get-duration 1))

Currently your file uses CRLF for end of line, which works on Windows but can cause problems on other platforms. If you use LF instead then it will work correctly on all platforms.
[Update] It should not actually matter if plug-ins are written using CR, LF or CR+LF for end of line. The problem on Linux is due to a bug in Nyquist Workbench that appears when CR+LF is used in a plug-in and the code is pasted into the NyqBench code window. Other than this bug there should be no problem with using whichever format is native to the operating system that is being used.

Excessive commenting can also make the code tiresome to read, particularly when you use a lot of non-language characters. If you look at the code in some of the existing plug-ins ( http://audacityteam.org/download/nyquistplugins ) you will get an idea of the programming style that is generally preferred. Comments should be used to explain the code where it is not obvious, and line indents used to indicate the structure of the program.

Where you have multiple IF statements that produce the same result, you can combine them using “OR”
For example, instead of

(if (= cp8 0) (go line-035))
(if (<= cp8 lcp) (go line-035))

you can use

(if (or (= cp8 0)(<= cp8 lcp)) (go line-035))

or better still, something like

(if (or (= cp8 0)(<= cp8 lcp))
  (setf ffl (addpoints ffl cp8 Frq8)))

where (adpoints …) is a function to add the next envelope points.

Once you have cleared out all of the superfluous text you will see that it is unnecessary to be constantly swapping data between the variables ffl and fft and that you can set ffl directly.

Even keeping all of the (GO …) statements and without using a function to add the points, the code drops from 229 lines to 90 lines and is much more readable.
fuzzbuster1.ny (2.46 KB)
You may also notice that the Nyquist manual says

(snd-tonev sound hz)
This function is identical to snd-tone except hz (cutoff frequency) is a sound. The filter coefficients are updated at the sample rate of hz. You should use lp instead

http://www.audacity-forum.de/download/edgar/nyquist/nyquist-doc/manual/part6.html#index572
The main advantage of using (lp …) instead of (snd-tonev …) is that in the current (1.3.12) version of Audacity, (lp …) supports multi-channel sounds, so removes the mono limitation.

(pwlvr-list …) uses relative positions so having “CP9” set to 1.0 will always create an invalid control point that is beyond the end of the selection (unless there are no other control points set). Depending on how this plug-in is supposed to work, the last control point may need to be set at (1.0 - (sum of other CP’s))

Finally, if you add (print ffl) to the end of the plug-in, this will print out the ffl list and you will notice that the data is incorrect, so although it will produce an effect, it does not produce the correct effect according to the parameters that the user sets. I’m not quite sure what the correct figures should be as you’ve not said what the intended effect is.

Anyway, here is a much simplified version of your code (I think it does exactly the same as your code) which should make bug fixing much easier:
fuzzbuster2.ny (1.92 KB)
I suspect what you really want is to initialise ffl to an empty list, then append “Frq, CP” rather than “CP, Frq”.

<>

<>

Sorry mate, I was only trying to be helpful.

BTW, in the “instructions” (INSTRUCTIONS – OPERATING THE FUZZ BUSTER PLUG-IN.txt) you state:

Due to inaccuracies in Nyquist filter code, frequencies

below entered values MAY be filtered as well (but less

so than frequencies above the value). We apologize and

hope that you can use this plug-in despite its

inaccuracy.

That is not correct. The Nyquist low-pass filters DO affect frequencies below the cut-off frequency, but it is not due to “inaccuracies in Nyquist filter code”, that is how a low-pass filter is supposed to work. Low-pass filter - Wikipedia

<>

<>

<>

<>

Strangely enough, this question came up just a few days ago elsewhere on the forum. Low Pass Filter Question - #2 by edgar-rft
Edgar’s reply covers the subject in detail.

If you want a filter that does not attenuate at the set frequency, then you will need to design a combination of filters to achieve your desired frequency response. A first order low pass filter will not do that and is not supposed to do that. A first order low pass filter is supposed to be 3 dB down at the corner frequency (which is exactly what the first order low pass Nyquist filter does).

I’ve been using this to clean my samples this week and discovered that the closer two points are together in time, i.e., the more of a right-angle they form, the more likely there will be some “tearing” of the audio…similar to selecting half a sample and applying a filter…the closer to 90 degrees, the more of this “tearing” occurs.

FOR EXAMPLE:
0.010 13000
0.012 8000

I’d suggest spacing frequency change points AT LEAST 0.005 seconds apart to avoid this ill “effect”.

Oddly enough, I used such spacing in my RELEASE KIT example, going from 4800 at 0.003 to 17000 at 0.004 and there was NO “tear”. So, I guess this just applies to DECREASES in frequency, although I’d have to test more to find out.