Custom Redraw Limiter (new)

[Perfect Human Interface]

EDIT:

This thread is being recycled!

I created a "custom redraw limiter" from a different approach. Still using a modified Ruby ticker. This one checks if the input value has changed and activates a ticker if it has, then after a short buffer shuts off if the input is no longer changing.

In effect, it can set redraw rate (or other update rate) from a continuously changing value to whatever you specify, and doesn't waste cycles on a ticker while the value is static. It's quite accurate as best I could test it; should be close enough for any redraws.

I think this one will be actually quite useful! Feel free to prove me wrong though.

The Ruby isn't super lightweight but the idea behind creating this is that the stock "redraw limiter" limits triggers to around 90/second and I find that to be too much. So even if you wanted 60 redraws/second, that's 50% fewer redraws, and if you're drawing a lot that can make a big difference. Ultimately, this module gives you control to set your redraw rate to whatever you like.

Edit again:
Ahg, keep having this problem with the ruby code seizing up. To get it working again you need to type "@ticking = true" then delete that then switch the thing off and on again. I don't know why it does this or how to fix it. Anyone?

[Tronic]

I would like to bring to light some information regarding the Ruby especially in the situation of generation Trigger:
Any ruby edit using a class "RubyEditConnector"
it seems to provide all the links (the famous spaghetti) to the ruby edit panel, regenerate the class for each GUI Thread refresh, with a circular buffer in internal FS where it stores the data of the connectors, and then writes and reads continuously from memory, it seems much affect on performance, for example, each time you use the method "output" or "input" it uses a new instance of the class said above.

So when you run a loop between in and output, you'll notice a massive increase in the use of CPU and memory, while if a Trig is passed between Ruby Edit panels, without the link (always the famous spaghetti), you will notice that the CPU remains quiet, because they do not generate continuously Classes "RubyEditConnector."
The conclusion is that passing data between a Ruby Edit panels with no links, everything seems to be more efficient.

[Perfect Human Interface]

I'm trying to follow you Tronic but not entirely sure I do. Are you basically just saying to use "output" and "input" as infrequently as possible since they suck CPU? I just modified the existing Custom Ticker to make this so I'm not sure how else to do it.

--edited out no longer relevant content--

[Perfect Human Interface]

Updated first post! New thing; hoping this is actually useful.

[tulamide]

To shed some light on the 'redraw trigger'. It has a different purpose than contantly reducing to a set rate. From the old forum, where Malc explained it in detail:

"I think the issue here is the description for the Redraw Limiter (which is not the best) so I'll try and explain this in more detail.

The Redraw Limiter has a very specific purpose. It was introduced to provide a mechanism for limiting the amount of GUI processing done during automation in an exported plugin.

Automation changes come into a schematic via the VST Parameter and VST Parameter Array primitives. In most cases the values these send out will send triggers out through parts of the schematic whose only purpose is to do calculations that relate to updating the GUI (a knob position say) in order to reflect the change in value.

We found that in some hosts the rate at which automation data is sent is very high. This results in GUI processing to be done at a far greater rate than is needed which significantly reduces performance. The Redraw Limiter was added to control the rate of GUI related triggers during these automation events. So when automation is in progress, instead of just letting the triggers through, they are limited to a maximum rate of 100Hz. If automation is not in progress the triggers just pass through.

We subsequently realised that MIDI CC can also present the same sorts of issues so the Redraw Limiter also comes into play during MIDI CC as well.

Another facet of the Redraw Limiter is that it completely blocks triggers when the plugin window is closed in a host and also during preset changes (although note that a full redraw is done after changing preset to reflect the changes made).

So I think the description needs to be revised. This might need some refining but I would propose something along the lines of the following:

"Controls the rate at which triggers pass through during automation, MIDI CC and preset change events so as to keep GUI related processing at an acceptable level. Note that no triggers will pass through if the plugin window is not visible""

In this context, it makes even sense that it limits to a maximum of 100Hz. That doesn't affect the usefulness of your trigger limiting idea. I post it just to clarify the intended use of that 'redraw limiter' prim.

[Nubeat7]

