I’d like to nominate Steve’s “Really simple tone control plug-in” https://forum.audacityteam.org/t/really-simple-tone-control-plug-in/12322/1 for inclusion in the Audacity distribution. I think it would be a boon to those users who are intimidated by the Equalization effect.
– Bill
I’m OK in principle as long as it replaces Bass Boost. Not otherwise, because I think we could use the menu space to add other plug-ins for which there is no current alternative.
EQ does (in 1.3.13) have Treble Cut, Treble Boost, Bass Cut and Bass Boost presets. Any comments on those?
I haven’t seen a lot of comments that EQ is intimidating - are there many such? I think Martyn accepts a possible case after 2.0 to have two EQ effects (one curves, one graphic) with possibly a reduced interface like this for the Graphic EQ. Perhaps the case for that is weaker if we replace Bass Boost with Tone Control?
The Help Screen in Tone Control would have to be fixed for excessive height as per Conventions.
I suggest the Technical Details should make clear Equalization and Normalization refer to that employed in this plug-in, not the built-in effects of that name.
Gale
Well, no-one else seems to be clamouring for this, so perhaps we can let it go. If Steve feels like polishing the help screens and putting it up on the Nyquist effect download page, that’s up to him.
The bass cut and treble cut have such severe cuts that the graph goes off the scale in the default view, which is +/- 36 dB. They are not the inverse of the “boost” presets - it occurs to me that they should be. But it depends on what you want to do. Gentle bass or treble reduction is one thing. The way these are structured one would be better of using the High Pass Filter or Low Pass Filter. I’ll bookmark that page and make comments there.
The distribution of the default EQCurves.xml still hasn’t propagated to the Mac nightlies, but that’s another discussion.
– Bill
+1
I’m generally OK with that, but there are some issues that should be considered.
The Bass Boost effect is approximately twice as fast as the Tone Control plug-in. The Tone Control is reasonably quick for a Nyquist plug-in, but Nyquist plug-ins are inherently slower than other effects.
The Bass Boost has a “Preview”. This is not currently possible with Nyquist plug-ins (but would be a great addition and is currently listed in the Nyquist Wish List.
The “Normalize” feature in the Tone Control is potentially dangerous (as is the case with all Nyquist plug-ins that include a Normalize feature) because if used on long audio tracks it can eat up all available memory and cause Audacity to freeze or crash.
I’ve not seen any posts saying “oh oh oh, the Equalizer is so intimidating it scares me…”
but I get the impression from quite a lot of users that they have avoided trying to use the Equalizer because it looks too complicated.
I think the main benefit of a “reduced interface” for the Equalizer would be to make it more convenient for people that already use it. If it encourages some less technical users to have a go with it, then that’s a bonus, but because of the number of features (sliders/curves, filter length, preset manager, invert …) I think it will mostly continue to be seen as a “power user” tool. For this reason, I think a quick and easy “tone control” would be a significant benefit for many users.
It is not an uncommon question to see someone ask “I’ve found the bass boost effect, but how do I do the opposite and reduce the bass?”
This begs the question, how can they find the bass boost without finding the Equalization effect?
I think the answer to this is that they immediately understand “bass boost”, but “Equalization” sounds technical and scary so they skip over it.
If they saw “Tone Control”, then my guess is that they would recognise that also.
Yes - basically along the same lines as Bill, but that’s a different discussion.
Tone Control plug-in
I’ve revisited this bit of code and made a few changes.
As mentioned, there is a potential hazard with the Normalise feature, so I have set that to OFF as the default.
This is a shame as it is a particularly useful feature of the effect, but there is currently no way to apply normalisation in Nyquist plug-ins without running the risk of crashing. Even the great R.D. has only succeeded in producing memory safe normalisation by using a 2 pass effect (a highly complicated Nyquist script that needs to be applied once to measure the current amplitude and a second time to apply the amplification).
This is a serious limitation in Nyquist that applies to several currently available plug-ins. My number #1 feature request for Nyquist would be for the peak amplitude of the selection to be passed to Nyquist, either as a Global variable, or as a property of “s”.
If it is technically possible to do so, I would think that attaching the peak value of “s” as a property would be the better way to do it. The global variable “LEN” could probably be attached in the same way, and in the future possibly other properties, such as the track name (could be very useful for labels).
However, we currently do not have such a feature, so I’ve looked at alternatives.
I notice in my original code that I have used a very complicated method to calculate the peak amplitude. I did this to try and minimise the memory usage, but I think now that it is only of benefit to earlier versions of Audacity that were suffering from a bug that prevented memory from being released properly. This Audacity/Nyquist bug has now been fixed so there is no need for such a complicated method, so I have simplified this bit of the code.
To avoid the normalisation problem altogether, I have also produced a version (tonecontrol-2) that has an “Output Amplification” slider instead of Normalisation. I don’t think this is as convenient for users, but it is safer.
The Help screens have now been fixed.
I’m not sure about including the “technical details” in the “Tips” section - it may be useful for some users so they can see exactly what the effect does, but does it undermine the “simplicity” of the effect? What do you think?
I have also made a third version (tonecontrol-3) that resamples the wave before calculating the peak level - I’ve seen this used in some of the existing plug-ins, but as far as I can tell it makes no difference to the speed or memory usage.
Here are the three versions.
tone-control.zip (4.67 KB)
Another issue may be that Tone Control will be well down at the bottom of the Effect Menu. Could be counteracted slightly by calling it “Bass/Treble Control”?
I kind of get the impression from that that even a reduced interface for Graphic EQ may be over the heads of some users. My non-Forum correspondents (who are definitely not technically inclined as you noticed) seem reasonably OK with Graphic EQ on a “push a slider and hope” basis… once they can find it. I would prefer EQ initialised to Graphic EQ.
The main benefit of Bass Boost though is I think the speed as much as lack of complexity. It gives you “something” like what you wanted quickly without a lot of agonising to get the “perfect” result. When I am in the mood to get the “perfect result”, I use all the available graphic EQ sliders so I would regret some being removed.
I don’t think “Output Amplification” will be useful if you are targeting more basic users. You could make the “Off” text for “Normalize Output” to be “Off (safer on long tracks)”, though David Sky used to have normalise in a number of his older plug-ins and I don’t think he was too worried about crashes.
I’d prefer a space between “0” or “-3” and “dB”.
I’d say ditch the technical details and the talk about bit depth in “Normalize Output”. If you use some briefer text like this:
(defun help ()
(format nil
"TONE CONTROLS:
To increase treble (high frequencies) or bass
(low frequencies), move the appropriate slider to
right. Move the slider to left to reduce the
treble or bass.
Set the slider to center [0] for no change.
NORMALIZE OUTPUT:
Increasing or reducing treble or bass makes the
output louder or softer. The 'Normalize Output'
option can adjust the loudest part of the output
to compensate. If 'Normalize to 0 dB' sounds too
loud, try 'Normalize to -3 dB' instead. NOTE:
Normalize could make Tone Control slow or liable
to crash if used on longer tracks or selections.
TIPS:
Test on a short section before applying to the
entire track. If you do not like the result, use
'Undo' from the 'Edit' menu.
For technical details of this effect, see the
comments in tonecontrol.ny."))
you can get away well enough with one screen I think.
Gale
Thanks for the suggestions Gale.
I’m not sure about the first part of “Normalize Output” help - I’ll sleep on it.
Yes I agree, technical details can go in the comments.
Absolutely - there are many occasions when I want to just knock down or up a specific range and anything wider than 1/3 octave would be too inaccurate. I would be strongly against permanently loosing some of the sliders - in the “reduced interface” mock-up that you referred to earlier, I very purposefully illustrated the number of bands as user selectable.
Probably more useful than nothing. Just being there draws attention to the fact that they may need to adjust the overall level.
But I agree that Normalising would be a lot easier for many users.
Good idea.
Yes, I know - but I’ve already had complaints about the tone control making Audacity lock up, and the issue is exactly the same in many of David’s plug-ins.
We really do need a fix for this. Any attempt to Normalize a full side of an album is likely to push memory usage up by about 1 GB, which will be very unfortunate for many users. Any idea how I/we can get a developer interested in fixing it?
That would be nice, but I’d rather have 2 screens if it is necessary to make the instruction clear and useful. I’ll have a think about the wording for the bit on “Normalise”.
Of course, another alternative to “Bass Boost” would be if someone coded a tone control as a native (C+) effect - then it could have the preview, be faster, and no problem with Normalising (but given a choice I’d rather they implemented a method of passing the peak amplitude from Audacity to Nyquist as that would benefit so many more plug-ins).
How about - if instead of the Normalize control, I just put in an option:
Use Overload Prevention: Yes (read Help) / No (safer on long tracks)
and in the Help File:
TONE CONTROLS:
To increase treble (high frequencies) or bass
(low frequencies), move the appropriate slider to
right. Move the slider to left to reduce the
treble or bass.
Set the slider to center [0] for no change.
OVERLOAD PREVENTION:
This option will automatically lower the overall
level if required to prevent distortion.
** WARNING ** If used on very long tracks or
selections it may crash Audacity.
TIPS:
Test on a short section before applying to the
entire track. If you do not like the result, use
'Undo' from the 'Edit' menu.
If Overload Prevention is disabled it may be
necessary to reduce the overall track level
before applying this effect.
For technical details of this effect, see the
comments in tonecontrol.ny.
+1
I agree that it would be good to get the digital audio novices started off in a simpler, less intimidating way - But it is important that we retain the full EQ functionality too for the power users.
WC
Bass/Treble effect (with optional Overload Protection)
Help screen (now only one) updated and Technical Details moved into comments.
bass-treble.ny (2.78 KB)
OK, I had forgotten user could choose number of bands, sorry. But even that control is itself a possible extra complication/confusion if users are struggling with EQ.
Is one extra pair of sliders worth considering for “Bass/Treble” so you have “Deep Bass”, “Light Bass”,“Soft Treble”,“High Treble” or some such?
Asssuming I’m correct this a problem with Audacity-Nyquist, then it (and anything else in the Nyquist wish list which is a bug /performance limitation) can in principle be tracked as a bug on Bugzilla (as opposed to an enhancement).
However, isn’t your issue really the same as the existing Bug 87 “Nyquist implementation: Excessive memory usage” (which I think relates to usage in processing)? If so this has been raised before by Edgar-rft, and as Richard pointed out, seems almost insoluble because Nyquist memory management assumes source/destination audio files.
Hence the only practicable solution would seem to be that proposed by Leland (memory pool tracking).
Back to your Bass/Treble effect, in the technical details in the comments - is the output amplification only applied when needed i.e. you are talking about the “overload prevention”?
I noticed that prevention doesn’t stop View Clipping showing individual samples here and there as clipped (e.g. if you go for positive EQs or repeat the effect). That’s true with 32-bit or 16-bit data.
I think the prevention idea is good, but I’d prefer standard terminology e.g. “Prevent Clipping” if this is to be proposed for distribution in Audacity.
Other minor points:
Do we need “Select help if required from menu” - should be obvious?
“View Help: No (process)” confused me - It could be taken as the opposite (don’t process the effect, show the help). There are two ways of handing this choice and I think it should be a “convention”:
“Show Help Menu” : No,Yes
or
“ or View Help”: Apply Effect,View Help
Vocal Remover opts for the second solution, which I prefer as being clearer - but I don’t mind the second solution if e.g “No (apply effect)” and “Yes”.
“No (safer on long tracks)” overflows on Ubuntu 800x600 and even on XP 1024x768 at slightly increased DPI. So I think you will either have to put the “(safer on long tracks)” as a new line underneath “Allow Clipping” (or whatever); or just have “No (safer)” for the combo box text.
Gale
Rats - I posted an extensive reply, but it’s disappeared 
Bug 87 is certainly related, but there is a common “special case” that can be addressed in a different way. This “special case” is when normalizing “s”. This is not a cure-all solution, but would be a useful feature. In some situations, if the peak value of the selected audio is known then the peak value of the output can be calculated (either exactly, or as a ball-park figure, depending on what processing is being done). The peak value of “s” is known to Audacity, so why not make that value available to Nyquist?
More about this here: Normalizing
Replacing “s-read” so that Nyquist can read audio data from Audacity (as mentioned by Richard) would address the performance limitation, but I think that passing the peak level of the audio to Nyquist is more of a feature request.
I’ll get back re. bass/treble effect in a new post.
You mean “Presets”? For the Bass/Treble effect?
Possible, but I think it makes it look too complicated.
I think it would be confusing that the sliders would be ignored if a preset was selcted, and what exactly does “deep bass” mean? Does “deep” refer to the gain or to the frequency? Better to keep it simple.
Yes, it is only applied if necessary.
I considered calling it "Prevent Clipping, but decided that was misleading.
I think that the phrase “Prevent Clipping” implies the opposite of “Allow Clipping” (as in the “Amplify” effect. However, “Allow Clipping” (when not selected) prevent the effect from being applied if the result will produce clipping.
The setting in this effect does not prevent “illegal” settings from being used - it applies level reduction if necessary to prevent clipping. This version has different wording to explicitly describe what it does.
Yes, the same thing happens when using the “Amplify” or “Normalize” effects.
However I’ve adjusted this version so that it amplifies to just below 0 dB so View Clipping should no longer produce red lines…
Yes it should be. removed in this version.
Yes I like that.
What about the Vocal Remover effect? Doesn’t the wording overflow in that also?
I don’t think that “No (safer)” is appropriate because in terms of whether clipping occurs, “No” is not safer, “Yes” is safer.
“No” is only “safer” with regard to processing long selections on computers with little RAM.
I’ve changed it to a simple Yes/No.
bass-treble.ny (2.77 KB)
Well I guess something that is only an Audacity-Nyquist feature request would (like other enhancements) not tend to get on Bugzilla until it has some pledges of support in a Wiki Proposal page.
Is Roger aware of your suggestion to pass the peak value of “s” to Nyquist? He doesn’t read here, so you should probably post on the -nyquist list about it. At least you would get an informed opinion of feasibility.
If we had memory pool tracking which should be of even wider benefit, would being able to pass peak value of “s” still make processing a lot faster compared to not having that ability? Passing “s” sounds to be very simple and efficient.
Gale
No I mean four text input boxes and four sliders, like a Graphic EQ “reduced interface” with four sliders (the reason being, will a “reduced but still useful” graphic EQ ever be simple enough)? The name of the slider can be what you like.
Then I wondered if the technical details should clarify that.
I take the point, though it’s a fine one. “Reduce Output Level if necessary to prevent distortion” is far better than “Overload Prevention”, thanks. Why not turn that into nouns as we do in most plug-ins and maybe a bit less verbose “Output Level Reduction (for clipping prevention)”? Anyway, up to you, though I think it should include “Output Level Reduction”.
Thanks, I did not know Amplify or Normalize could clip, though the selections I tried did not clip when scaled to 0 dB in those effects.
Yes, bigtime 
… And so do some others but it does make them look crappy IMO.
OK. Though having taken 1 minute to bass/treble a 35 minute track with prevention set to “no”, but 7 minutes to process with it set to “yes” (plus 5 minutes to redraw the track after the effect finishes) I can see why you were worried. How about “Yes (slower)”?
Gale
GA: is the output amplification only applied when needed i.e. you are talking about the “overload prevention”?
S: Yes, it is only applied if necessary.
GA: Then I wondered if the technical details should clarify that.
…
GA: Why not turn that into nouns as we do in most plug-ins and maybe a bit less verbose “Output Level Reduction (for clipping prevention)”?
Yes I can clarify that in the Technical Details, but with the wording “Reduce Output Level if necessary to prevent distortion” I think it is already clear that it is only applied if necessary to prevent distortion.
If the wording is changed to “Output Level Reduction (for clipping prevention)” then I think that it is no longer (as) clear that it is only applied if necessary to prevent distortion.
As a compromise it could be: “Output Level Reduction - if necessary to prevent distortion”, though this looks and reads badly IMO.
I see that turning it into nouns is the convention, but as the original premise is to make it easy to use for new users, I prefer clarity over convention. Ideally the user should be able to understand what the effect does and how to use it without reading the Technical Details, or even without reading the Help.
I’m open to any ideas for alternative wording that is as clear as the current wording.
BTW, the Nyquist interface always adds a colon at the end of the “text-left”, which does not look good if the last character in the “text-left” is a punctuation mark (a close bracket looks similar a sad “smilie” ): and a question mark looks wrong?:
S: What about the Vocal Remover effect? Doesn’t the wording overflow in that also?
GA: Yes, bigtime >
I agree. If possible, I think this needs fixing in the Audacity code so that the box can be expanded.
Depending on the characters used there may only be enough space for as few as 8 characters.
At least the text expands when clicked on.
I would expect that if you test on a 10 minute selection, the time taken will be identical whether it is set to Yes or No.
I would also expect that if you try processing a 60 minute selection, processing with Level Reduction enabled will be extremely slow, or even crash.
It all depends on the available RAM. As soon as data swapping from RAM to disk is grinds down to dead slow.
On XP with 512 MB RAM, a 5 minute selection will process at virtually the same speed regardless of whether Level Reduction is enabled or not, but a 15 minute track will seize up for a long time.
On Linux with 3 GB of RAM, a 35 minute selection will process at virtually the same speed, but a 70 minute selection will seize up.
I have added a note to the Technical Details to clarify this:
TECHNICAL DETAILS:
Tone adjustment uses two second-order 'shelf Eq' filters.
The half-gain point of the filters are set to 600 Hz (bass)
and 2 kHz (treble).
Maximum boost/cut is +/-15 dB for all controls.
'Level Reduction' is applied to the sound post filter and is
only applied if the output will otherwise exceed 0 dB.
If the selected data is too large to be read entirely into RAM,
processing will be very slow as data is swapped from RAM to
disk. This is unavoidable in the current implementation of
Nyquist in Audacity and applies to all Nyquist plug-ins that
use a "Normalize" function.
As Nyquist processes audio at 32 bit (float) there is no risk
of distortion being introduced provided that the output level
is set such that the final output level is below 0 dBFS.
Both channels of stereo tracks are amplified equally (linked).
A 10 Hz eight-pole Butterworth high-pass filter is applied
to the entire selection to remove DC off-set and sub-sonic
frequencies.
bass-treble.ny (3.09 KB)
It’s of course clear from the plug-in interface. Hence I thought it was confusing for the Technical details (above the controls in the .ny file) to suggest by omission that “Output amplification” might always be applied. I think the details are fine now you have changed “Output amplification” to something mentioning “reduction”.
I think “Output Level Reduction (for clipping prevention)” is pretty clear given novices have already got to get used to Amplify and Normalize (which I doubt they will avoid using) with minimal help on the interface. If there is nothing to prevent, nothing will be reduced.
I’m OK with verbs if they give their primary purpose or show exactly what is being done. To me, “Reduce Output Level” does not convey either without reading the next line.
Attached has seven variants and you could mix’n match their two lines as well if you wished. 
I think any of them are better than what we have now. My first choice is (4) and second choice is (7).
That matches with the built-in effects so I don’t think we need to change that.
I’ve added to Nyquist wish list.
Given the space restrictions I think the best we can do is either “Yes (See Help)” or a brief warning in ;info line. Reluctantly, I think I prefer the info line warning (example in the attached). Clipfix has an ;info line warning too, so it’s not indefensible.
Gale
bass-treble-normalize-wording.ny (3.8 KB)
Option 4
Clipping Protection
(normalize to 0 dB if too loud):
Yes, let’s go with that.
I’ve amended the Technical Details and the ‘View Help’ text to match this wording.
Yes, I think that’s the best option.
Rather than referring the user to the ‘View Help’, how about just putting:
NOTE: Setting ‘Clipping Protection’ to ‘Yes’ may crash on long selections
if the computer has insufficient RAM.
(this is more information than currently displayed in ‘View Help’).
Alternatively, (though I prefer the above option),
NOTE: Setting ‘Clipping Protection’ to ‘Yes’ may crash on longer selections.
See ‘Technical Details’ in ‘bass-treble.ny’ file for more information.
bass-treble.ny (3.52 KB)
Has this effect become too complicate?
I’ve noticed that this effect has become a lot more complicated since I first wrote it, so I’ve also attached an even easier tone control.
This works in the same way as a tone control on many portable players - No help screen included - This is so simple that ‘how to use’ should be totally obvious for anyone.
SimpleToneControl.ny (845 Bytes)
Very simple, yes. Appropriate for Audacity, maybe not. Turning up the bass turns down the treble and vice versa. Not flexible enough IMO. This can’t replace “BassBoost”.
I don’t think the original is “too complicated” at all. The complication (if you want to call it that) is the normalizing option. I think that is covered well in the Help screen.
– Bill
Thanks for the comments Bill.
I’ve made the “really simple” version into a “Tone and Volume” effect and posted it here: https://forum.audacityteam.org/t/really-simple-tone-and-volume-control/16987/1
Yes it’s limited, but I think the simplicity could be just the thing for some users.
You’re right though, the “really simple” version could not replace “Bass Boost”, but I think that “Bass/Treble” could.
(it’s just a shame about the Normalizing issue) 
So what happens now?
The current version of the Bass/Treble plug-in has all the agreed changes made.
Do we now e-mail the developers and ask for “Bass Boost” to be taken out and “Bass/Treble” put in, or do we raise the question on the QA list, or something else?