DSP Robotics Support

During some test of these days i noticed that Flowstone made plugins are really CPU consuming when they are idle.
Also after ASM optimizing them, they still increase alot of CPU usage also when idle. (from 5-6% to 12-13%).
And for each multi-instance opened these % are added for each instance, resulting to high CPU consuption for each instance.

I belive that this thing requires to be fixed and to performs better or multiple instances will be ever a dream for Flowstone made plugin and also for cheap ones.

Your technical suggestion, support?

CS, did you checked
- tick/triggers vs ruby interactions
- general tick/trigger propagation density
in idle mode?

I had recently some "bad crashes" because of that. But I limited the data flow from trigger-based to tick-based, and limited trigger amounts at all, and now works like a charm.

Are these %'s in idle mode - low priority or CPU demanding?

This happen for anything, also if you run multiple instance of stock "amp" module VST.

You've probably done this, but check for denormals... especially search in filters and structures that are connected in feedback (delay/echo/reverb modules). The feedback works good when the signal is flowing to it, but when the input stops the value converges to zero probably reaching denormal range.

The CPU % jump-ups in idle mode might be only apparent. The CPU meters within applications are calculated from max-CPU cycles provided by operation system. For example on notebooks in power-saving battery mode the max CPU is set to 50% and you'll get double the amount of CPU% (compared to max-performance battery mode) in your app-meter although the absolute CPU use is the same. The CPU might even be automated to lower the max CPU downto 5%, so you may get insane amounts of CPU% in your app-meter while idle although the real CPU cycle use is very small.
Check advanced battery mode options on your computer and set both max and min CPU to 100% and also set priority of the application to highest in task manager to get steady CPU ceiling. If this doesn't solve the problem then the CPU problem is really within your app/plugin and not in the clumsy widnows CPU metering.

But I limited the data flow from trigger-based to tick-based, and limited trigger amounts at all, and now works like a charm.

Can you show how with a schematic? Last time i'v tried same design according to trog's example, i'v ended up with no
drastic improvements (in a big project with lot of parameters). As corestylerz said, about 13-17% with i-7 processor,
which are not that reasonable

It's something about Flowstone.
You can easily look at it by exporting any kind of audio module like the amp module, and use it multiple times.
The amp take as much CPU as Camelaudio Camelspace does.

CPU: 2

Amp x 6 : 5%

Camel Audio Camel Space x 6: 2%

Im running Intel Core i7 3770k, win 8.1 PRO 64bit.

Chamelspace just disables the audio processing, when there is silence for some seconds on the input... as soon as you put something through, the CPU shoots up and stays there... after some seconds it goes down to idle mode.

This has nothing to do with FS, the chamelspace devs just wanted to squeeze out any tiny bit of CPU. You can build that into a FS Schematic as well, just don't use the standard "always processing" method.

MyCo wrote:Chamelspace just disables the audio processing, when there is silence for some seconds on the input... as soon as you put something through, the CPU shoots up and stays there... after some seconds it goes down to idle mode.

This has nothing to do with FS, the chamelspace devs just wanted to squeeze out any tiny bit of CPU. You can build that into a FS Schematic as well, just don't use the standard "always processing" method.

Could you explain more about this standard processing method always on?