Why is [del] filtering multiple bangs ?


    Dec 25 2021 | 8:14 pm
    I encounter a problem in a patch and it's caused by the fact that introducing a delay filters consecutive bangs. ANy explanation ? Simple illustration :

    • Dec 25 2021 | 8:28 pm
      see [del] reference. You can use [pipe].
      "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."
    • Dec 25 2021 | 8:59 pm
      Thanks. In my case, this won't solve the issue I'm afraid. See the [del 0] in this device. It's just aimed to allow to draw the automation more intuitively (otherwise I should draw it slightly early). The device doesn't not work properly when several notes are played at the same time : it only takes to account the highest one. Bypassing the [del] make it work with multiple notes. Replacing it with pipe doesn't work.
    • Dec 25 2021 | 9:23 pm
      using 'pipe' like this(with 'sel 0' at its outlet) seems to work exactly as 'del' might with consecutive bangs for me:
      ^does that work differently when placed within m4l/.amxd for some reason?
      also, using 'del' or 'pipe' with a constant time of '0'... just a feeling i have but... seems like one of those max-urban-legends :D... doesn't actually perform reliably as a 'tiny' defer/delay(in that case, just use 't b b l' and skip using the middle 'b'(haha, i've done this, too)... but these are all hacks... i don't think they're as effective as we think...) would a simple 'defer' or 'deferlow' work instead(somewhere along the data-flow)?
      anyways, if none of this works in the exact context, hope it at least helps get you further in the right direction :)
    • Dec 26 2021 | 12:01 am
      this (your second patch) is a completely different scenario as we thought. :) what should this [del 0] do if i may ask? make two successively incoming note events remain together in high priority? where they have never been?...
    • Dec 26 2021 | 6:03 am
      Thank you both. This [del 0] is the best way I found to ensure that clip automation is sent before the midi notes. So I can draw probability per note more intuitively. Without this, I have to set up the probability just before the note.
    • Dec 26 2021 | 2:20 pm
      erratum, it works with [pipe]. Any idea how this probability concept could effectively work on each note triggered simultaneously ? Currently, simultaneous notes are all either blocked or passed thru. I'd love that the probability would be applied to all individual notes. EDIT : nevermind, in practice, I like it like that.