when you create the gemwin, what log do you see when you set log level to 3?

is it similar to this?

[gemglfw3window]
    GLFW compile version: 3.4.0
    GLFW runtime version: 3.4.0 Cocoa NSGL Null EGL OSMesa monotonic dynamic

@y0g1 said:

pdlua script would have worked ?

yep. that would be an easy option in this case with its signal rate capabilities. currently, there's still a huge PR waiting to be merged into the official pdlua repo which also adds luajit support, increasing signal rate performance quite a bit.

anyway ... i think i ended up successfully implementing this in vanilla now:

... [pd cooldown] looks like this:

... my previous version had the main issue that cooldown reset and first impulse could overlap. it's fixed now by just using 2 consecutive 0s for the reset (and avoiding consecutive impulses for the first trigger).

this might still be way too complicated. but it seems to actually measure the impulses for 4 channels now.
here's the patch: test-cooldown-share.pd

if you'd want really exact localization, this should probably support subsample-measurements though. or at least a higher samplerate (since 1sp represents 7.15mm at 48kHz).

EDIT: the delay 100 for the snapshot is way too large here. 3ms is enough to cover the 100 samples range.
EDIT2: cleaned up the patch and comments. fixed some stuff and uses fewer objects now by reducing redundancy.

btw. this rpole~ counter for the cooldown period could possibly be simplified with just a delwrite~/delread~ ... and the whole implementation is rather crappy since it's breaking down when signals or cooldown varies too much. not sure yet how to make this more stable. hopefully might share better approaches.

here's a download link for the graph object (called show~). requires pdlua (installable through deken):

• https://github.com/ben-wes/pdlua-show_tilde/releases

... and here's the patch from above so that you don't need to patch it again from the picture if you want to check it out: test-cooldown.pd

@y0g1 said:

@ben.wes your graph is a pdlua script of yours ?

yep. I'll write another message with download link and also the patch when getting home later. currently at work. thanks for your response!

this is probably overcomplicating things quite a bit. but i tried to patch something that will let through an inital impulse and then has a cooldown before the next impulse can go through:

next step would now be to measure the times for all mics starting from the first impulse.

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

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