DSP Robotics Support

I have fond memories of the many days work, and dozenss of posts that infuzion and me put into the whole problem of getting GUI CPU load down in SM using 'heartbeat' timers and trigger trickery.
And then along comes this new fangled FS3 thingy, and now the same thing, and better, can be done in half an hour with just a few lines of code! Those guys at DSPr are such a bunch of spoilsports sometimes!


Rapidly changing input events will only update the output at the maximum 'frames per second' set in the dialogue (maxes out at 100fps as a 'safety measure'). There will also only be an output event if the input has actually changed.
This can really help to lower CPU load from screen redraws when you have GUI stuff driven from fast moving data.

The code is generic, and will work for pretty much any kind of data, so long as you set the in and out to be the same data type (there are exceptions - some obscure Ruby objects cannot be 'compared', in which case just delete the testing with the @last value). I've commented the code, so hopefully it will be easy to do a cut-and-paste job if putting it inside your code is more appropriate than a separate module.

There are even some advantages over the old green method...
- Independent frame rate for each event limiter, so different displays can have different degrees of animation 'smoothness'
- No complex reading of system time needed to get an accurate 'heartbeat'
- The first event after a long pause is output immediately without waiting for a 'tick' of the clock
- The clock goes to sleep if there is no input event between 'ticks' - so when input activity stops, there is no processing at all going on at all.

Awesome... nothing more 2 saw right now

4 all vikings here: spoilsports means "Spielverderber"

btw: Is ruby drawing over GDI+ ???

Walter Sommerfeld wrote:btw: Is ruby drawing over GDI+ ???

Well, the raw redraws are much the same as far as I can tell - so long as everything else is well optimised the CPU load seems about the same. But that's pretty much what I would expect, as GDI+ is just part of windows, so no-one has any way to make it work faster.
Where I think there is an advantage is that when using Ruby there is much better control over events, so refreshes are simpler to control, and the placing of many GUI items prior to re-fresh seems much more efficient.
For example - the 'Super text box' that I made draws every single "spreadsheet cell" individually for better control of format, text colour etc. - equivalent of nested draw loops and multiple array accesses with dozens of selectors. Yet I can measure little more CPU load than for SM drawing a simple block of text to fill the same area (and I still need to add the redraw limit to that design).
However, you've still got to watch out for excessive screen updates - put 100 value changes per second into an area of that size, and it will still suck CPU - hence writing this little module.

Hi trog,

thanks 4 ur well explained Info...

I placed here Big CPU Prob my new GUI test

Walter Sommerfeld wrote:I placed here Big CPU Prob my new GUI test

Did I pass the test?

trogluddite wrote:I have fond memories of the many days work, and dozenss of posts that infuzion and me put into the whole problem of getting GUI CPU load down in SM using 'heartbeat' timers and trigger trickery.

It didn't take me long to build the "heartbeat"; there already were many examples of gating a trigger with another trigger. What took me 1-2 hours was to test if the Ticker 100 or Time primitives were more accurate.

trogluddite wrote:- Independent frame rate for each event limiter, so different displays can have different degrees of animation 'smoothness'

I wonder if this ideal; if there was a global "heartbeat", would that not save CPU cycles & memory (timer objects) over 50 ReDraw limiters? Perhaps not all 50 would run at the same time, but could be a dozen with parameter automations, wave form & filter displays updating at once. Though running a knob & wave-output at different FPS would be helpful.

Minor Suggestion: If FS-Ruby has an "VST Editor Open" command built-in (like the primitive), that would be better to add. Plus if this is targeted at ReDraws, I would cap at 60FPS; most gamers are happy with that number (I personally would not waste the Ruby Code on the cap; I would hard-wire fix it at __FPS inside the Ruby, but I'm not suggesting that )

FlowStone Suggestion: Add this in FS's stock modules already please!

Hi there, thanks for the comments and suggestions.

infuzion wrote:I wonder if this ideal; if there was a global "heartbeat", would that not save CPU cycles & memory (timer objects) over 50 ReDraw limiters? Perhaps not all 50 would run at the same time, but could be a dozen with parameter automations, wave form & filter displays updating at once.

Yes, I am still pondering that questions. I need to get around to setting up a big rig to see what, if any, difference there is between 'synchronised' and 'staggered' redraws. My hunch is that it probably won't make much difference - presumably every redraw is a separate call to GDI+ that will be scheduled however the CPU see fit - but no hard evidence yet!
Like you point out, much could depend on how much automation etc. is used. In the situation where control changes are relatively sparse, this way should be a little better, as 'unused' control have absolutely no activity - and not even a heartbeat running when no controls are being moved.
When many are likely to move at once, I usually opt for the 'shared redraw'area' method - but that technique is a little tricky to make into a single 'general purpose' toolbox module.

I'm not too certain which would be better also.

Or is it worth staggering the redraws?