anti-rush blocker, timers, overload

[tester]

As suspected - ruby crashes application in automation mode, if it receives too many triggers at once in certain looped wiring. Solution - temporal trigger blocking. Simple module like below. But there is one small problem.

While it works perfect during automation mode - after you stop playback - you need to wait over 10 seconds (on my machine) - before the "antirush" unblocks output. It appears, that too many triggers at once are queued to the timer, and this overloads the wiring.

So - can this be done differently? Some time measurement based perhaps instead of firing the timer?

[tester]

Inside the schematic - antirush3 seems to work almost as it should be. It blocks triggers during automation, it isn't overloading the timer, but...

It's interesting. When the "test plugin" is in no-automation mode (Reaper) - everything works fine. But when "plugin" has automation on array element - then even at slow clicking and "no playing" mode - very often (each 5th or so) pass-through trigger is missing... antirush v2 inside the schematic - seems to suffer from the same issue.

Any ideas how to approach it?

[tester]

4 antirush solutions. I see no way without some sort of timer or ticker.
Now it's time to check whether are there other places to place it...

[tester]

Is there a way whether changed values are coming from DAWs automation? I mean - some sort of bool indicator, when values are not changied manually, but are driven by DAW automation.

[Nubeat7]

ruby crashes application in automation mode, if it receives too many triggers at once in certain looped wiring

maybe i dont understand what you are talking about but this starts to confuse me, it looks like you are talking about a fictional problem, trojakEW couldn`t examplified any ruby crashes, and for what you are talking, a normal redraw limiter should solve it,

the preset module from the stockknob is build that it prevents triggerloops, automated data (from host) which comes out from presetparameter to knob -> from knob to presetparameter input, this triggerloop is locked with the interaction boolean and 2 triggerswitches.

when automated data comes from presetparameter primitiv, the knob is updated with a redraw limiter which shouldn`t be a problem for ruby (i never had), so where should this triggeroverload happen when you build it like this?

[Nubeat7]

Is there a way whether changed values are coming from DAWs automation? I mean - some sort of bool indicator, when values are not changied manually, but are driven by DAW automation.

would be nice but not that i know..

[tester]

When I use automation with my multifunction editbox, where values are looped back due to undo/redo system and refreshing routine (so that view match output) - on automation - it crashes. But it also crashes on automation when I blocked triggers within the editbox module, and had on output - simple text viewer, to see how the array is refreshing (forgot about redraw limiter here - maybe this caused second part of the problem).

Anyway I'm checking for some sort of universal option for limiting amount of triggers per second, that will work for both - flood of triggers coming from automation, and manual updates (user clicking, external field, and so on).

So it's a "case in progress" so to speak. But I think I found a way. I probably can combine antirush 1 with antirush 4 (limit triggers per second + blocking if triggers happen too often; first part should act as an anti-flood the timer).

*

The thing is - how to block undoredo during automation cycle.

[tester]

It appears, that "antirush 2" from template can be arranged here, to make it work fine. But I noticed interesting thing regarding Reaper. After plugin is loaded - everything works normal. After automation is set for whatever node - things work "almost normal" (sometimes some global triggers fail to pass through), but when all automation envelopes are removed - plugin's node is not released. So I'm marking this thing to investigate it somewhere in the future.