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

NEW REGISTRATIONS - please contact us if you wish to register on the forum

Stock EQ V2

Post any examples or modules that you want to share here

Re: Stock EQ V2

Postby RJHollins » Fri Nov 09, 2018 1:55 am

KG_is_back wrote:Hello guys,
The FFT analyser is from my early years in ruby. I can make it a bit more robust, and perhaps less CPU intensive if you're interested.

Always interested in your post !
RJHollins
 
Posts: 1567
Joined: Thu Mar 08, 2012 7:58 pm

Re: Stock EQ V2

Postby KG_is_back » Fri Nov 09, 2018 2:49 pm

I have done some tests and I wasn't able to get any noticeable improvement in performance. The main cost in performance seems to be drawing the display in the first place. The old version already needs to draw buffersize/2 number of gradients and draws each pixel exactly once, so it's optimal in that regard. Any other optimizations I tried were peanuts with no noticeable improvement.
The flickering is also something I wasn't able to fix. It seems to be a problem with the flowstone/windows drawing mechanism itself. In fact, it is present in any flowstone GUI that needs to redraw the full GUI repeatedly. It just happens to be the case, that usually only parts of the GUI actually change each frame, so the flickering is not noticeable. In this bar graph, the entire GUI changes significantly each frame, so the flickering is apparent.
KG_is_back
 
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: Stock EQ V2

Postby nix » Fri Nov 09, 2018 7:45 pm

The half screen flickering thing-
I think it's called tearing and is an artifact of GDI,
not just Flowstone.
I think it is needed that drawing is done with a video card to stop it.
which is not possible in FS
User avatar
nix
 
Posts: 817
Joined: Tue Jul 13, 2010 10:51 am

Re: Stock EQ V2

Postby tulamide » Fri Nov 09, 2018 8:11 pm

nix wrote:The half screen flickering thing-
I think it's called tearing and is an artifact of GDI,
not just Flowstone.
I think it is needed that drawing is done with a video card to stop it.
which is not possible in FS

Yep, it is called tearing. It happens if drawing doesn't sync to the monitor's refresh rate. Using Flowstone terms: You r drawing routine is active, but another trigger comes in. The drawing routine stops working on the current frame and starts with the next one. Now the upper half is from the last frame and the lower from the current frame.

This is only preventable in current Flowstone when the drawing is quicker than the refresh rate (and even then not fully). A smaller view and less pixels to be drawn is the only thing that could make it significantly faster.
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Stock EQ V2

Postby juha_tp » Fri Nov 09, 2018 10:58 pm

tulamide wrote:
nix wrote:The half screen flickering thing-
I think it's called tearing and is an artifact of GDI,
not just Flowstone.
I think it is needed that drawing is done with a video card to stop it.
which is not possible in FS

Yep, it is called tearing. It happens if drawing doesn't sync to the monitor's refresh rate. Using Flowstone terms: You r drawing routine is active, but another trigger comes in. The drawing routine stops working on the current frame and starts with the next one. Now the upper half is from the last frame and the lower from the current frame.

This is only preventable in current Flowstone when the drawing is quicker than the refresh rate (and even then not fully). A smaller view and less pixels to be drawn is the only thing that could make it significantly faster.


Ruby seem to support multithreading so, is it possible to use this feature in drawing routine ... i.e. bypass incoming triggers until current frame is fully drawn ?
juha_tp
 
Posts: 56
Joined: Fri Nov 09, 2018 10:37 pm

Re: Stock EQ V2

Postby KG_is_back » Sat Nov 10, 2018 3:07 am

juha_tp wrote:Ruby seem to support multithreading so, is it possible to use this feature in drawing routine ... i.e. bypass incoming triggers until current frame is fully drawn ?

Ruby "seem" to support multithreading. Th threads in ruby are "fake" threads. As far as system is concerned, there is actually only 1 real thread that the ruby is executed on, from your operating system's point of view. The threads in ruby are implemented internally in the interpreter. While it is technically possible to bypass incoming threads and thus preferring one ruby thread over others, there is no way to sync up ruby with the frames of your monitor - OS simply does not provide that kind of information to flowstone, AFAIK (really hope someone proves me wrong).
KG_is_back
 
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: Stock EQ V2

Postby juha_tp » Sat Nov 10, 2018 9:17 am

KG_is_back wrote:
juha_tp wrote:Ruby seem to support multithreading so, is it possible to use this feature in drawing routine ... i.e. bypass incoming triggers until current frame is fully drawn ?

Ruby "seem" to support multithreading. Th threads in ruby are "fake" threads. As far as system is concerned, there is actually only 1 real thread that the ruby is executed on, from your operating system's point of view. The threads in ruby are implemented internally in the interpreter. While it is technically possible to bypass incoming threads and thus preferring one ruby thread over others, there is no way to sync up ruby with the frames of your monitor - OS simply does not provide that kind of information to flowstone, AFAIK (really hope someone proves me wrong).


