@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.

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.

@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.

@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).

... 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).

@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

@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).

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.

really cool stuff - had fun playing around with this! now i didn't understand the whole patch (which is insane) ... but it looks like you're checking the closest "pixels" only for each mass? seems like a great optimisation so that you don't need to check against every pixel. did i get that correctly?

oh ... i didn't see the discussion here ... just built a little (and certainly dirty) patch for this after the discussion on facebook:
patch_n_bitmaps.zip

it obviously becomes very slow with lots of canvases (and i'm already omitting the white pixels):
2024-09-21 22-46-18.mp4

... plugdata on the other hand can deal with these quite easily - i creates rounded cnv rectangles though.
2024-09-21 22-58-59.mp4

(i scale them in that video - so this is not a glitch, but many wide rectangles)

EDIT: this patch only works with a specific 3x8bit bmp format. so it would certainly look a bit funny with other formats.