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