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__