Support

If you have a problem or need to report a bug please email : support@dsprobotics.com

There are 3 sections to this support area:

DOWNLOADS: access to product manuals, support files and drivers

HELP & INFORMATION: tutorials and example files for learning or finding pre-made modules for your projects

USER FORUMS: meet with other users and exchange ideas, you can also get help and assistance here

Slow Scope by MV, now modded by tulamide

Post any examples or modules that you want to share here

Slow Scope by MV, now modded by tulamide

Postby tulamide » Wed Apr 01, 2020 6:31 am

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!
Attachments
Slow Scope r4.fsm
(143.63 KiB) Downloaded 94 times
If you feel like gifting: https://paypal.me/tulamide
tulamide
 
Posts: 2201
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Slow Scope by MV, now modded by tulamide

Postby RJHollins » Wed Apr 01, 2020 6:46 am

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] :lol:

As always ... Thanks Tulamide for your contributions to the FS community !
RJHollins
 
Posts: 1411
Joined: Thu Mar 08, 2012 7:58 pm

Re: Slow Scope by MV, now modded by tulamide

Postby kortezzzz » Wed Apr 01, 2020 7:35 am

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 :)
User avatar
kortezzzz
 
Posts: 660
Joined: Tue Mar 19, 2013 4:21 pm

Re: Slow Scope by MV, now modded by tulamide

Postby Spogg » Wed Apr 01, 2020 8:01 am

Wow!

Very much improved sir! :ugeek:

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

Thank you for sharing.

Spogg
User avatar
Spogg
 
Posts: 2561
Joined: Thu Nov 20, 2014 4:24 pm
Location: Birmingham, England

Re: Slow Scope by MV, now modded by tulamide

Postby martinvicanek » Wed Apr 01, 2020 10:03 am

Excellent, Tulamide! :ugeek:
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.
User avatar
martinvicanek
 
Posts: 1080
Joined: Sat Jun 22, 2013 8:28 pm

Re: Slow Scope by MV, now modded by tulamide

Postby wlangfor@uoguelph.ca » Wed Apr 01, 2020 2:51 pm

Thanks Tulamide I will check it out.
User avatar
wlangfor@uoguelph.ca
 
Posts: 803
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

Re: Slow Scope by MV, now modded by tulamide

Postby BobF » Wed Apr 01, 2020 4:38 pm

Thanks tulamide,

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

Later then, BobF.....
BobF
 
Posts: 587
Joined: Mon Apr 20, 2015 9:54 pm

Re: Slow Scope by MV, now modded by tulamide

Postby tulamide » Wed Apr 01, 2020 11:40 pm

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).
If you feel like gifting: https://paypal.me/tulamide
tulamide
 
Posts: 2201
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany


Return to User Examples

Who is online

Users browsing this forum: No registered users and 26 guests