Why is [del] filtering multiple bangs ?
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 :
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."
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.
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 :)
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?...
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.
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.