@whale-av thank you for the pointer, david! i've stumbled upon her site multiple times in the past years (mainly through old threads on this forum, i think). she made incredible contributions to the Pd world! i've yet to properly work through this stuff though ...

glad you found a good solution! and thanks for your words - but i'm actually just starting to learn a bit more about that frequency domain stuff. and i think that my patch still has quite some flaws concerning the scales for example! anyway - i'll try to clean this up a bit more and share when ready (also to document it for myself) ... would be fun to check out your result as well!

ok, damn ... this solution with iem_tab was really pointless! feeding back the signal as you did is smarter and certainly more efficient! i also like the approach using max~ to keep the immediate peaks. so here's now an all vanilla solution (except for the tabredraw i'm using to redraw the array). thanks a lot for the inspiration!

video: 2025-05-08 16-44-26.mp4

yep - smoothing the spectrum with a lop~ was not a good idea, i assume. and also my convolution with the kernel i used was not a good idea, since it created an offset of the frequencies in the final spectrum. but that smoothing kernel can also be properly represented really symmetrically if half of it is in the negative frequencies (at the end of the array). and i omitted the convolution with tab_conv in favor of frequency domain convolution with vanilla objects which should be quite fast as well:

the smoothing kernel in this case is just a 64 sample hann window (split in half). barely visible here - and possibly, it might be a good idea to use an uneven width and offset it. not sure ...

here's the result (original, smoothed values and smoothed spectrum) - looks quite correct. there's a 4000Hz signal peak here besides the pink noise now that makes it more obvious:

this is not a precise imitation and i'm not sure if it can be done more efficiently - but it works quite well by smoothing the graph value updates, effectively low-passing them by only adding a fraction of the difference (i'm also differentiating between rising and falling values - the rising ones are less filtered):

smoothed_spectrum.mp4

this could be done in vanilla - but the tab_* objects of the iem_tab library are certainly a lot faster.
for smoothing the graph itself, i use convolution (tab_conv) with a small smoothing kernel. another option there is tabreceive~ -> lop~ -> tabsend~. the result looks ok as well, but it's obviously not symmetrically smoothed then.

not sure if these explanations make sense. but since i was working on some spectrogram stuff today, this question resonated and made me try to respond.

EDIT: btw., the signal in the video is just pink noise on/off.

@oid you're right that my subpatch naming is a bit confusing here. pd $0-main only serves as the canvas where everything is created. so the idea here was that opening this file would directly create a running patch (which could have more dependencies created similarly to everything.pd). but your suggestion sounds good to just create an installer and let the user choose where to install.

the reason for the dynamic patching of everything into pd $0-main here is that i had no luck with iemguts/initbang since it would not trigger first in a subpatch used for file creation unfortunately (this is mentioned in its help file).

interesting discussion! i hadn't considered using the savetofile message before. combined with the dir message to pdcontrol for retrieving the patch path, this should be quite reliable, no?

... this works well for me and might actually be an option to keep everything in one file. thanks!

actually, there has been quite some work on it in the recent months - including updates of the pd version (to 0.54 - so 0.55 is still due). the current builds on github are just 2 months old: https://github.com/agraef/purr-data/releases/tag/2.20.0

... there is no build for silicon mac yet though and i didn't attempt to build it myself - so unfortunately, i can't say anything about vstplugin~ in this version (only that it works perfectly well in vanilla for me, too).

also adding my attempt to create a software oscilloscope with Gem (trying to simulate some physical characteristics). Requires pmpd lib besides Gem: https://github.com/ben-wes/pd-osci_xy

i just uploaded a spectrogram built with Gem. It's not very efficient and i might give it another try with shaders doing the drawing and logarithmic mapping. but anyway - seemed like an appropriate contribution to this thread:
https://github.com/ben-wes/pd-spectro_tilde

responding to myself here ... it's possible to iteratively append data to a top-level array with purest_json (which avoids the restriction to symbols of MAXPDSTRING size).

that's not possible for nested keys though (which is a requirement in my case). i changed the purest_json code now so that i can add to nested keys via messages like array LoudspeakerLayouts.Loudspeakers $1. not sure if that's the "right" way and i'd still be curious if other people see better options in Pd for it!

i'm trying to use json-encode from the purest_json library to create config files for the IEM AllRADecoder. now it might be a questionable endeavor to do this with Pd in general - but i'd like to see if it's possible anyway.

the aim is to create a file like https://plugins.iem.at/allradecoder/layoutWithAdditionalImaginaryLoudspeakers.json

... what i have so far works up until 10 speakers with some test data. but then, the symbol obviously gets too long and i get unnecessary escapings and the last parts of the data look like this:

\"Channel\":11\\,*"}

any ideas on how to solve this?

here's the patch.
test-json-encode.pd (ATTENTION: this writes a test.json file on bang in the patch directory)

Has anyone implemented or experimented with the Fractional Fourier Transform (FrFT) in Pure Data and might point me to relevant resources? So far, I badly failed at implementing an external that would allow continuous rotation between time and frequency domains (see https://en.wikipedia.org/wiki/Fractional_Fourier_transform).

I've heard about quite interesting musical applications of this in a talk and demos by Günther Rabl (who implemented this years ago in his own tools AMP/VASP) and would love to experiment with it in Pd.

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