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

João Pais jmmmpais at googlemail.com
Sun Jan 29 18:30:36 CET 2012


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.

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:

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

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? Or does it has
to be done with some kind of a polyphonic reader + overlapping?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: test2.wav
Type: audio/wav
Size: 145682 bytes
Desc: not available
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20120129/39900b28/attachment-0001.bin>

More information about the Pd-list mailing list