..the stock "redraw limiter" limits triggers to around 90/second and I find that to be too much. So even if you wanted 60 redraws/second, that's 50% fewer redraws, and if you're drawing a lot that can make a big difference.

use the trigger divider that's just one primitive...

[Perfect Human Interface]

In this context, it makes even sense that it limits to a maximum of 100Hz. That doesn't affect the usefulness of your trigger limiting idea. I post it just to clarify the intended use of that 'redraw limiter' prim.

Sure. This will effectively do the very same things, except instead of limiting to 90 hz or so (which is unnecessarily much in many cases), it will limit to X hz. That was the purpose in this design. It will also block updates when the input value has not changed, even if triggers are still being received (in the example uploaded you'll notice the knob still sends triggers while you drag down even if it's already at 0). And as a final note, since it's based on the Ruby ticker, this may output triggers with better timing (less jitter).

So, I believe this has a lot of benefit. The downside is that it will probably take more CPU while running than any primitive, but I believe the net gain in being able to limit redraws to lower rates will be positive in many cases. And isn't that what we'd all like?

This is all assuming of course I can figure out that bug (any help there would be greatly appreciated!).

use the trigger divider that's just one primitive...

This is a good suggestion. And to be honest I thought you were bonkers for a second, but then I realized you meant use it in conjunction with the stock redraw limiter.

Trog made what was basically a green version of what I've built here using this concept you mention. I imagine it's significantly easier on CPU. The problem with it is that you can only choose from a few set rates, and they're very inaccurate. You have "100, 50, 33, 25" and the "50" might be like 40 triggers per second or less. With my module, you type in 60, you get 60 per second.

[Nubeat7]

here are some examples to limit triggers, also with a working ruby ticker used to limit triggers... after you convert to green again the accuracy of the ruby ticks are getting "green washed" anyway but you can set whatever rates you like..

[Perfect Human Interface]

Your custom trigger limiter is very good. It's similar to my first Ruby attempt except it's more green and actually accurate (wondering if the interaction between green and Ruby in general might be a little funky). Some differences I note between it and mine:

-Yours reacts to every trigger received while mine only reacts if the value has changed
-Yours runs the ticker constantly (while the editor is open) while mine stops it whenever input isn't changing
-Yours can potentially put out much fewer triggers if the triggers going into it are less than the "limit" value (mine keeps running at the set rate for at least a 3 step buffer)

Wondering if I might be able to marry the two.

EDIT-

Here it is! Like Nubeat's example and mine combined, this one can switch between reacting to every trigger or only if the input value is changed, stops the ticker after a short timeout, and does not put out excess triggers when input rate is lower than the limiting rate.

It's also pretty darn accurate and doesn't have the bug my original had. The first trigger timing is actually more accurate than Nubeat's example (observable if you set the trig/sec to a low value such as 1). It loses accuracy past 200+ triggers per second (depends on the length of the timeout buffer in the ruby code) but you probably shouldn't be running it that fast anyways.

Uploaded schematic includes Nubeats and the new one I've modified in a testing configuration. Let me know what you think!

[Nubeat7]

-Yours reacts to every trigger received while mine only reacts if the value has changed
-Yours runs the ticker constantly (while the editor is open) while mine stops it whenever input isn't changing

both are good points specially the second one, because the ruby ticker really sucks cpu specially with fast rates but also with slower ones..

i fixed both things just with green, because its pretty easy to do..

anyway i wouldn't go this way in general, i think if you use this kind of redraw limiting you don't use the ticker itself on every knob, its better to have a 'global' redraw ticker and send its ticks to every knob, so it makes no sense to turn the ticker on and off with valuechanges...

furthermore i would assume to use a 25 tick or 100 tick with dividing for different rates for the global redraw ticker, like you know it from some examples in the SM forum, simply because the 25 tick and the 100 tick have much better performance then the ruby ticker!

on my very slow testnotebook the ruby ticker shows 4% cpu with 50 ticks /sec and 0.4% when stopped while the 25 or the 100 ticker doesn't affect the cpu at all!

so when its just about redrawing i wouldn't use the rubyticker at all it just makes sense when you need accurate ticks between ruby and midi for example but this is not required for redrawing