RMS slow human

Reply to RMS slow human on Wed, 07 May 2025 10:49:40 GMT

theunknownproducer — Wed, 07 May 2025 10:49:40 GMT

Hello everyone! I was wondering if there was the possibility to dynamically change the Hann windowing to change the update rate of the spectrum.
What could be a feasible solution to move from a fast-peak spectrum to a slow-human one such as in the TDR prism?
Thank you for your attention!

rmsslowhuman.mp4

Reply to RMS slow human on Thu, 08 May 2025 12:54:11 GMT

ben.wes — Thu, 08 May 2025 12:54:11 GMT

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.

Reply to RMS slow human on Thu, 08 May 2025 12:41:35 GMT

theunknownproducer — Thu, 08 May 2025 12:41:35 GMT

WOW @ben-wes that's a great looking solution! Thanks for the answer
I tried to create the idea, having two smoothing factors.
The first concerns the transition between peak and rms response.
The second, as you well thought, with a lop~. The smoothing is quite evident, as is a frequency shifting/spectrum translation (probably phase problems caused by the filter). I would have to study quite a bit about rephasing the signal
I'm really out of ideas, as I would like to stay in the plugdata environment to take advantage of the patch in the DAW.

Freqshifting.mp4

Reply to RMS slow human on Thu, 08 May 2025 13:47:24 GMT

ben.wes — Thu, 08 May 2025 13:47:24 GMT

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:

Reply to RMS slow human on Thu, 08 May 2025 14:44:52 GMT

ben.wes — Thu, 08 May 2025 14:44:52 GMT

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

Reply to RMS slow human on Thu, 08 May 2025 20:26:58 GMT

theunknownproducer — Thu, 08 May 2025 20:26:58 GMT

Omg @ben.wes you went godmode! Well, you are really sophisticated. I think yours is a much cleaner solution (mathematically speaking), but it affects cpu cycles a lot.
Your intuition about the filter was definitely the best.
I dont need to explain my solution, I just positioned the filter in the right spot and simply exploited the feedback in the correct way (or at least I think).
And here's the grand finale

Gran Finale.mp4

Thanks for everything Ben, you will definitely be mentioned in this work!

Reply to RMS slow human on Sat, 10 May 2025 10:34:03 GMT

ben.wes — Sat, 10 May 2025 10:34:03 GMT

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!

Reply to RMS slow human on Sat, 10 May 2025 17:38:21 GMT

whale-av — Sat, 10 May 2025 17:38:21 GMT

@ben.wes Have you seen @katjav's site...?
https://www.katjaas.nl/home/home.html
There is some of her thinking on this subject in / applied tech / low latency FIR filters.
David.

Reply to RMS slow human on Sun, 11 May 2025 00:12:24 GMT

ben.wes — Sun, 11 May 2025 00:12:24 GMT

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

Reply to RMS slow human on Tue, 13 May 2025 17:46:44 GMT

theunknownproducer — Tue, 13 May 2025 17:46:44 GMT

This is what I managed to create. There is still a lot to fix, but I think it's a good starting point
HyperCurves v1.0.pd