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