@manuels said:

@ben.wes Oh, I think I completely missed your point ...

no worries. that was an interesting hint nonetheless!

disarm the switch after every crossing instead every switch

now i feel completely stupid, haha. of course that's the proper solution! there's no reason at all for not just resetting on every crossing!

i assume that i was too much influenced by a zero-crossing switcher abstraction i built in the past that required feedback in a similar case. thank you!

EDIT: and obviously, there's no need for the [sgn~] (sign) object. [>~ 0] is enough and i really hope that https://github.com/pure-data/pure-data/pull/2054 will make it into vanilla soon!

@manuels said:

@ben.wes You could use [cpole~] instead of [rpole~] like this: audio-rate-toggle.pd

thanks! - this seems very interesting! i never used [cpole~] so far and will play around a bit with it these days. but i admit that i don't get yet how i would use these states here to "disarm" the flipflop mechanism immediately after a switch?

this should hopefully work correctly for switching only after impulses:

EDIT: without block~ 1, there's a risk of directly switching back in the same block while the switch is still armed. so this is not very elegant. if anyone knows how to tackle this without 1 sample blocksize, let me know!

a bit late to this and nice approaches were already mentioned. but since i just built a flipflop~ abstraction a few days ago, i felt like joining this discussion anyway.

here's a patch that uses this to switch signals when they're crossing while sharing the same direction:

flipflop~ is this:

this obviously relies on the zexy library. time to lobby for https://github.com/pure-data/pure-data/pull/2054 ... but these compiled objects can be replaced with vanilla stuff if needed.

patches:
switchoncross~.pd
flipflop~.pd

PS: this obviously happily switches the signals on every crossing. if you want to "arm" the switch through a trigger, it'll need to handle this additional "armed" state which then get's reset by the next crossing impulse ...

just a short update for the record here - this is fixed with https://github.com/umlaeute/Gem/commit/6c321961440a99ec1e4515284a990286fcf5a041

(see issue for more details)

(sorry if someone already read about this issue on discord - should have posted here right away since the forum gathers quite a bit more experience ... in my experience. )

i'm currently experimenting with some mechanisms to scan visuals for audio generation. it's quite fun - but for whatever reason, it seems like Gem is applying some kind of gamma correction when i load images via [pix_image]. i'm loading this image here, which should have a neutral grey in its center - rgb (128, 128, 128) ...

... but when i display it (or work with the values in shaders), the color at its center is read as (109, 109, 109). does anyone know what the hell is going on there - and how i might avoid this?

here's the texture processed by a shader that displays its distance to neutral grey - it's obviously far from the center:

not sure if i really got the idea - but based on the previous discussion and contributions, i came up with this patch to avoid unwanted output of intermediate states:

test-evi-outputs.pd

this is rather experimental and also far from practicable (and certainly not what anyone is looking for when patching DSP stuff) - but since it came to my mind in this context, i'll leave it here anyway: with Gem, you can shift the oscillator computation to the GPU. there is an example for this in examples/10.glsl/18.additive_audio_synthesis.pd.

@jameslo said:

Woah! Look how similar my patch is and how little is missing:

haha, that really seems quite similar - and elegant.

actually, cnv-help.pd explains everything quite well! see the pd properties and pd position subpatches.
i slightly changed the color for the background cnv. so that's not completely coincidental, i admit.

maybe it's not a bad idea to check out data structures again after they received some updates with the latest pd versions! - but in this case, cnv objects with else/canvas.mouse seem to work reasonably well.

not sure this is the most elegant way - but it works:

here's the patch: reaktor-control.zip

@HannaGen said:

a pre-cooked filter for the A-weighting curve

not sure if precise enough (although the error curves look really good!) - but here is a nice source for biquad coefficients for an A-weighting filter at 44.1 and 48 kHz:
https://jenshee.dk/signalprocessing/aweighting.pdf (from https://jenshee.dk/signalprocessing/signalprocessing.html)

In Pd, at 48kHz, this translates to:

[biquad~ 1.34731 -0.349058 0.965251 -1.3473 0.382051]
|
[biquad~ 1.89387 -0.89516 0.94697 -1.89394 0.94697]
|
[biquad~ 1.34731 -0.349058 0.646665 -0.383622 -0.263043]

@morast said:

i posted the issue to the mailing list.

hi moritz! i might have missed something - but i can't seem to find a report on the pd-list?
please feel free to create an issue for this on https://github.com/pure-data/pure-data/issues (ideally with system details and the above screenshot). certainly sounds like a relevant issue.

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