[PD] Re: metro vs. samm~ (Frank Barknecht)
fbar at footils.org
Mon Feb 19 14:29:49 CET 2007
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
[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.
Frank Barknecht _ ______footils.org_ __goto10.org__
More information about the Pd-list