[PD] precision of vline~ and/or pd messaging

Roman Haefeli reduzent at gmail.com
Sun Jan 29 21:31:03 CET 2012


On Sun, 2012-01-29 at 18:30 +0100, João Pais wrote:
> Hi,
> 
> another chapter in this: I just tried out the same patch, using now
> [metro] instead of Lyon's objects. The problem is that the results are
> still quite simliar, i.e. I still get clicks (almost) every 125ms (the
> beat duration), resulting from non-aligned phases.
> You can look at the attached file, get a big zoom, and look at the
> multiples of 125ms.

If you zoom not _that_ deep into it, you notice, that only a small
segment of 48 samples (?) has the completely odd phase. The continuing
part seems to align fine again. I haven't checked all the clicks, but
this applies to the few I checked.

> Was it supposed that with metro->vline the messages would go out in time,
> as I understood? The patch is too complicated for me to put it online, so
> I'll explain what it happens:

It's even more complicated to interpret the ongoings without having a
look at the patch.
 
> - a sound in an array is played in segments of (currently) 125ms
> - a metro (before Lyon's objects) sends the bangs out
> - several calculations are made to know which excerpts are played back in
> the array
> - the segments get to vline~ in the normal message form: [0, 10000 125(,
> [10000, 20000 125(, [20000, 30000 125(
>      (these are fictional values to read three fragments on a sequence)
> - vline~ goes to tabread4~

Those messages look fine to me, if the expected outcome is that 3
segments of 125ms length at different positions of the table should be
played (I think that is what you want).

> As I understood before, would the metro bangs arrive to vline~ "on time",
> so that vline's reading index doesn't get rebuffered? that doesn't seem to
> be the case of what's happening now, I think.
> I also tried changing the message from [0, 10000 125( to [10000 125(, but
> there were no differences.
> 
> 
> Or may I make the final question: is it possible to read table segments
> sequentially, whose size is different from the block size? 

Yes.

> Or does it has
> to be done with some kind of a polyphonic reader + overlapping?

Nope.

Roman





More information about the Pd-list mailing list