(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