@nycjacqui said:

but still can not use gemwin and DSP at the same time. whichever order i try, pd freezes.

damn. that sounds bad. i can't reproduce this here on macOS (M4, Tahoe, Version 26.5). can you give more details? does it happen for a very simple example (just a gemwin that receives create, 1)? freeze means it's still responsive, but very slow? or completely frozen? any more details welcome! hope, this can get solved!

@y0g1 said:

This signal is long, a few samples long, and I was scratching my head to find a way to turn it only into a 1 sample long impulse. It would make my life much easier.

i'm really not sure if i understand - but if it was only about that, a simple clipped derivative should be enough?

[rzero~ 1]
|
[max~]

but based on the rest of the discussion, it sounds like you want to know which mic received the first input? i assume that it's not enough to have this per block though - since some mics might have a rising edge in the block after the mic that detected first? (EDIT: when handling things on control rate)

EDIT: it should be doable though to only trigger one impulse each time after a defined "cooldown" period (not sure about the proper word here) on signal rate.

EDIT2: and if it's about counting samples from the first hit to the others and then triangulating - that should also be achievable. let me know whether i understand correctly first.

issue is fixed with the latest build on deken.

@whale-av i'm afraid that changing computer time won't have any effect. there's exactly one file on deken per system for version 0.94-snapshot. other externals preserve old versions (that become visible in deken results when the Edit->Preferences setting "Only show the newest version of a library" is unchecked). but deken didn't receive a version increment for quite a while and just overwrites previous snapshots.

it might be worth following the instructions in https://github.com/umlaeute/Gem/issues/541#issuecomment-4354638261 though.

cheers,
ben

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