Cool patch, Frank. Note though that by converting the click signal from samm~ into a bang, you are rounding it to the nearest vector.
Hm, I actually only used click2bang~ to be able to do measurements with [timer]. In attached patch I removed that part, so the impulses are directly recorded to samm.wav. It still is in sync with [metro].
It can only be off by the blocksize which I believe is 64 samples in the default. So, I wonder if your patch graphic shows that level of accuracy? But even in that case, it might just be lucky that they line up.
As I showed in my demo at LAC, I can make metro perform poorly in a subpatch with a very large blocksize (say 4096), but samm~ will perform the same irrespective of blocksize.
But weren't you showing this only for Max? Pd's [metro] doesn't care about the blocksize at all.
I showed it for both programs. According to my experimentation blocksize can make a big difference for metro in both Pd and MaxMSP. Please see if you have the same result:
#N canvas 795 77 454 304 10; #N canvas 537 201 482 454 shaky 0; #X obj 113 158 block~ 8192; #X obj 334 229 adsr~; #X obj 346 273 *~; #X obj 344 306 outlet~; #X obj 112 96 inlet; #X obj 236 74 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 1 1; #X obj 242 119 metro 500; #X obj 355 120 samm~ 120 1; #X obj 273 172 impulse~; #X obj 273 210 adsr~; #X obj 181 223 osc~ 440; #X obj 217 253 *~; #X obj 195 302 outlet~; #X obj 267 243 osc~ 567; #X obj 323 72 loadbang; #X msg 243 36 1; #X connect 1 0 2 1; #X connect 2 0 3 0; #X connect 4 0 0 0; #X connect 5 0 6 0; #X connect 6 0 8 0; #X connect 7 0 1 0; #X connect 8 0 9 0; #X connect 9 0 11 1; #X connect 10 0 11 0; #X connect 11 0 12 0; #X connect 13 0 2 0; #X connect 14 0 15 0; #X connect 15 0 5 0; #X restore 145 90 pd shaky; #X obj 146 143 *~ 0.1; #X obj 146 229 dac~; #X obj 211 143 *~ 0.1; #X msg 109 40 set 8192 1 1; #X msg 234 34 set 64 1 1; #X obj 214 188 *~ 1; #X obj 282 134 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 293 110 listen to samm~; #X obj 124 183 *~ 1; #X obj 100 146 tgl 15 0 empty empty empty 17 7 0 10 -262144 -1 -1 0 1; #X text 17 124 listen to metro; #X text 105 22 metro is drunk; #X text 236 15 metro more sober; #X obj 323 210 loadbang; #X msg 322 235 1 0; #X obj 323 260 unpack 0 0; #X connect 0 0 1 0; #X connect 0 1 3 0; #X connect 1 0 9 0; #X connect 3 0 6 0; #X connect 4 0 0 0; #X connect 5 0 0 0; #X connect 6 0 2 1; #X connect 7 0 6 1; #X connect 9 0 2 0; #X connect 10 0 9 1; #X connect 14 0 15 0; #X connect 15 0 16 0; #X connect 16 0 10 0; #X connect 16 1 7 0;
It is true that samm~ and friends were originally written for MaxMSP to deal with its problematic event-level timing. OTOH as my paper points out, Pd's audio thread is more susceptible to interruption from GUI events than MaxMSP.
But aren't samm~ etc. also derived from the audio thread, because they are signal externals? Then they should be just as shaky or solid as the clock-derived objects metro, delay etc., shouldn't they?
I'm not convinced that metro is accurate, rather than being rounded to somewhere within the vector. The *underlying* clock of Pd's metro is certainly as accurate as samm~ (unlike for MaxMSP) but that doesn't matter if the blocksize is too big. The one vulnerability of samm~ is if the audio stream itself is interrupted. But that should never happen unless you're doing glitch music ;-)
In addition to convenience, The benefits of samm~ come from its integration into a system of signal-level triggering, particularly with the soundfile player called player~ which I think has some nice features.
Yes, it's definitely a cool collection, and I'm glad to have it in the CVS soon. ;)
Thanks. I hope so too, but I first have to figure out how the CVS system works.
Best, Eric