Has anyone seen a puredata implementation of Andrew Simper's dynamic smoothing algorithm?
https://cytomic.com/files/dsp/DynamicSmoothing.pdf

@ben.wes said:

for the sake of completeness (and thanks to @manuels' inspiring patch), i'm adding the "efficient" version here (not well tested neither):

dynamicsmooth-efficient~.pd

... i really like this approach and i will create an external for it as well.

did you happen to make an external yet?

I'd like to use multiple instances in a patch and that's only possible by changing the names of the delay lines...

cheers!

Here is my speech optimized audio leveler with dynamic smoothing. Feel free to comment and improve.

leveler_dynamic_smoothing.pd

works in plugdata.
still a bit messy, I'm a sound engineer, not a coder.

enjoy

@trummerschlunk said:

did you happen to make an external yet?

you can try this: https://github.com/ben-wes/pd-dynsmooth/releases/tag/0.1.0-test1 ... this is completely fresh and untested though. so no guarantees! and the help file currently relies on my show~ object which relies on pdlua. damn those dependencies.

anyway: it looks ok for me. that stuff isn't well organized though. i might invest a bit more time soon. also not sure if it's sufficient to control base frequency and sensitivity only via messages.

it includes the abstractions as well ( @manuels: i'm referring to your patch there - let me know if this is ok for you, otherwise, i'll gladly change that).

@ben.wes works like a charm, thank you!
(only efficient version tested so far.)

@trummerschlunk glad to hear! i made another quick update. the abstractions are more properly named now (dynsmooth-abs*) and they also support creation args for basefreq and sensitivity. i removed the additional inlets ... all objects (including the external) are now expecting messages for those parameters (and for clear).

i also added a basic readme and the new "release" (huge word for this little object) is also ready for download:

• https://github.com/ben-wes/pd-dynsmooth_tilde

@ben.wes awesome

... and probably the last update on this for the time being (unless people find errors, of course):

the latest changes add multichannel support to the external (it might be nice to allow different base frequencies and different sensitivities for different channels - but i'll skip that for now).

@ben.wes ah, multichannel support - just what I need

Sorry, I am still very new to plugdata, and I get error messages with dynsmoth-abs-efficient~ -mc 32
bad arguments for message 'f' to object 'objectmaker'

Where exactly do I place your dynsmooth~ folder (downloaded from releases)? In Abstraction and Externals? Thanks a LOT!

@trummerschlunk said:

Sorry, I am still very new to plugdata, and I get error messages with dynsmoth-abs-efficient~ -mc 32
bad arguments for message 'f' to object 'objectmaker'

ah, wait ... you don't need to do anything for multichannel support - it just takes multichannel signals as input and outputs the smoothed multichannel signal. but i only added that for the external (dynsmooth~) - for the abstractions, it would also be simple, i think - but i didn't attempt yet. would need to change the feedback to multichannel.

Where exactly do I place your dynsmooth~ folder (downloaded from releases)? In Abstraction and Externals? Thanks a LOT!

in any folder that pd knows. ... but externals would be fine, sure! and pd will automatically search in the dynsmooth~ folder for the external with the same name (for the abstractions, you'd need to use dynsmooth~/dynsmooth-abs~ unless you add the folder to the paths).

Understood. I still can't load the external somehow. Maybe because I am on a arm/silicon Mac?
The abstractions are loading.

Would dynsmooth~ then be the accurate or the efficient version?

Would it run in 'compiled mode' in plugdata?

@trummerschlunk said:

[...] Maybe because I am on a arm/silicon Mac?

the builds include binaries for both, silicon and intel Macs (on M2 here myself - so that's even the only build that's actually tested ).

Would dynsmooth~ then be the accurate or the efficient version?

dynsmooth~ initializes the accurate version. if you create dynsmooth~ -e, it'll use the efficient algorithm. also, you can initialize base frequency and sensitivity with creation args like this: dynsmooth~ -e 100 0.01 for example.

Would it run in 'compiled mode' in plugdata?

compiled mode only supports the object that are known by the heavy compiler:
https://github.com/Wasted-Audio/hvcc/blob/develop/docs/09.supported_vanilla_objects.md

... unfortunately, block~ (for the 1-sample feedback) is not supported - so i'm afraid that it's not an option to use the abstractions in that mode.

ah - and i forgot to mention in the previous response: i made another little update to the abstractions so that you can set the channel count via a channels <count> message:

• https://github.com/ben-wes/pd-dynsmooth_tilde/releases/tag/0.4.0-test2

unfortunately, it's necessary to set the count of send~ objects manually that way.

@ben.wes said:

the builds include binaries for both, silicon and intel Macs (on M2 here myself - so that's even the only build that's actually tested ).

I accidentally installed the wrong (pd64) version. Now, pd32 dynsmooth~ external works perfectly. Also multichannel

... unfortunately, block~ (for the 1-sample feedback) is not supported - so i'm afraid that it's not an option to use the abstractions in that mode.

hm, too bad. Same is true for the external, I guess?

@trummerschlunk said:

hm, too bad. Same is true for the external, I guess?

yep. vanilla patches are the only option for that ... but when it comes to 1-sample feedback without block~ 1, the only options are the filter objects (rpole~ etc.). i'm honestly not completely sure if this dynamic smoothing here could be achieved in some other way (like obtaining x[n-1] via rzero_rev~ 0) - but i don't think so.