Hi PD community!

I have this "simple" idea (in quote yes) that it would be "easy" (in quote also) to compare 2 metronome audio signal (similar but not identical) in pd: 1 source ADC1 and another metronome on ADC2. I need to get the latency between the 2, or the syncness (if this term exist in english) between source 1 and source 2. So maybe they are 20ms apart (+ or - would be fantastic but would be happy with just + for now).

It's not for testing my soundcard round-trip latency (for that I am using the excellent patch from Katja). I want to jam with someone and we are using ableton link pd external - we can manage the offset by ear, but would like to have the exact MS.

Found this python library, but it works with a specific sound signal, I have in mind a more relax metronome signal (ie coming from a midi drum machine (snare, hihat x3)).

I have a feeling that a patch like that is already coded...
Thanks!

I don't have a great answer but it made me wonder if you've seen William Brent's new project OUTPUT? https://github.com/wbrent/OUTPUT

I believe he's using JackTrip to jam online.
https://github.com/jacktrip/jacktrip/releases/tag/v1.4.0-rc.5

@EEight There is more info from Miller about solutions (and possible problems) using Jacktrip ........ http://msp.ucsd.edu/tools/quacktrip/doc.htm in Pd, although it is for jamming over the web/network.......
Not sure where these came from, and they are for windows I think, but the patches and readme give some indications......
quack-and-netty-0.92-patches.zip
Quacktrip-pc-vst3-0.92.zip
David.

@EEight Just curious--suppose the metronomes are at 120 BPM, i.e. 500 mS between clicks. If a patch were to see a 5 mS offset, how would it know it's not really 505 mS, or 495 mS?

Really basic implementation, just as a POC. I will test soon.

@jameslo In my mind, adc~ 1 is the master metronome (for example, an old drum machine that you cannot offset the clock). adc~ 2 is another metronome but this one you can offset the clock (ie: ableton link~, midi clock with offset).

So if adc~ 2 metronome click is before adc~ 1, I will get a huge offset in ms (ie 455), but if adc~ 2 click is just after adc~ 1 click (by ear), then I will know but how much I need to adjust the offset (ie: 20ms). That's the theory.

I need to have a look at jacktrip / quacktrip, but without fiber, the latency is simply too high ~50ms. I know that some people said that with 5G it would be possible, well... time will tell. For now, I am using ninjam (not realtime, offset).

@EEight OK, this is probably insane overkill: metronome timer.pd

I only fed it one metronome @ 120 BPM into both channels, so that's why the high side time is 35 seconds. But my untested theory is that you will get both the lag and lead times.

Update: Made a few changes and tested it with 2 physical metronomes @ 130 BPM close mic'd with omnis in my noisy apartment. I had to futz with it a while to get clean rectangular pulses in array2. Note that the lead and lag times add up to the period of 130 BPM as hoped. It's probably still insane overkill though. metronome timer.pd

@jameslo Thank you so much!! I will test your solution soon. Overkill? I don't think so, well implemented (and vanilla) for the win. Cheers~

@EEight Oh good! Well when you test it, you might want to fix the cutoff freq on the right, plus add a metro bang to update the arrays. The latter really helps when you're adjusting level and threshold in order to get a clean rectangular pulse out of novelty metronomes (e.g. my phone app has a duck sound).