hi the delay~ object steps in values of the vectorsize. (with 64 samples vectorsize possible values are 1.4 ms, 2.8 ms, ... if you put the delay in a "block~ 1" subwindow then your smallest delaytime is 1 sample (0.023 ms, 0.045 ms, ...)
to check your current samplerate~ you could use the samplerate~ object which gives you the sr, when sending bang. marius.
Am Samstag, 12. Januar 2002 00:50 schrieb Larry Troxler:
Hi, I'm getting some dissapointing behavior from the "delay" object. Even though I am using the real-time-patched kernel from Planet CCRMA (this is on Linux, BTW), it seems that my delay values (+/- some jitter) are only quantized to 10ms.
I would have expected that PD uses the rtc device and hence would not depend on the kernel's HZ resolution, but apparently this isn't so(?)
This brings to mind the following questions:
- Is it the case that just this delay object doesn't use the rtc
device, or is it the case that nothing in PD uses the rtc device?
- (Not really a PD question) If the answer question 1A is no, then that
means that the Planet CCRMA real-time kernel still uses a 100Hz HZ value, right? I'm kind of surprised at this, unless using larger HZ values breaks some drivers or something.
Best Regards
Larry Troxler
Test patch below :
#N canvas 0 0 450 300 10; #X obj 26 16 bng 15 250 50 0 empty empty empty 20 8 0 8 -262144 -1 -1; #X msg 22 50 1; #X obj 24 148 realtime; #X floatatom 30 190 0 0 0; #X obj 22 77 metro 1000; #X obj 81 112 delay 5; #X connect 0 0 1 0; #X connect 1 0 4 0; #X connect 2 0 3 0; #X connect 4 0 2 0; #X connect 4 0 5 0; #X connect 5 0 2 1;