Delay vs Pipe


    Apr 16 2022 | 11:27 pm
    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!

    • Apr 17 2022 | 6:26 am
      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."
    • Apr 17 2022 | 8:58 am
      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.
    • Apr 17 2022 | 9:10 am
      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.
    • Apr 17 2022 | 9:39 am
      OK, [pipe] wins. It also has the "stop" message to make it work like [del].
    • Apr 17 2022 | 9:41 am
      stop message is cheating.
    • Apr 17 2022 | 9:55 am
      A little caching and [del] delays any message.
    • Apr 17 2022 | 10:26 am
      and then for thread safety a [pipe 0] at the beginning, before the trigger. no wait...
    • Apr 17 2022 | 10:35 am
      No, a defer behind the [del]. But seriously, you may have a point there. I hope zl.reg ensures its thread safety internally.
    • Apr 17 2022 | 10:58 am
      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?
    • Apr 17 2022 | 11:11 am
      on windows the patch just freezes max permanently with 1 million numbers, so i cant test what´s going on.
    • Apr 17 2022 | 11:28 am
      [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.
    • Apr 17 2022 | 11:43 am
      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)
    • Apr 17 2022 | 11:48 am
    • Apr 17 2022 | 11:54 am
      cheating and symbol table bloating
    • Apr 17 2022 | 12:15 pm
      :( but less objects.
    • Apr 17 2022 | 12:17 pm
      what about using poly~ ?
    • Apr 17 2022 | 12:19 pm
      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.
    • Apr 17 2022 | 2:00 pm
      >> slower and slower yep, that makes sense.