DSP Robotics Support

Dangit, I so wanted to test the new envelope generator! But I was distracted by the terrible display of the slow scope. So much, that I spent 8 hours straight on optimizing it.

Please understand the following:
While I replaced inefficient code with more efficient one in several places, the goal was not to reduce CPU load! The goal instead was to produce a steady view (some here would refer to it as "smoother animations")
Therefore I put everything I saved on CPU into stabilizing the view - which increased CPU load again. And then I added some things that make it even higher. And higher.
You get the point.

If least CPU usage possible is your goal, stay away from my mod. If smoother animations are your goal, it might be of interest for you.

The biggest impact (I'm talking of 3%+ increase on Flowstone's blue stream CPU use meter) was a replacement of the unreliable Tick25 in the logger module. By providing data in unpredictable timespans, the graphics get jerky. Therefore I replaced it by an event-based(!) Ruby ticker (the stock one is method based), that runs 100 times per second. This was needed, because we have no possibility to hook into vertical sync from the monitor, so the frame rate should be higher than that (most business model monitors run at 60 Hz). However, there still is a bit tearing, and I can't prevent that (google for "screen tearing in games" to understand what the issue is), unless we get access to monitor sync'ing (aka, another graphics library like OpenGL, DirectX, Vulcan or WebGL)

Still, I think I did a pretty good job at stabilizing the graphics. The schematic shows both scopes (original and my mod) at the same time, so you can judge for yourself.

I can't do wonders though. If you increase the size of the scope's view, at one point, tearing will become really ugly. Best to use this as a small display of an LFO or something, rather than a full size oscilloscope.

You can always reduce the ticker in the logger module by setting it to higher times (for example 0.04s = 25 fps), to reduce CPU load drastically. But that comes at the price of jerkier graphics (even with the optimizations in Ruby, because blue to green conversion is the bottleneck here in terms of CPU load).

It would be so nice to hear what you think about it. Good, bad? Useful, waste of time? Don't hold back, but keep it civil!

Wow .... well clearly, this is a much smoother display.

Using my novice level ... I was looking into the optimize Ruby Ticker module. It would seem to be a good candidate for the Toolbox [for those 'special' needs].

This is advanced stuff ... so I'll be happy to watch [learn] from the conversations that may follow. [nothing like an 'Isolation' to get an audience]

As always ... Thanks Tulamide for your contributions to the FS community !

Thank you, Tula. Note: I got a strange error from FS4 alfa on starting. I copy\pasted the module, saved and it stopped the error messaging. Other then that, it's perfect looking feature

Wow!

Very much improved sir!

I make extensive use of the Slow scope for envelopes and debugging slower event sequences (in dual usage) etc.

Thank you for sharing.

Spogg

Excellent, Tulamide!
Your version is smooth and pleasant for the eye, thanks for that!
I am thinking perhaps I could improve the spectrogram display in a similar way.

Thanks Tulamide I will check it out.

Thanks tulamide,

So much better! Makes it much easier testing AHR's, ADSR's, etc..

Later then, BobF.....

Thank you very much for the positive feedback!

I really wasn't sure if a modifictation that adds to the CPU load, would make sense. From the answers I realized, that this scope is more often used only during the development phase, not for end user supply. And there it totally makes sense to have a stabilized view, because the CPU overhead won't be in the final product!

@Martin
Yes, it can be improved, but only slightly. The Ruby code's improvements won't do much, as they will only help to reduce memory use and prevent the GC to chime in too often. But the ticker replacement should stabilize the delivery of the data (it seems to be the very same logger module), so that should help. But don't expect wonders, because the view itself is pretty big, which brings GDI+ to its limits. (Your module would be sooo cool in applications like pitch correction, if we had access to hardware accelerated graphics libraries!)

I also wondered about the transparency issue. While normally transparency is a big factor regarding CPU usage, you implemented a workaround to set the colors with math to match as if they would be transparent. I'm not sure, if in that case, transparency usage wouldn't actually be less stressful for the CPU (because it would be done from the system code, not from a Ruby script).