[PD] Sample-accurate sequencing techniques

[Mathieu Bouchard]

On Tue, 8 Feb 2011, Frank Barknecht wrote:

> This is actually an essential point: Where should people care? Simplified a
> little bit: The message realm of Pd is not quantized to block boundaries. It is
> a continuum, which is neither quantized nor sampled/discrete.

That's a little bit way too much simplified. When indexing into "big" 
tables, the float32 format is quite often a lot too quantised, which is 
why pd 0.42 introduced a new feature for making the index relative to 
another index. This has also been added to ZG.

Those big tables aren't particularly big, relatively speaking, because 
people often want tables that are that big.

> The problem with sample-accuracy in Pd occurs at the border between control
> streams and audio signals.

It also happens within the audio signal realm, as even when you control 
everything with signals, you can't go below a one-block delay in 
[delread~], and thus you have to lower blocksize or change strategies 
completely, when you need to make events tighter than that.

I mean, suppose that I sequence a click through a recursive delay line, 
for Karplus-Strong synthesis... How accurately-timed the 
recursively-processed clicks can be ?

> Personally I think, it wasn't fully true in 2006 either. (I was on the 
> review board for LAC2006, where the paper was presented, so Eric and I 
> already discussed the issue a bit.) I'm not sure where the 
> representation of events incurs glitches the audio scheduler,

It's just the possibility of making a lot of message-stuff happen between 
two block computations... Pretty much anything involving GEM pixes or GF 
grids of comparable size will take a lot of time in the CPU in the main 
thread. (For PDP, it may depend on whether threading is enabled). It's not 
specific to video, and it can happen for large matrices in iemmatrix, 
large networks in pmpd/msd, and large grids in GF that happen not to 
contain images. It's just a matter of duration of computation.

Basically, it's a feature : Pd allows to use the spare time between the 
audio blocks to do whatever you want. Thus it allows you to go over the 
time limit between blocks and this causes dropouts.

But yes, it would be a good idea to allow threading of the audio... in a 
way possibly similar to what MAX does, but I don't really know what MAX 
does with that. Maybe it's already being done (I don't know what can be 
done with the -schedlib option).

  _______________________________________________________________________
| Mathieu Bouchard ---- tél: +1.514.383.3801 ---- Villeray, Montréal, QC