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__ _______________________________________________ [email protected] mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
