DSP Robotics Support

Hi all, it was only recently that I had been trying to take schematics to a new level using less images.

I like the idea of using math to create something thast is ultimately simpler; but because it uses math, it looks somewhat real. But there in lay an issue. I began to see that even instances of multiplication and derivatives tax the CPU a great deal.

In fact, if you are making a schematic that utilizes many knobs per say or elements that mirror or mimic one another the best way to avoid this is to convert the area co-ordinates to a plain string. But, the trick (if you didn't know already) is to use a trigger blocker which prevents the string from being misinterpreted I guess by the primitive.

Here's an image and here is the schematic which has made My latest product (White Black) use 1.5% less CPU than it had initially. If you're looking for a way to optimize in a surefire way, this is it.






GL, and enjoy.

btw, here's the white black screenie:

Fascinating!

I really don’t understand just how and why this reduces CPU.

For any redraw I would expect the prim to read the current Area values, so when the area input pin looks for values it would get them from the output of the trigger blocker instead of a View to Area prim. Is it cheaper because the values are stored in a String and not read from an area prim?

If this works as advertised, it’s a big deal because once the view area has been decided and finalised it can be used and it's especially good for identical synchronised modules where one change can be replicated over many modules.

Cheers

Spogg

Spogg wrote:Fascinating!

I really don’t understand just how and why this reduces CPU.

For any redraw I would expect the prim to read the current Area values, so when the area input pin looks for values it would get them from the output of the trigger blocker instead of a View to Area prim. Is it cheaper because the values are stored in a String and not read from an area prim?

If this works as advertised, it’s a big deal because once the view area has been decided and finalised it can be used and it's especially good for identical synchronised modules where one change can be replicated over many modules.

Cheers

Spogg

yeah, I mean this i really only relevant if you have hundreds of knobs and ultimately hundreds of calculations. But in the tense of that Mverb7 project I was working on, the math to make it scale cost an entire%. It's quite surprising, check it out, the older version is still available and only like 13 knobs or so.