DSP Robotics Support

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 !

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.

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

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.

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 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 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 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 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!

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.