Delay vs Pipe
Greetings, I ran into something unexpected with Delay. I thought I would verify.
Say I send a bang to Delay. Then I send another bang before the delay time is expired. The first bang does not get output. We just start delaying the second bang. It looks like if Delay receives a new bang before the first delay is finished, the delay timer is reset. If this is happening on a regular interval you end up with nothing coming out of the delay.
Pipe takes bangs as well as other datstypes, and it maintains the pipeline even if a new input is received before the delay is finished.
So pipe seems strictly superior, except in cases where you want to reset the delay timer if it hasn't finished yet. I suppose there might be usecases for this. But it seems like it would be easier to manage this usecase as an attribute of pipe rather than having a whole separate object that only takes bangs.
Curious if I'm missing the point here, or if anyone has any insight into why it works this way. Thanks!
delay documentation:
"output
bang
bang received in the left inlet is delayed by the number of milliseconds specified by the right inlet, then is sent out the outlet. Only one bang at a time can be delayed by delay. If a bang is already in delay when a new bang is received in the left inlet, the first bang is forgotten."
As you've already realized, it's not about one object being superior, it's different usecases. [delay] was helpful very often for instance to wait for inactivity of something.
on older versions of max [pipe] was not even able to process symbols and lists but only numbers. so then they were actually totally different objects.
what i miss a bit is that [del] would take anything, too.
[pipe] is superior. it will be quite hard to create a patch where you add an infinite buffer to [del], but it is easy to make [pipe] work like [del] by simpling putting a timed [gate] or "onegate" behind it.
OK, [pipe] wins. It also has the "stop" message to make it work like [del].
stop message is cheating.
A little caching and [del] delays any message.
and then for thread safety a [pipe 0] at the beginning, before the trigger.
no wait...
No, a defer behind the [del]. But seriously, you may have a point there. I hope zl.reg ensures its thread safety internally.
right, a defer behind del would be the solution for all non-high priority situations.
however i think that the abuse of del as pipe is not required since you can use pipe if you need pipe.
(unless in my old version of max, where i do exactly what you suggested. zl reg is the saviour for a ton of these "object only takes ints" type of problems.)
now how would you make pipe work like del? when coll is too slow, would you do it based on zl nth and e.g. implement a size limit of 4096 or something like that?
and what would you do if the messages you need to store are of type list already?
and speaking of size limit: what is the theoretical size limit of pipe´s buffer?
on windows the patch just freezes max permanently with 1 million numbers, so i cant test what´s going on.
[pipe] isn't as flexible as it won't handle lists with different length. I'm not saying both objects are interchangeable in any case.
[pipe]'s buffer size? I have no idea. But if you don't vary the time, it wants to spit out all million numbers at once after 5000ms.
i guess you are trying to say i should have put a defer behind for that test patch... but this is in overdrive off, of course. (maybe it is just my whacky non-pro audio device)
cheating and symbol table bloating
:(
but less objects.
what about using poly~ ?
There's probably no real limit but adding more cues gets slower and slower. Then sending "stop" takes ages to clean up the buffer. I stopped at 100 000.
>> slower and slower
yep, that makes sense.