DSP Robotics Support

Folks,

All this time, I have been learning about making things work. I know I have discussed graphics speed in the past and the issues I ran into related to putting to many individual LED with sliders on the screen at once really took a horrible performance hit.

@k brown has done amazing work on the front end. What is special about what he does to keep the performance up on all of those synth? My assumptions are no real time moving parts like the stuff I am trying to do. I looked through several of the interfaces with all of those knobs, sliders and many many overlays? I cringed looking at the level of detail thinking if I even do a quarter of that, will this have killed my project to the point of starting over again?

Q: I have a ruby bar graph with 125 bars, works great. I needed to overlay lines/numbers now, boom the display performance dropped on my powerful (12 threaded i7 gaming machine using a useless RTX graphics card in FS). I did mix prim elements with the ruby graph.

Q: Is it better to keep all the same inside the module: All ruby graphics or all graphic prims? I suck at the prims more than ruby. So ruby is the choice for me. lol
Q: If I draw a bitmap of the numbers and graph lines to overlay, I assume even worse? It might be an easier path to get the measurements 100% correct. The overlay could be around the edges of the bar graph and not truly overlaying it.

I assume 64 bit will help in this area as someone once pointed out it was night and day on the speed difference.

Q: Outside of the graph lines, if I put all those fill boxes and pretty up the interface, will this most likely cause a performance issue?
Not selling my self short here, I just know my limitations, I will never be able to create interfaces like @k brown or some others I have seen. I am best at functional with dynamic capability.

Q: Does hiding all knobs/gui elements in a module and pulling them out when needed make a big difference? Again I go back to @k brown with the huge gui.

Keep in mind, I understand graphics from the traditional way screen buffers and drawing to the screen etc. This is strictly about FS.
I know I can test this myself by going down the wrong path, but it would be faster to ask the question now instead of wanting to throw your computer off the table after spending a week on your gui and fail. That is not lessens learned. Some of this might have been mentioned to me before, but this is very specific.

Long questions I know and thanks!!

The most important things regarding graphics in Flowstone are

1) Size matters
2) Redraw only what's needed

A view the size of x will need time x to draw. A view the size of x/4 will need time x/4 to draw.

Only drawing what'S needed can be a challenge. Kevin gets away with it, because he composes the final big GUI view out of dozens of smaller views. This automatically enables point 2, because if you move a slider that'S in its own view, the other views won't receive a redraw trigger.

But you can restrict drawing to the affected regions only in Ruby too. There are several tools to help you with that. Please refer to chapter 8 of the user manual. It is very detailed and tells more than I could in this post.

Lastly - yes, don't try to sync animated graphics to audio. Instead run a low timer, say 25 ticks or less per second and grab from the audio stream whatever is there at that moment in time. You won't see any significant difference and the cpu load goes down by a lot. The stock meters and scope are implemented exactly like that.

.

Let me draw your attention to the arp of Adam's Viper. It is done with Ruby completely. I know it, because I did the graphical programming of it. It is composed of three seperate views. The number line above and below (enabling steps and setting the range of the arp), and the big arp step editor in the middle.

It features transparency, "realtime" highlighting of the current step, a grid responding to the settings etc. It runs silky smooth, although the middle part (the HUGE one) doesn't even make use of partial redrawing. Yep, on any redraw the whole view is drawn. So why does it run so smooth then? It has no syncing to audio involved, uses Ruby timers and only redraws when needed - not all the time 30x per second.

https://youtu.be/dwhO3y5xy-M?t=363
(it's a longer bit, take your time to watch it to see the arp editor reacting to user input)

More can only be said if you actually share a schematic, to look through for little hickups or bottlenecks.

.

I think tulamide has covered the general points really well, so I won't repeat those. But there is one specific question that I'll answer...

pshannon wrote:If I draw a bitmap of the numbers and graph lines to overlay, I assume even worse?

No, not usually - in fact, once you've nailed down the sizes, shapes, styles etc. of panels, I'd recommend "flattening" all static elements to the minimum number of bitmaps.

Essentially, when you use vectors and text, you are creating a bitmap on-the-fly - the frame-buffer into which the primitive (or Ruby) are drawn. Vector shapes (even lines) all consist of an outline which has to be filled by a real-time algorithm, and every individual text character is rendered as a similar vector shape. None of this rendering is implicitly cached, so it is all repeated in real-time every single time there's a redraw. You can easily end up in an ironic situation where the static label for a control drains more CPU than the animated parts - as with your meter.

Bitmaps, on the other hand, are far simpler to draw, especially when drawn at their native size and with the pixels aligned to grid - the pixels can just be copied across into the redraw frame ("blitting"), and the most complex calculation required will just be a simple linear interpolation if transparency is used.

Sometimes, you have elements which are somewhere in-between being static and dynamic - for example, if your meters had a "range" control, you might need to redraw the gradations and labels when the setting changes, but not really for the audio-sampling redraw ticker. For situations like this, you can implement a view cache, where a bitmap is created on demand within the schematic whenever a new one is needed. IIRC, MyCo has now added such a component to the alphas, but for older versions, here's the implementation that I usually use...


Note that the redraw trigger to the module should be used only when the view connected to the right actually needs to change. The resulting bitmap will be drawn to the view on the left whenever it's redrawn implicitly for any other reason.

There may be cases where a bitmap really isn't any more efficient - say, if the area covered is very large in order to render a couple of widely spaced and very small vector elements. The "view cache" module can be used as handy "sanity check" for this situation - just insert it in-line with the elements in question and retest!

Thanks for the details and now I feel like I am learning FS again. I worked so hard learning how to piece things together and now I am stopped in my tracks trying to figure out proper way to overlay something trivial for working with the graphics portion. Blitting sections of a bmp to the screen is something I have done in several languages since the early 90's, this just feels different to me.

@trog - I forgot about the cache view and thanks for the details.
@tula - The youtube video: What you and adam did is exactly my expectation. It moved the way I expected and smoothly. But I can only hope to achieve that level of a gui outside of the functionality.

I would love to share what I have, it is so in the functional testing concept phase, I would have to copy and paste the key elements into a new schematic. Tula/Trog might have a heart attack with my ruby code. There was some trial and error in there which worked and I left it because I wanted to keep moving forward. My sloppy code is not the hangup, because the base is from another bar scope. Once I have a solid design I would need to go back and clean it up.

I thought about manually creating gauge as a bmp to overlay the at the side(DB) and bottom(freq & Octave). I have noticed people do draw this with ruby for scaling, but the ranges for the size between freq are not 100% in multiples of the same number because of my graph. It changes the scale spacing of the freq from the lower part to the higher freq. It could be my math is off too to find the ratio. It was close, but not close enough. 126 bars based off of the 12 semi tones. The base number is 1.059 and as I was typing this out, the light bulb just went off. Maybe that is my ratio and I missed it. lol

Attaching file concept. I grabbed all the important stuff and hopefully it makes sense. Thanks

Any tips on how to use the Alpha view cache ?

lalalandsynth wrote:Any tips on how to use the Alpha view cache ?

Ask in the slack group please. Trog is there as well.

I did , but its not very active.