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

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

 Frank Barknecht                 _ ______footils.org_ __goto10.org__

More information about the Pd-list mailing list