chapelier fou

I encounter a problem in a patch and it's caused by the fact that introducing a delay filters consecutive bangs. ANy explanation ? 

button

print

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 : 


I encounter a problem in a patch and it's caused by the fact that introducing a delay filters consecutive bangs.  ANy explanation ? 
Simple 

why-is-del-filtering-multiple-bangs

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."

 see [del] reference. You can use [pipe].

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.

CF_probability_gates.amxd

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 

^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 :)

using 'pipe' like this(with 'sel 0' at its outlet) seems to work exactly as 'del' might 
with consecutive bangs for me:

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?...


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?...




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.

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. 

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. 

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. 


Why is [del] filtering multiple bangs ?