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