Nicolas Bazoge

Example.maxpat

I have an input value (a number box, integer) that varies between 0 and 127. This value triggers events every time it passes through a certain value (thanks to a coll object)

If the input value modulates slowly (say as if I was turning a midi potentiometer slowly), everything is fine. But as soon as this value changes too quickly, some events do not trigger, as if some values were skipped.

Would there be a way to ensure that no numbers are skipped?

Is it related to a potential Max's internal operating clock? To the processor? Would there be a way to improve that?

I have an input value (a number box, integer) that varies between 0 and 127. This value triggers events every time it passes through a certain value (thanks to a coll object)
If the input value modulates slowly (say as if I was turning a midi potentiometer slowly), everything is fine. But as soon as this value changes too quickly, some events do not trigger, as if some values were skipped.
Would there be a way to ensure that no numbers are skipped?

Is it related to a potential Max's internal operating clock? To the processor? Would there be a way to improve that?

Thank you for your answers


 
Hi there,
I have an input value (a number box, integer) that varies between 0 and 127. This value triggers events every time it passes th

like-some-"skipped"-values-in-incoming-data

G'day Nicolas, I don't know why it happens, but this is one way to fix it (although I haven't checked it thoroughly). Cheers!

Both offered fixes will trigger more than once

and that could be a problem for the stuff that gets executed.

One could try to implement something with onebang 1 and short delay or so.

If You study the problem a bit, it gets down to mouse executed events.

Uzi output does not skip any value and will allways trigger.

If midi is received, enabling overdrive is a must.

One can go as wild as possible with real midi input,

Both offered fixes will trigger more than once
and that could be a problem for the stuff that gets executed.
One could try to implement something with onebang 1 and short delay or so.
If You study the problem a bit, it gets down to mouse executed events.
Uzi output does not skip any value and will allways trigger.

If midi is received, enabling overdrive is a must.
One can go as wild as possible with real midi input,
it will allways trigger selected value.



Thanks Double-ug and Bill. I still don't fully understand the concept behind your two solutions but in any case they seem to work perfectly for what I want to do. Thanks a lot. 

Source Audio, I'm not sure I see what you mean when you say that these two solutions will trigger more than once and that it can be a problem. The behavior I want is that the event is triggered every time the value is received, even if it's more than once.

Anyway thanks for the Overdrive option that I didn't know about and which also seems to be a great track.

Thanks Double-ug and Bill. I still don't fully understand the concept behind your two solutions but in any case they seem to work perfectly for what I want to do. Thanks a lot. 
Source Audio, I'm not sure I see what you mean when you say that these two solutions will trigger more than once and that it can be a problem. The behavior I want is that the event is triggered every time the value is received, even if it's more than once.
Anyway thanks for the Overdrive option that I didn't know about and which also seems to be a great track.

If You have no problem wenn event is triggered more than once

If triggered event was something as simple as to toggle the state of the toggle,

than it would be a trouble, don't You think so ?

If You have no problem wenn event is triggered more than once
than everything is fine.
If triggered event was something as simple as to toggle the state of the toggle,
than it would be a trouble, don't You think so ?


Like some "skipped" values in incoming data