I’ve been lurking the juce forums and watching youtube tutorials to learn about juce and audio programming in general. I thought a simple first project would be saturation plugin with an asymmetrical waveshaper into a PID controller. You can find it here:
I’m looking for advice on coding, juce, and audio dsp best practices that I’m ignorant to as an hobbyist programmer. I’m looking forward to what I can learn from y’all!
the plugin sort of crashes when you feed audio into it that clips 0db. you might ask yourself why would anyone do that? well i just tried it on a full mix that was normalized to 0. so it didn’t even exceed 0, but just reached it sometimes. so i suppose you have a lookup table somewhere in the code that probably processes the audio differently based on its volume, since it’s a saturation plugin. you’d have to make sure that it can’t go out of bounds.
next up let’s talk about the actual processing. i turned down the volume of my mix to -6db as that’s usually the best range for saturation imo. it immediatly colours the signal pretty strong on default settings into a warm and sorta dull direction. i guess that was to be expected. some popular plugins like NI Dirt do that too. i turned down the input gain to -60, but it didn’t really turn down the volume a lot. that doesn’t seem to work yet. double clicking on the parameter resets it to 0. that’s cool. but the skew factor sucks. you can barely just turn it down to -6 or something. it can only be moved very strongly without holding ctrl. when you turn the gain up it can turn the sound off similiar to my crash earlier, but the sound comes back when you turn it down again at least. still i’d change that. and no one needs max +30db for saturation. So i went on to turn up “Kp” and it kinda glitched out. now i have no sound anymore again. … ok i turned it down again and messed a bit with the input gain, now the sound is on again. so definitely see what#s the problem there. the “Ki” knob also does some weird stuff with the sound sometimes but i more or less like what it does. seems to be a tone-control. higher values make it sound a bit brighter. “Kd” also glitches out, like Kp does. the range works for the master output gain, but sometimes when you move it too fast the whole sound turns off. so definitely copy the code for the decibel conversion from this parameter to the input one, but also definitely try to improve everything else about it.
conclusion: all these audio dropouts are super annoying. idk what’s going on there. if it was about things going out of bounds i think it would crash the plugin so it must be something else. maybe some calculations just make no sense, idk. you have to find out.
edit: i checked out your code a bit. it seems you just do everything in processBlock. Maybe it would be a good idea to learn how to use your own header files and classes so you can tidy up your stuff better. A better overview on your code sometimes makes the mistakes more obvious as it’s easier to navigate. For example you could make a class that is only responsible for the gain faders and then just make 2 objects of that for in- and output. Also be more careful about edge-cases. There are so many audio dropouts everywhere that I’m really surprised that you didn’t encounter any of them before compiling this plugin
Hi hdlAudio! Thank you very much for taking a look at my plugin and the code itself too! Your comments are very helpful.
A few responses to your comments:
Plugin crashes when feed audio into it clips 0dB and problems with Kp and Kd: Yes, this is actually intended behavior of the plugin, as I unfortunately haven’t found a satisfactory solution to the following problem. Maybe someone has an alternative solution I could try? In summary, the plugin is not overall super user friendly because I allow the user direct access to Kp, Ki, and Kd, which are actually filter coefficients. This gives a lot of power to the user and actually means that the user can input values of Kp, Ki, and Kd that cause the filter to be unstable, which means that the output of the filter will feedback to infinity. This is why I decided to implement a safety cutoff that triggers at 0dB, which the user can toggle off, once they find a combination of Kp, Ki, and Kd that sounds good to them. I’m not super happy with the solution as it causes a lot of the audio glitches related to Kp and Kd that you noticed. However, the benefit of this safety feature is that the user will just hear a little click at 0dB and the filter shuts off, as opposed to a huge signal being sent to the user’s speakers. This is definitely the main problem for this plugin being more user friendly, and if you have any good suggestions for alternative solutions, I’m all ears!
The gain knob doesn’t do anything at lower values: This is also intended behavior, but it seems upon seeing your review that it may be unintuitive. The reason the gain knob doesn’t do anything at lower gains is that I divide by gain after my waveshaping so that the gain doesn’t have too much of an effect on the overall output volume.
I’ll check out NI Dirt for sure!
The coding advice is very helpful. I’ll look into making my own header files to tidy up my code!
ah i see! interesting concept. about the parameters that break the filter often. i don’t know how predictable such stuff is, but if there is an actual formular that can tell if a coefficient will break the filter on a specific value or not, then you could just use that function in a way that parameter changes always snap to values, that make sense, just like some car radios nowadays that skip all the noisy stuff when you press on “next station” instead of letting you scroll through it like the old ones. then the user would still have maximum control about the reasonable combinations of settings. if you don’t manage to do that the plugin would still be interesting from a developers perspective, but i can assure you that even very generous audio engineers wouldn’t be amused about audio dropouts. especially that one dropout that made me have to restart my daw should be solved differently.
edit: oh and also: if some of the filters only break if a parameter is moved too fast by the user you can easily solve that by smoothing the parameter. for example by limiting the maximum difference it can have after one sample or one audio block. or by constantly replacing it with an envelope follower of the parameter that is lowpass filtered. i think juce even has a class specifically made for parameter smoothing but i haven’t tried that yet