anyone got a parameter smoother routine they don't mind sharing?
will be writing mine on Monday, and it's gonna go on pretty much every single parameter used in my audio classes, so yeah, kinda vital to have an efficient one, that only runs when values are changed...etc
cheers, Matt
Have a look at Reverb::LinearSmoothedValue
having a look now,
but ummm,,, why is it tucked away there? If you did the work to make it, perhaps it's useful outside the reverb class? ;)
edit:: ahhh...there's lots of stuff here which is useful outside the reverb class... i assume that's the sort of thing you've already grouped together for your new dsp classes.
Yeah, a lot of classes start life tucked away and then get moved out into the public area.
This one was also the subject of Timur's talk at the JUCE summit - you'll be able to watch it when we get the videos up...
i had done this on paper and in my head, and the Juce implementation is pretty close to what i would have done too.
but here's what i would have done different:
"getNextValue" makes perfect sense inside the smoothed value class,
but when you look inside the reverb class where it is used time and time again, "getNextValue" really doesn't mean anything much. I'd go with something much simpler like 'smoothed', to show what the function actually DOES
so,
const float damp = damping.getNextValue();
would become:
const float damp = damping.smoothed();
i'm years and years off writing my own coding standards guidelines, but i think that's something i would add. That functions should be named in accordance to how they look from the caller, rather than how they look internally within their own class.
kinda like how the 'accelerator' of a car is not called the 'increase spark plug spark rate pedal" (not sure if that's how cars work, but u get the idea.
and really looking forward to the talks and videos! That vid of Timur's on threading and atomics was not just really informative, but also he has a real knack for making an hour long speech quite interesting and not at all dry.
No, I'd strongly disagree - method names should make sense within the context of their class, and rarely need to be bodged to involve a class description.
If anything is wrong with the code you're talking about, I'd say it's the name "damping", which would be better called e.g. "smoother", so that you'd read it as smoother.getNextValue(), which would be far better than damping.smoothed()
i'd even more strongly disagree then :D
haha.
nah, not trying to make an argument, and i'll leave it here if u want...
but my example was actually badly chosen. In this case 'damping' is just the lowpass filtering of the reverb input...nothing to do with the smoothing. bad coincidence.
the next call makes it more obvious;
const float feedbck = feedback.getNextValue();
i think it would be much clearer if it were called feedback.smoothed().
and actually, even looking back into the LinearSmoothedValue routine,,,,surely it's main purpose is to 'smooth values, linearly', so i think it's a bit cryptic that the main function is called 'getNextValue'.
anyway, not a biggie... just wanted to share cos i had thought about it a bit.
const float dry = dryGain.getNextValue();
const float wet1 = wetGain1.getNextValue();
const float wet2 = wetGain2.getNextValue();
could become:
const float dry = dryGain.smoothed();
const float wet1 = wetGain1.smoothed();
const float wet2 = wetGain2.smoothed();
yeah?
No - I really think that's much worse than the original!
fair enough.
i pity the poor fools who ever use my code then :D
