Vincent Goudard

the title of this post just refers to the (wrong) information provided in qlim.maxhelp.

I hope someone at C74 (Joshua, at random) will shed some further light on the topic, because I read 

 about ten times, but can't seem to find an answer to my issue.

OK, rather that confusing myself with obscure scheduling terms, my problem is exposed in the patcher below, and my needs are :

— How to filter out duplicated [child]event that are generated in the same [parent]event (qlim 0) ?

— What is the delay likely induced by the [qlim 0] method in the patcher attached ? Can it be measured/bounded in relation with scheduler's parameters (poll throttle, queue throttle and co) ?

 I hope someone at C74 (Joshua, at random) will shed some further light on the topic, because I read this post about ten times, but can't seem to find an answer to my issue.

OK, rather that confusing myself with obscure scheduling terms, my problem is exposed in the patcher below, and my needs are :
— How to filter out duplicated [child]event that are generated in the same [parent]event (qlim 0) ?
— What is the delay likely induced by the [qlim 0] method in the patcher attached ? Can it be measured/bounded in relation with scheduler's parameters (poll throttle, queue throttle and co) ?

qlim-is-not-like-speedlim-deferlow

Indeed, [qlim] is no [speedlim]->[deferlow], contrarily to what the [qlim] docs state.

In your example, the most important is that [speedlim 0] behaves like a patch cord. Then, [deferlow] doesn't loose any events. All of this is expected behavior. [qlim 0], on the other hand, will ignore a bunch of events:

Here is another example of [qlim]'s specificity:

qlim doesn't care about the first item coming in. Rather, it may prefer telling you twice the last bit it gets.

speedlim->deferlow has the behavior I would have expected from qlim: it gives you the first bit of information it receives, and the last, too (but not twice).

Does anybody know why? Is it a qlim feature, or poor side-effect?

qlim doesn't care about the first item coming in. Rather, it may prefer telling you twice the last bit it gets.
speedlim->deferlow has the behavior I would have expected from qlim: it gives you the first bit of information it receives, and the last, too (but not twice).
Does anybody know why? Is it a qlim feature, or poor side-effect?


Vincent, your example behaves different if max is in overdrive or not.

Also, the [speedlim]>[deferlow] is pretty inconsistent at high metro rates.

the [speedlim]>[deferlow] is pretty inconsistent at high metro rates

What do you mean? Would you have an example patch?

In my experience, [speedlim]>[deferlow] gives pretty consistent results, at least more predictable than [qlim].

For instance, with your attached patch, and a metro interval of 2 ms, speedlim>deferlow doesn't drop events, whereas qlim does, on my system (Mac).

Actually, [qlim 0] drops events on Max 6. It "seems" fixed in Max 7, but try [qlim 1] and you'll get dropped events. I assume they kind-of fixed the case "qlim 0" making it a special case similar to a patch cord, but the underlying difference between qlim and speedlim>deferlow is still there.

What do you mean? Would you have an example patch?
In my experience, [speedlim]>[deferlow] gives pretty consistent results, at least more predictable than [qlim].
For instance, with your attached patch, and a metro interval of 2 ms, speedlim>deferlow doesn't drop events, whereas qlim does, on my system (Mac).
Actually, [qlim 0] drops events on Max 6. It "seems" fixed in Max 7, but try [qlim 1] and you'll get dropped events. I assume they kind-of fixed the case "qlim 0" making it a special case similar to a patch cord, but the underlying difference between qlim and speedlim>deferlow is still there.


Here is another patch to reflect upon qlim & speedlim->deferlow. On my system, I get a different behavior in Max 6 & 7.

In Max 7, I don't manage to get events dropped, a behavior we might prefer, like it is in Max 6.

Let me know if you have any thoughts about why, and if there are other approaches, thanks.

Here is another patch to reflect upon qlim & speedlim->deferlow. On my system, I get a different behavior in Max 6 & 7.
In Max 7, I don't manage to get events dropped, a behavior we might prefer, like it is in Max 6.
Let me know if you have any thoughts about why, and if there are other approaches, thanks.


I ***STILL*** get dropped events.....8 years later...in max 8 using qlim. Typical Ableton software engineering.....

qlim is *not* like speedlim->deferlow

qlim is not like speedlim->deferlow