Hello all,

I'm having a hard time to achieve the following:

I have an audio signal that is 1 for 14 samples then 0, when it's "1" I'd like to output a "1" signal, then the next sample I'd like to output zero, in order to know at which sample the change occurred.

I want to avoid using "block~" to set audio block to 1 in a subpatch, and don't want to use externals.

Anyone has a clue about how to achieve this ?

Cheers

@lacuna Actually I could even attach the patcher, it would make it easier right ?

@ben.wes

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

Hi, I missed your post, but this is the idea. get the right number of samples from first hit to the others.
( The triangulation part is already sorted )

I should maybe start a fresh topic about this, as my original question was answered.

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.

@ben.wes neat piece of code!

I'll try it, and also learn from the way you graph the signal ( it must be an else object? )

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

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

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

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.

@ben.wes I ended up writing a few externals for the "gen~" codes I wanted to translate.
Looking for a pd-vanilla way was quite instructive.

I guess some pdlua script would have worked ?
If so, I think a puredata vanilla "scripting" object would be a really nice feature...