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;
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;
marius schebella hat gesagt: // marius schebella wrote:
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, ...)
A good example is 73.control.blocksize.pd, which features a karpus-strong-like pluck instrument. Here you need the smallest possible blocksize, otherwise your pluck instrument will go out of tune in higher notes because of the possible delay time being too short, if you don't block~ the delay window to 1.
bye,
__ __
Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______
/ __// __ /__/ __// // __ \ / / __ \ ___\
/ / / ____/ / / / // ____// /\ \ ___\____ \
/_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
Frank Barknecht hat gesagt: // Frank Barknecht wrote:
karpus-strong-like pluck instrument. Here you need the smallest possible blocksize, otherwise your pluck instrument will go out of tune in higher notes because of the possible delay time being too short, if you don't
not too short, I meant too long.
block~ the delay window to 1.
/_/ _\
Small correction... delay~ is quantized to teh sample, but the minimum delay is the block size; so you can get on of 65 samples for example. the vd~ object only goes down to 65 samples (needs an extra point for interpolation) but isn't quantized at all.
cheers Miller
On Sat, Jan 12, 2002 at 12:42:03PM +0100, Frank Barknecht wrote:
marius schebella hat gesagt: // marius schebella wrote:
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, ...)
A good example is 73.control.blocksize.pd, which features a karpus-strong-like pluck instrument. Here you need the smallest possible blocksize, otherwise your pluck instrument will go out of tune in higher notes because of the possible delay time being too short, if you don't block~ the delay window to 1.
bye,
__ __Frank Barknecht ____ ______ ____ __ trip\ \ / /wire ______ / __// __ /__/ __// // __ \ / / __ \ ___\ / / / ____/ / / / // ____// /\ \ ___\____ \ /_/ /_____/ /_/ /_//_____// / \ \_____\_____
/_/ _\
I'm experiencing weird behaviour on a win98(se) laptop.
I have pd 0.34 running in the same set-up as my win2k machine, that is with zexy, gem, iemlib, etc., with virtually no problem at all except for the following: if I double-click or control-click a pd object to see a subpatch, PD crashes automatically. I have tried with a brand new install of the most recent version of PD, with no libraries and I'm always getting the same problem.
Does anyone have a clue why this is happening, or experienced similar problems? I'm a bit puzzled as to why this only happens with the pd object, especially considering that everything else is working as expected.
Thanks!
- martin
Yes!!!!
I've found a *lot* of strange problems with PD running under 98/95 and ME. I have has that specific problem with subpatches exactly. Also I could not get the expr object to work on ME and then all of a sudden one day it did. Works great on win2k and linux though. I'll have to double check but I think its works as well in XP as 2000.
I use 2000 at home, but tried to use PD under 98 at school. Any reason why you have to use 98 on the laptop?
I'm runing PD.35 and GEM .86 using NVidia drivers under linux and blackbox. So I get video out without window decorations (I turn them off in blackbox) the only problem was getting sound drivers to work!!! (just stay away from redhat)
Ben
On Sun, 13 Jan 2002, Martin Dupras wrote:
I'm experiencing weird behaviour on a win98(se) laptop.
I have pd 0.34 running in the same set-up as my win2k machine, that is with zexy, gem, iemlib, etc., with virtually no problem at all except for the following: if I double-click or control-click a pd object to see a subpatch, PD crashes automatically. I have tried with a brand new install of the most recent version of PD, with no libraries and I'm always getting the same problem.
Does anyone have a clue why this is happening, or experienced similar problems? I'm a bit puzzled as to why this only happens with the pd object, especially considering that everything else is working as expected.
Thanks!
- martin
B. Bogart
i have this problem also (been happening for a while). Only when i load pd with GEM, though. I guess it's something to do with GEM PD ineraction. started happening after 0.34
----- Original Message ----- From: "Martin Dupras" martin.dupras@uwe.ac.uk To: pd-list@iem.kug.ac.at Sent: Sunday, January 13, 2002 4:05 PM Subject: [PD] win98 crash when clicking on pd object
I'm experiencing weird behaviour on a win98(se) laptop.
I have pd 0.34 running in the same set-up as my win2k machine, that is
with
zexy, gem, iemlib, etc., with virtually no problem at all except for the following: if I double-click or control-click a pd object to see a
subpatch,
PD crashes automatically. I have tried with a brand new install of the
most
recent version of PD, with no libraries and I'm always getting the same problem.
Does anyone have a clue why this is happening, or experienced similar problems? I'm a bit puzzled as to why this only happens with the pd
object,
especially considering that everything else is working as expected.
Thanks!
- martin
Ahh, thanks everyone!
As it turns out, my problem was in my test patch, and [delay] does work to the nearest 64 samples, as I verified by using a [tabwrite~] and toggling values to [sig~]. I was lead astray by the use of the [realtime] object to meaure the delay.
What happens, is that the realtime object measures exactly that (as we would hope!). Hence that object *does* get blocked for what I assume is the time between writing to the DAC, and the time the next output buffer gets ready to be written. So, the PD application does have this jitter, but that doesn't mean that the delay isn't correct, because PD messages get activated not in real time but several times (DAC-buffer-size/PD-block-size?) in the course of generating an output buffer to write to the DAC.
Hope I explained that clearly enough.
Larry
-
Ben Bogart - FMPM/F1999 -
Frank Barknecht -
Larry Troxler -
marius schebella -
Martin Dupras -
mick grierson -
Miller Puckette