Hi,
Can we go below a blocksize of 64 ?
I have been trying with pd0.34-4 and 0.34-2-updown without success.
Basiclly i count the number of bang from a bang~ object during 1 second and still get 750, which is well 48000/64, but even with blocksize of 32 and less.
Any hints ?
Linium
Well, you've hit on a major weakness of Pd's scheduler. The block size can go all the way down to 1 (check it out using print~ for example)... BUT ... control computations only occur at intervals of 64 samples. So bang~, which sets a delay so as to schedule a (message/control time) bang, might schedule it 64 times in a 64-sample period, but at the end of the show, only one of the 64 comes out.
I wish I knew a better way to interleave control and DSP scheduling, but so far, the best I can come up with is to have the grain at which control passes back and forth be a global quantity. In Pd it's arbitrarily set to 64...
cheers Miller
On Fri, Apr 26, 2002 at 07:24:25PM +0200, intent wrote:
Hi,
Can we go below a blocksize of 64 ?
I have been trying with pd0.34-4 and 0.34-2-updown without success.
Basiclly i count the number of bang from a bang~ object during 1 second and still get 750, which is well 48000/64, but even with blocksize of 32 and less.
Any hints ?
Linium
Hi,
I made another discovery connecting the output of "env~" then "line" to a bang message and counting them during 1 second.
I get 93 bangs for "env~" and 50 for "line".
But i don't understand, it cannot be 20 ms update time for "line" since we are doing ADSR with it (?)
Linium
Le Samedi 27 Avril 2002 00:25, Miller Puckette a écrit :
Well, you've hit on a major weakness of Pd's scheduler. The block size can go all the way down to 1 (check it out using print~ for example)... BUT ... control computations only occur at intervals of 64 samples. So bang~, which sets a delay so as to schedule a (message/control time) bang, might schedule it 64 times in a 64-sample period, but at the end of the show, only one of the 64 comes out.
I wish I knew a better way to interleave control and DSP scheduling, but so far, the best I can come up with is to have the grain at which control passes back and forth be a global quantity. In Pd it's arbitrarily set to 64...
cheers Miller
hi,
intent wrote: ...
I made another discovery connecting the output of "env~" then "line" to a bang message and counting them during 1 second.
I get 93 bangs for "env~" and 50 for "line".
[env~ <nanalysis> <noutperiod>] <nanalysis>: number of samples used for analysis (default: 1024) <noutperiod>: number of samples between successive output points (default: <nanalysis>/2)
[line <grain>] <grain>: time between successive output points (default: 20 ms)
But i don't understand, it cannot be 20 ms update time for "line" since we are doing ADSR with it (?)
`we' use line~
Krzysztof
Le Lundi 29 Avril 2002 09:56, Krzysztof Czaja a écrit :
[line <grain>] <grain>: time between successive output points (default: 20 ms)
Well, in pd 0.34 the grain argument is the second one:
line <x> <grain>
I don't know what is x, should be the time to jump on the new value but i can't yet see any effect ... It can be a bug too since the doc doesn't talk about 2 arguments ?
But i don't understand, it cannot be 20 ms update time for "line" since we are doing ADSR with it (?)
`we' use line~
I know but there are some objects that take control rate as input (like some ladspa plugins) and since i was not finding a way to change the grain rate...
Thx a lot,
Linium
hi,
sorry, my mistake -- and also the help patch is wrong! -- line arguments are in Pd just like they are in max:
[line <initial-value> <grain>]
Krzysztof
intent wrote: ...
Well, in pd 0.34 the grain argument is the second one:
line <x> <grain>
I don't know what is x, should be the time to jump on the new value but i can't yet see any effect ... It can be a bug too since the doc doesn't talk about 2 arguments ?