[PD] timing

[Michal Seta]

On Mon, Dec 20, 2010 at 7:21 PM, Dietrich Pank
<dietrich.pank at googlemail.com> wrote:
> Hi list,
> This is my first post here asking you for help.
> I built for many years in NI Reaktor (and still do). For this reason I'm
> used to handle basically 2 signal types:
> Audio - always sample rate clocked
> Event - any(!) time, even between samples

Excuse my ignorance, I have never seen NI Reactor, but what does
"between samples" mean?  I imagine the Event rate is higher than the
sample rate?

> Now I need to get to know and used to the clock and trigger "secrets" in pd.
> I want to work efficiently of course but also to be sample accurate if
> needed.

Pd, by default, does not do any computations per sample, it computes
blocks of samples.

> Beside having fun with the great freedom and logic of puredata, my aim is to
> be able to build hi quality audio stuff sooner or later...
> While building an audio scope (for e.g. debugging) I got stuck in searching
> sample exact message trigger.

The only way, AFAIK, to get sample accurate triggers is to use [bang~]
inside a subpatch that has its block size set to 1 [block~ 1 1 1].
You could probably get close to "between" samples by upsampling (i.e.
[block~ 1 1 2]) but I never tried it and the triggers will eventually
be re-aligned with the current block size...

> I wanna ask you for suggestions tips about my approach. Have a look into
> attached pd I prepared with comments here and there describing my thoughts
> and problems.
> There may be different ways to make audio scopes (I know there is one
> build-in but it only displayed useless coarse vector lines) but some
> questions I want to get answered anyhow:
> my basic questions:

in pd-extended you should be able to use [cyclone/Scope~].  Perhaps it
is less useless.

> * is it possible to get/fire precise timed messages, e.g. Metro (at least)
> Samplerate accurate?

[bang~] with [block~ 1 1 1]... except for the global block size?

> * is it possible to get sample timed events/messages, e.g. threshold what is
> far to coarse! (see attached pd)

[threshold~]'s resolution seems to be timed at millisecond intervals
which is 44.1 samples.  Perhaps a more accurate timing would be to use
[env~] inside [block~ 1 1 1] but then you would need a sample accurate
timer (I am not aware of any for Pd)

> * regarding changing block~ size:
> - my patch only accepts 64 - why?

did you use [block~] inside a subpatch?  also, the subpatch using
[block~] should not have any [inlet~] or [outlet~] objects because
they reblock the signal (see the helpfile for [block~].
Alternatively, try to start pd with -blocksize 1 but I have no idea
whether that will actually make everything sample-accurate and suit
your needs.

> - why does the $0-audioscope show extreme high amplitude when block~ size is
> <64 ?
> - makes it sense at all changing block~ size in order to get better message
> timing? Or what is it for...

As far as I understand [block~], its purpose is to compute signals
irrespective of current sampling rate/block size but anything you try
to output back into the main patch will be reblocked in accordance
with the current block size.

Perhaps someone else will have more insight into the issues you are
facing, I have rarely had a need for sample (sub sample) precise
timing.  ChucK's rationale is sample precision, CSound can do kr=sr
(control rate = sampling rate), SuperCollider can certainly do
sample-wise computations but Pd's niche is elsewhere.  Someone will
probably prove me wrong but maybe you are not looking at the right
tool for the job...

See audio.examples/G04.control.blocksize.pd.  There was also an
example of reading a sample into an an array without [soundfiler], a
faster than reatime playbackusing [block~] but I cannot locate it ATM.

HTH

./MiS