@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