Delay 0 and Pipe 0

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 18:11:33 GMT

nuromantix — Fri, 21 Jul 2017 18:11:33 GMT

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?

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 18:35:38 GMT

weightless — Fri, 21 Jul 2017 18:35:38 GMT

@nuromantix Hi, I did this little test and it seems that on average the system with spigot takes longer, maybe because there are more objects in the chain.

I'd say that [pipe 0] is zero enough.

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 18:39:07 GMT

whale-av — Fri, 21 Jul 2017 18:39:07 GMT

@weightless Yes, for pipe...... tested with realtime......
David.

(v = realtime)

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 18:52:55 GMT

nuromantix — Fri, 21 Jul 2017 18:52:55 GMT

@weightless
either I am misunderstanding how [realtime] works or your patch is wrong.
I thought you bang the left input to reset the clock and then bang the right output to get the time at the end of the process, like this:

pipetest1.pd

...or am I mistaken?

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 18:55:03 GMT

nuromantix — Fri, 21 Jul 2017 18:55:03 GMT

@whale-av
I'm sorry, I don't understand your post, can you explain more simply?
thanks!

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 18:59:04 GMT

nuromantix — Fri, 21 Jul 2017 18:59:04 GMT

@weightless
in fact I am sure because your patch always returns a result of 0.002 or 0.003 even if you set del to high values!

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 19:05:35 GMT

weightless — Fri, 21 Jul 2017 19:05:35 GMT

@nuromantix Yes you're quite right, my bad. Thanks for pointing it out. This seems to be better.

pipezero.pd

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 19:10:08 GMT

nuromantix — Fri, 21 Jul 2017 19:10:08 GMT

So the spigot is quicker! Thanks for your help. That was the result I got too having just done my own test while I awaited your reply.

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 19:12:45 GMT

weightless — Fri, 21 Jul 2017 19:12:45 GMT

@nuromantix Yes, that's what I get too. Weirdly, the spigot method is quicker even when the delay is > 0, not sure why.

On the other hand, the difference is so small that for all practical purposes one might go with pipe just to avoid the extra-patching, but that depends on the patch of course. Good to know though.

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 19:18:28 GMT

nuromantix — Fri, 21 Jul 2017 19:18:28 GMT

My next question is: why is pipe so unreliable?
Using my tests and yours, something like [pipe 9] returns a realtime value between 10.3 and 11.3 most of the time, and I guess that the extra 2ms is caused by the rest of the patch.
But about 1 time in 5, the value returned is close to 0.
Why is that?

Reply to Delay 0 and Pipe 0 on Fri, 21 Jul 2017 19:58:11 GMT

LiamG — Fri, 21 Jul 2017 19:58:11 GMT

There's a section in the Theory of Operation [delay 0]. From memory, it still happens in logical 0 time, but breaks the order of operations.

Reply to Delay 0 and Pipe 0 on Sat, 22 Jul 2017 04:55:38 GMT

seb-harmonik.ar — Sat, 22 Jul 2017 04:55:38 GMT

Just to talk about the logical time (perhaps it's helpful?):
Pure data uses a linked list as a scheduler. When a block is resolved, events from the gui and previous delays trigger the functions in objects. In the case of [delay 0] or [pipe 0], the thing that triggers the clock callback to start (like a bang) puts it on the scheduling list at the same logical time that the bang came in, but after everything else that was already scheduled for the same logical time and everything that is executing through function calls between objects
when you are within the execution flow due to a specific trigger (number, bang, whatever) the rest of that flow of execution is resolved before anything else happens
So, passing it through without going through [delay 0] or [pipe 0] is "faster" from the perspective of logical time because it will happen immediately and before the clock callback.
This would explain the "realtime" tests. things that the program executes later will take longer from when they're triggered, though it's mainly because they are later on the scheduling list. However, it might also be true that scheduling something in [pipe] is more cpu-intensive than the logic it takes to avoid it.
Also, pipe is probably a bit more cpu intensive than delay as it has to keep a linked list of clocks and stuff it's delaying.

Reply to Delay 0 and Pipe 0 on Sat, 22 Jul 2017 07:05:38 GMT

nuromantix — Sat, 22 Jul 2017 07:05:38 GMT

Thank you.
But why in the tests above, with a positive value for the delay time of the [pipe] does it seem to fail to delay the input quite often?
ie. with a delay value of 9 we see realtime delays of 10 or 11ms usually, but sometimes less than 1 ms.

Reply to Delay 0 and Pipe 0 on Sat, 22 Jul 2017 14:16:32 GMT

seb-harmonik.ar — Sat, 22 Jul 2017 14:16:32 GMT

I'm not seeing the less than 1 ms times with a delay of 9 on my computer.
for me it's
print: 10.458
print: 10.18
print: 10.182
print: 8.841
print: 8.831
print: 8.815
etc..

Reply to Delay 0 and Pipe 0 on Sat, 22 Jul 2017 15:05:17 GMT

weightless — Sat, 22 Jul 2017 15:05:17 GMT

@nuromantix I think the example patch was just for testing purposes. If you send a fast stream of numbers through that, pipe's outputs (which is delayed from the numberbox), is not going to trigger realtime necessarily after the specified delay time, especially if the input stream is faster than the delay time, unless you link the input with pipe's output somehow and use multiple realtime objects.

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 07:18:04 GMT

nuromantix — Mon, 24 Jul 2017 07:18:04 GMT

Hmmm a mystery.

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 07:49:41 GMT

weightless — Mon, 24 Jul 2017 07:49:41 GMT

@nuromantix You can check it yourself if you get the same behaviour. I get consistent results as long as the metro is higher than the pipe time, whereas with a metro time lower than the pipe I get the close to zero stuff.

pipezero2.pd

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 13:07:45 GMT

seb-harmonik.ar — Mon, 24 Jul 2017 13:07:45 GMT

the whole point of using pipe is that you can store multiple things in it and it will output them after a time delay. So, if you put in 2 things a certain amount of time apart they will show up in the output the same time apart.

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 14:09:27 GMT

ingox — Mon, 24 Jul 2017 14:09:27 GMT

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.32

Notice 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.

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 14:20:26 GMT

ingox — Mon, 24 Jul 2017 14:20:26 GMT

i get similar hiccups with delay:

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 14:28:25 GMT

weightless — Mon, 24 Jul 2017 14:28:25 GMT

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

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 15:01:39 GMT

ingox — Mon, 24 Jul 2017 15:01:39 GMT

@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:

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 15:20:03 GMT

ingox — Mon, 24 Jul 2017 15:20:03 GMT

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.

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 15:45:49 GMT

ingox — Mon, 24 Jul 2017 15:45:49 GMT

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.

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 16:09:59 GMT

weightless — Mon, 24 Jul 2017 16:09:59 GMT

@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).

Reply to Delay 0 and Pipe 0 on Mon, 24 Jul 2017 16:25:19 GMT

ingox — Mon, 24 Jul 2017 16:25:19 GMT

@weightless confirmed, the delays are completely in sync: delay-test2.pd

Reply to Delay 0 and Pipe 0 on Tue, 25 Jul 2017 07:22:11 GMT

nuromantix — Tue, 25 Jul 2017 07:22:11 GMT

Yes I get the feeling the delays are OK but [realtime] isn't!