DSP Robotics Support

MichaelBenjamin wrote:no wonder then that this runs like ass. redraw tickering the whole gui area is super wasteful, this is not opengl. Instead, just redraw the area of the gui element with manual 'on value change' triggers, like in the default elements posted above, then it will work smoothly.

It's designed to work that way in light of the space for an analyzer. Normally the analyzer would be running which would be why the redraw area is so large. But yeah, if off multiple redraws seem relevant.

It's a good idea, It runs fast enough now however; but still I'm always for optimization. But yes, the point of the video is when two items are running at the same time and not just sliders; that's the easy part, as is trying to be a fancy pants I suppose .

Though I was in a rush and did not add:

1. When using the range function of this equalizer, a refresh of nearly the entire draw area is affected as any dB readout would of course change as a result of the maximum dB in that threshold being affected, so; that given it requires a lot of extra instrumentation to create this switch based on various clauses etc.
   
   
2. There's a selected band color for text, meaning that not only the active but the last active has to redraw as well; so I avoided that extra architecture, lazy? call it what you will.
   
   
3. When I was initially ironing out the issues, I found that the difference between redraw for singular redraw area in the case of one knob versus while the analyzer was on was staggering; so I'd decided, thirdly that I wanted there to be no such transition when someone turned on the analyzer. Because, as a result of that effect, I received complaints by customers and decided it was a happy medium.
   
   

But thankfully; either way now I can achieve both. And I guess it's a really "ass" issue to solve when you have that much processing occurring and the CPU resources are going towards the bells versus the graphics; but given the fact that VST's are not designed to be bolstered by GPU RAM, we're SOL.

Which is why I thought it was a good reason to make a video. But the mouseover is a good workaround I thought, while the analyzer is activated. I also invoke My own custom "playing" detection that does not require the DAW's infrastructure, but instead, linear float data being above zero from a mono to float at 25 ticks a second. that of course negates this "opengl" like redrawing as you suggest, it's such a multi-faceted solution when you get into the semantics that you really require the time to write the answer in full, it's an "ass" of a dilemma, wouldn't you agree?

The only counter-productive realization though; of testing for dB in this manner is ultimately there being EQ's and some synths (like waves element) that add that cheesy fake analog hiss, the CLA compressors also do that for instance. It'd be nice to be able to detect playing; but for customers or users using your plugs who are employing an editor rather than a DAW, get differing results to the "play" primitive, the one with the stream-out connection seems the only accurate one. The other type is not 100%. A good workaround, you could see why it seemed so alluring to just have one redraw considering all the architecture to allow only singular instances of redraw.

I guess in the case of the boardstation, it comes down to being able to see the last band that was selected, so only it needs to redraw after another band becomes active while the analyzer is turned off.

This flowstone series will also include errors with decimals and workarounds because only recently I was attempting to make calcs more precise and realized what's holding us back with multiplication.

here's a new video about enhancements I made which are more efficient and how I was able to make things faster, also it shows the new horizontal animated bitmap I'm working on.
I'll be sharing the method for the image knobs tomorrow .

I'm also trying to route all settings through a bus to see if it is faster as well.