Hi,
I'm trying to trigger [print~] every sample. in the same patch I'm using [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger [print~].
but I noticed that [print~] is yes printing 1 sample at time (in accord with the block size) but only every 64 samples. so it receives a bang every sample but prints every 64 (default block size).
can you guys help me understanding why? I'm pretty sure I'm missing something here :D
cheers,
Mario
the technical reason is that clock timeouts can't happen in intervals smaller than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks (e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work as expected.
Christof
*) more generally, clock timeouts are limited to the largest parent blocksize. see attached patch.
Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr Von: "mario buoninfante" mario.buoninfante@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] triggering [print~] faster than every 64 samples
Hi,
I'm trying to trigger [print~] every sample. in the same patch I'm using [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger [print~].
but I noticed that [print~] is yes printing 1 sample at time (in accord with the block size) but only every 64 samples. so it receives a bang every sample but prints every 64 (default block size).
can you guys help me understanding why? I'm pretty sure I'm missing something here :D
cheers,
Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Christof,
thanks for that, this clarifies quite a lot of things. that said it seems that objects like [del] and [pipe] can deal with this kind of situations (ie [del 1 10 samp]). the "issue" seems to appear when you start using "hybrid" objects (control signal to audio signal or the other way around). am I right assuming that?
cheers,
Mario
On 28/07/18 10:43, Christof Ressi wrote:
the technical reason is that clock timeouts can't happen in intervals smaller than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks (e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work as expected.
Christof
*) more generally, clock timeouts are limited to the largest parent blocksize. see attached patch.
Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr Von: "mario buoninfante" mario.buoninfante@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] triggering [print~] faster than every 64 samples
Hi,
I'm trying to trigger [print~] every sample. in the same patch I'm using [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger [print~].
but I noticed that [print~] is yes printing 1 sample at time (in accord with the block size) but only every 64 samples. so it receives a bang every sample but prints every 64 (default block size).
can you guys help me understanding why? I'm pretty sure I'm missing something here :D
cheers,
Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Mario,
you're right, [del], [pipe] (and [metro] btw) themselves are unproblematic because clocks are timestamped (and therefore [timer] will show the correct logical time). the problem really lies in the conversion from/to audio, as you noted correctly.
for the sake of completeness:
with every scheduler tick, Pd checks for clock timeouts, polls the GUI and does 64 samples of DSP computation. now let's say a canvas has [block~ 256]: in the first 3 schedular ticks nothing happens expect for [inlet~] buffering, only at the 4th tick we actually do the 256 samples of DSP. but this means that clock timeouts can only happen before those 256 samples - not in between! still, clock timeouts happen at the same "rate" as DSP computation. now imagine this canvas has a subcanvas with [block~ 64]: everytime the parent canvas (256 samples) is processed, the subcanvas (64 samples) gets processed 4 times in a row and clock timeouts effectively only happen every 4 blocks. but this means DSP computation and clock timeouts are out of sync and even sub-sample correct objects like [vline~] might behave strangely.
eventually, the number of samples between clock timeouts for a canvas and all its subcanvasses is determined by the largest blocksize within the list of parent canvasses.
[block~ 1] on a root canvas is just the simple case where the parent blocksize equals the schedular tick size of 64 samples.
Christof
Gesendet: Samstag, 28. Juli 2018 um 11:50 Uhr Von: "mario buoninfante" mario.buoninfante@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-List pd-list@lists.iem.at Betreff: Re: Aw: [PD] triggering [print~] faster than every 64 samples
Hi Christof,
thanks for that, this clarifies quite a lot of things. that said it seems that objects like [del] and [pipe] can deal with this kind of situations (ie [del 1 10 samp]). the "issue" seems to appear when you start using "hybrid" objects (control signal to audio signal or the other way around). am I right assuming that?
cheers,
Mario
On 28/07/18 10:43, Christof Ressi wrote:
the technical reason is that clock timeouts can't happen in intervals smaller than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks (e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work as expected.
Christof
*) more generally, clock timeouts are limited to the largest parent blocksize. see attached patch.
Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr Von: "mario buoninfante" mario.buoninfante@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] triggering [print~] faster than every 64 samples
Hi,
I'm trying to trigger [print~] every sample. in the same patch I'm using [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger [print~].
but I noticed that [print~] is yes printing 1 sample at time (in accord with the block size) but only every 64 samples. so it receives a bang every sample but prints every 64 (default block size).
can you guys help me understanding why? I'm pretty sure I'm missing something here :D
cheers,
Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
Hi Christof,
thanks a lot for this :D in the meanwhile I looked at Miller Puckette's book, and in fact what you described is reported also there.
thanks for your explanation.
cheers,
Mario
On 28/07/18 12:58, Christof Ressi wrote:
Hi Mario,
you're right, [del], [pipe] (and [metro] btw) themselves are unproblematic because clocks are timestamped (and therefore [timer] will show the correct logical time). the problem really lies in the conversion from/to audio, as you noted correctly.
for the sake of completeness:
with every scheduler tick, Pd checks for clock timeouts, polls the GUI and does 64 samples of DSP computation. now let's say a canvas has [block~ 256]: in the first 3 schedular ticks nothing happens expect for [inlet~] buffering, only at the 4th tick we actually do the 256 samples of DSP. but this means that clock timeouts can only happen before those 256 samples - not in between! still, clock timeouts happen at the same "rate" as DSP computation. now imagine this canvas has a subcanvas with [block~ 64]: everytime the parent canvas (256 samples) is processed, the subcanvas (64 samples) gets processed 4 times in a row and clock timeouts effectively only happen every 4 blocks. but this means DSP computation and clock timeouts are out of sync and even sub-sample correct objects like [vline~] might behave strangely.
eventually, the number of samples between clock timeouts for a canvas and all its subcanvasses is determined by the largest blocksize within the list of parent canvasses.
[block~ 1] on a root canvas is just the simple case where the parent blocksize equals the schedular tick size of 64 samples.
Christof
Gesendet: Samstag, 28. Juli 2018 um 11:50 Uhr Von: "mario buoninfante" mario.buoninfante@gmail.com An: "Christof Ressi" christof.ressi@gmx.at Cc: Pd-List pd-list@lists.iem.at Betreff: Re: Aw: [PD] triggering [print~] faster than every 64 samples
Hi Christof,
thanks for that, this clarifies quite a lot of things. that said it seems that objects like [del] and [pipe] can deal with this kind of situations (ie [del 1 10 samp]). the "issue" seems to appear when you start using "hybrid" objects (control signal to audio signal or the other way around). am I right assuming that?
cheers,
Mario
On 28/07/18 10:43, Christof Ressi wrote:
the technical reason is that clock timeouts can't happen in intervals smaller than 64 samples (pd's scheduler blocksize) *), so any objects relying on clocks (e.g. [print~], [bang~], [line~], [vline~], [del], [pipe], etc) might not work as expected.
Christof
*) more generally, clock timeouts are limited to the largest parent blocksize. see attached patch.
Gesendet: Samstag, 28. Juli 2018 um 10:45 Uhr Von: "mario buoninfante" mario.buoninfante@gmail.com An: Pd-List pd-list@lists.iem.at Betreff: [PD] triggering [print~] faster than every 64 samples
Hi,
I'm trying to trigger [print~] every sample. in the same patch I'm using [block~ 1 1 1] to change the block size and [metro 1 1 samp] to trigger [print~].
but I noticed that [print~] is yes printing 1 sample at time (in accord with the block size) but only every 64 samples. so it receives a bang every sample but prints every 64 (default block size).
can you guys help me understanding why? I'm pretty sure I'm missing something here :D
cheers,
Mario
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Christof Ressi -
mario buoninfante