[PD] Re: metro vs. samm~ (Frank Barknecht)

[Eric Lyon]

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