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?

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

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

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

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

pipezero.pd

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.

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

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?

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.

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.

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.

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

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

Hmmm a mystery.

@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

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.

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.

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.