• ben.wes

    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.

    posted in technical issues read more
  • ben.wes

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

    ... 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

    posted in technical issues read more
  • ben.wes

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

    posted in technical issues read more
  • ben.wes

    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:

    image.png

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

    posted in technical issues read more
  • ben.wes

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

    posted in technical issues read more
  • ben.wes

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

    posted in technical issues read more
  • ben.wes

    issue is fixed with the latest build on deken.

    posted in technical issues read more
  • ben.wes

    @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

    posted in technical issues read more
  • ben.wes

    @manuels said:

    @ben.wes Oh, I think I completely missed your point ... :laughing:

    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!

    posted in technical issues read more
  • ben.wes

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

    posted in technical issues read more

Internal error.

Oops! Looks like something went wrong!