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
Hallo, Eric Lyon hat gesagt: // Eric Lyon wrote:
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:
...
It's not the [metro] that is shaky in your patch, it's the [impulse~]! Attached variation proves this.
Pd's messages come in two kinds: regular, GUI-generated messages and so called "clock-derived" messages. The time objects in Pd like metro, delay, pipe etc. all generate clock-derived messages. Their timing is not affected by dsp-blocks at all.
However, and now comes the important trick: DSP objects need to do some extra work to make use of the accurate timing of clock-delayed messages, when converting these messages to audio signals. So far, the only object that does this is vline~ AFAIK. You may want to have a look at its source to check out what needs to be done to convert from control messages to signals with accurate timing. The doc-patch 3.audio.examples/C04.control.to.signal.pd has some more about this.
So the rule would be: When converting messages to audio and when timing is important, always do the conversion with vline~.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
Hallo, Frank Barknecht hat gesagt: // Frank Barknecht wrote:
Eric Lyon hat gesagt: // Eric Lyon wrote:
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:
...
It's not the [metro] that is shaky in your patch, it's the [impulse~]! Attached variation proves this.
Pd's messages come in two kinds: regular, GUI-generated messages and so called "clock-derived" messages. The time objects in Pd like metro, delay, pipe etc. all generate clock-derived messages. Their timing is not affected by dsp-blocks at all.
A little addition why I normally prefer working with [metro] and relatives: Clock-delayed messages keep their sub-sample accuracy even when you do all kinds of operations on them. This makes it easy to do various algorithmic transformations on them, like scaling periods with [*], dividing periods for polyrhythms in two or more with constructs like this:
[metro 1000] | [t b b] | | | [delay 500] | |
or the various list-operations as demonstrated in Essl's RTC-lib and so on. As long as this is converted to audio correctly with [vline~], this approach is very powerful and cheap because you don't need to calculate anything in the signal domain, until you do the final conversion to audio using vline~.
The flow of messages may also be easier to follow and understand than the rather invisible signal-clicks that [samm~] uses. Debugging is very simple and generally only involves [print] and [timer] most of the time, whereas debugging the signal domain may need a scope with [tabwrite~] and an array to see what's going on.
Ciao
Frank Barknecht _ ______footils.org_ __goto10.org__
-
Eric Lyon -
Frank Barknecht