Hmm... IMO, what I suggested should work with any type of multithreading system ... it's the mechanism that matters here.
Without some "gating" system you try to draw all those triggered frames (could be 1000's / second ... depends on implementation ofcourse) which usually leads to visible malfunction because of disturbed drawing process ... with "gating" the drawing process you draw only those frames which are triggered right after drawing of previously allowed frame finished (i.e. you just skip those frames which are triggered while drawing ongoing) and the last triggered frame.

Have you tried already if this method is possible in Ruby?

BTW, this type of method worked well in realtime file write/read process which otherwise had the same type of issue where file was written while read --> file became read before writing process was ended... . Gating the process like described above fixed the issue
juha_tp
 
Posts: 56
Joined: Fri Nov 09, 2018 10:37 pm

Re: Stock EQ V2

Postby KG_is_back » Sat Nov 10, 2018 11:17 pm

juha_tp wrote:Hmm... IMO, what I suggested should work with any type of multithreading system ... it's the mechanism that matters here.
Without some "gating" system you try to draw all those triggered frames (could be 1000's / second ... depends on implementation ofcourse) which usually leads to visible malfunction because of disturbed drawing process ... with "gating" the drawing process you draw only those frames which are triggered right after drawing of previously allowed frame finished (i.e. you just skip those frames which are triggered while drawing ongoing) and the last triggered frame.

Have you tried already if this method is possible in Ruby?

BTW, this type of method worked well in realtime file write/read process which otherwise had the same type of issue where file was written while read --> file became read before writing process was ended... . Gating the process like described above fixed the issue


From what I understand, the tearing happens on system level, because the system ignores the fact that drawing isn't finished and simply slaps the half-baked frame on the screen. It's not that two drawing routines within flowstone run simultaneously - that is something which would be fixed by the thing you propose.
To fix tearing, we would need to prevent system from sending half-drawed frames to the display (for example by always sending it last fully-drawn frame). I do not think there is a way to do that from flowstone. This would be something that the developers would have to implement in flowstone sourcecode (or even worse, it might be machine specific and had to be fixed by Microsoft in their Windows OS).
Off course I might be wrong...
KG_is_back
 
Posts: 1196
Joined: Tue Oct 22, 2013 5:43 pm
Location: Slovakia

Re: Stock EQ V2

Postby tulamide » Sun Nov 11, 2018 12:57 am

KG_is_back wrote:
juha_tp wrote:Hmm... IMO, what I suggested should work with any type of multithreading system ... it's the mechanism that matters here.
Without some "gating" system you try to draw all those triggered frames (could be 1000's / second ... depends on implementation ofcourse) which usually leads to visible malfunction because of disturbed drawing process ... with "gating" the drawing process you draw only those frames which are triggered right after drawing of previously allowed frame finished (i.e. you just skip those frames which are triggered while drawing ongoing) and the last triggered frame.

Have you tried already if this method is possible in Ruby?

BTW, this type of method worked well in realtime file write/read process which otherwise had the same type of issue where file was written while read --> file became read before writing process was ended... . Gating the process like described above fixed the issue


From what I understand, the tearing happens on system level, because the system ignores the fact that drawing isn't finished and simply slaps the half-baked frame on the screen. It's not that two drawing routines within flowstone run simultaneously - that is something which would be fixed by the thing you propose.
To fix tearing, we would need to prevent system from sending half-drawed frames to the display (for example by always sending it last fully-drawn frame). I do not think there is a way to do that from flowstone. This would be something that the developers would have to implement in flowstone sourcecode (or even worse, it might be machine specific and had to be fixed by Microsoft in their Windows OS).
Off course I might be wrong...

That probably goes on my account, since I tried to explain it in Flowstone terms. I hoped that it would be easier to understand then, but it obviously confused people, thinking it's an issue that can be solved in Flowstone.

It can't! Without the use of higher libraries like DX or OpenGL (or WebGL), there's no way to introduce a vsync optimized drawing!
"There lies the dog buried" (German saying translated literally)
tulamide
 
Posts: 2686
Joined: Sat Jun 21, 2014 2:48 pm
Location: Germany

Re: Stock EQ V2

Postby wlangfor@uoguelph.ca » Tue Nov 13, 2018 2:57 pm

tulamide wrote:
KG_is_back wrote:
juha_tp wrote:Hmm... IMO, what I suggested should work with any type of multithreading system ... it's the mechanism that matters here.
Without some "gating" system you try to draw all those triggered frames (could be 1000's / second ... depends on implementation ofcourse) which usually leads to visible malfunction because of disturbed drawing process ...


From what I understand, the tearing happens on system level, because the system ignores the fact that drawing isn't finished and simply slaps the half-baked frame on the screen. It's not that two drawing routines within flowstone run simultaneously - that is something which would be fixed by the thing you propose.
To fix tearing, we would need to prevent system from sending half-drawed frames to the display (for example by always sending it last fully-drawn frame). I do not think there is a way to do that from flowstone. This would be something that the developers would have to implement in flowstone sourcecode (or even worse, it might be machine specific and had to be fixed by Microsoft in their Windows OS).
Off course I might be wrong...

That probably goes on my account, since I tried to explain it in Flowstone terms. I hoped that it would be easier to understand then, but it obviously confused people, thinking it's an issue that can be solved in Flowstone.

It can't! Without the use of higher libraries like DX or OpenGL (or WebGL), there's no way to introduce a vsync optimized drawing!




You can use a slide to time the input exactly. Look at how I use a slide in the new version. It seems odd at first, but You'll realize what they do is save ticks. As Long as you have a refreshing end goal; Even less ticks like 25 will keep it refreshing; But in such a way that there's nothing start and stop about it. It's a guess that it's much due to the data I suppose; But perhaps a good one.

I extensively marked up this version for educational purposes. I'm wanting to go to Berklee and took some Coursera courses so I'm always trying to learn more. Please correct Me if You see anything and if there is any room for improvement please let Me know.



Here it is, small version for synths coming soon.
Should be 1% CPU or Less. This one uses about 0.4 - 1.5. It adds about 120 Mb or ram usage.
Last edited by wlangfor@uoguelph.ca on Wed Jan 02, 2019 4:15 pm, edited 2 times in total.
My youtube channel: DSPplug
My Websites: www.dspplug.com KVRaudio flowstone products
User avatar
wlangfor@uoguelph.ca
 
Posts: 912
Joined: Tue Apr 03, 2018 5:50 pm
Location: North Bay, Ontario, Canada

PreviousNext

Return to User Examples

Who is online

Users browsing this forum: Google [Bot] and 33 guests