I want to pass a value that is subject to a varying delay, so I put the delay amount in the right inlet of a [pipe] and the value into the left inlet.
What I want to know is: if the value in the right inlet is 0 will there still be any delay or is it really 0?
If I need a true 0 value then I can make something with spigot or moses to completely bypass the pipe.... but is it necessary?
-
Delay 0 and Pipe 0
-
i can confirm getting strange results from the two test patches @weightless made.
These are some results from pipezero2.pd without any changes:
spigot: 10.294
pipe: 10.313
spigot: 10.315
pipe: 10.334
spigot: 10.302
pipe: 10.322
spigot: 5.187
pipe: 5.206
spigot: 10.294
pipe: 10.314
spigot: 10.3
pipe: 10.32Notice the about 5 ms results in the middle. Similar results appear now and then in the list. i had similar results with the manual test patch. i also tested with zexy/time and got similar results.
This is Pd 0.47.1 on linux.
-
i get similar hiccups with delay:
-
Sounds like I spoke too soon, in fact my results aren't consistent at all either. Iterating the file pipezero2 500 times, and with a delay time of 10 I get results ranging from 0.122 to 19.231, and they are different every time. The mean is always around 10 (but not exactly 10) but that's not the point. Changing the delay time yields the same results of around about ±10 milliseconds. Could this be a bug?
I'm on mac with Pd 0.47.1
-
@weightless for me it seems to be a more or less constant difference of about 5 ms. metro speed does not affect this.
delay 20:
delay 60:
-
Let's hope the bug is just in realtime or it is the os that is too lazy to report the time in time.
This patch seems to indicate this, but not definitely: realtime-test.pd
For me it looks like whenever the time is exactly zero, either realtime or the os is too slow to report the actual microseconds difference. Which would be good news for the delay and pipe objects.
-
This patch seems to indicate the same: delay-test.pd
Instead of adding up, the differences roughly stay within the 5 ms margin.
For now my conclusion would be that delay and pipe are ok, but one should not rely on time measurement too much.
The source of the error could be realtime, os or hardware, which is still not determined in my view.
-
@ingox I think so too, that the object work fine. This test seems to show that the bang from [pipe 98] goes through every time (there's an offset of 1 don't know why).
-
@weightless confirmed, the delays are completely in sync: delay-test2.pd
-
Yes I get the feeling the delays are OK but [realtime] isn't!
-
@nuromantix Looks like it. I get inconsistent results with this too:
-
@weightless I think [realtime], and all the other bits are correct and "ok"...... but of course every object and every connexion has a time associated. Looking at it a few days ago I found that changing the order of connections, saving and re-opening a patch, introducing a common [bang]..... etc. all influence the scheduling.
David. -
@whale-av That's good to know!
-
the delays will always be "in sync" because they run on logical time not realtime... there is a difference between the 2
you can use [timer] to measure logical time