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.