Chris H.

I would like to share my latest experiences on performance issues using vst~-objects with you. What I try to accomplish is to implement a multi-channel MSP-patcher with parts of the signal processing compiled as a .dll and wrapped up in a vst~-object. Unfortunately I found out, that this eats up a lot of CPU!

In order to investigate what causes the high CPU-usage, I did some experiments. Therefore I utilized the adstatus cpu-object and a mean-object to get a rough idea of the patcher’s current CPU-usage. The instrumentation itself results in about 3% CPU-usage. I compared VST Plug-in implementations with Max MSP (directly patched) versions of the same algorithm for a varying number of channels. The results are shown in the following table:

----------------------------------------------------------------------------------------

CH     |    MSP     VST~    VST~ (no plug-in)

64     |    5     6     1        

256    |    9     11     6            .

1024    |    17     20     6            .

2048    |    24     36     11            .

4096    |    42     65     26

Additionally, I analyzed a VST Plug-in that just bypasses the audio channel buffers, which lead to results in the same order of magnitude as with a simple function (row “VST~” of the table).

This leaves me with the impression, that the vst~-object generates some unnecessary overhead. Another thread (

Of course, it comes to mind that writing externals would be the perfect solution (right?).

Other than that, does anyone have a better understanding of what is going on inside the vst~-object and how to use it in a more clever way to lower the CPU-usage? Did some of you have similar experiences? If yes, what is your work-around and what is seemingly the "best-practice" way to cope with many channels and VST Plug-ins?

I would like to share my latest experiences on performance issues using vst~-objects with you. What I try to accomplish is to implement a multi-channel MSP-patcher with parts of the signal processing compiled as a .dll and wrapped up in a vst~-object. Unfortunately I found out, that this eats up a lot of CPU!
In order to investigate what causes the high CPU-usage, I did some experiments.  Therefore I utilized the adstatus cpu-object and a mean-object to get a rough idea of the patcher’s current CPU-usage. The instrumentation itself results in about 3% CPU-usage. I compared VST Plug-in implementations with Max MSP (directly patched) versions of the same algorithm for a varying number of channels. The results are shown in the following table:
----------------------------------------------------------------------------------------
CH 	|	MSP	    VST~	VST~ (no plug-in)
----------------------------------------------------------------------------------------
64	        |	5	            6	                1		
256	|	9	           11	        6			.
1024	|	17	            20	        6			.
2048	|	24	            36	        11			.
4096	|	42	            65	        26
----------------------------------------------------------------------------------------
---Audio Settings---
Sampling Rate: 48 kHz
I/O Vector Size: 64
Signal Vector Size: 64
Scheduler in Overdrive: Off
Enable Mixer Parallel Processing: No
----------------------------------------------------------------------------------------

This leaves me with the impression, that the vst~-object generates some unnecessary overhead. Another thread () seems to point at similar findings.
Of course, it comes to mind that writing externals would be the perfect solution (right?).
Other than that, does anyone have a better understanding of what is going on inside the vst~-object and how to use it in a more clever way to lower the CPU-usage? Did some of you have similar experiences? If yes, what is your work-around and what is seemingly the "best-practice" way to cope with many channels and VST Plug-ins?
Any hint is highly appreciated!

vst-cpu-usage

Apologies for the formatting. I cannot edit my post anymore...

Here's a short update on my investigations:

I utilized the Max SDK and have implemented a "thru" (bypass) and a "one-for-all" multi-channel gain as both, a Max/MSP external and a VST plug-in. In a rough performance comparison between the Max external and a VST Plug-In (loaded into a vst~-object), I could see, that both seem to have the same CPU-load. This is valid for both algorithms, bypass and gain. Now I am searching for possible enhancements on the performance side. From observations on the "thru"-objects' performance, I get the impression, that the creation of instances and the buffer handling are already demanding in a multi-channel scenario, even without any DSP algorithm. Do I understand this correctly? Would it be possible to implement this more efficiently in some way?

Thanks in advance and merry Christmas!
Chris


since the very first version of the VST object was born 18 years ago, it was always a CPU hog when the audio vector ist short. put the audio vector to 2048 and the CPU usage of plug-ins will somehow be back to normal.

note that this is only for effects and not for instruments - VST plug-ins without audio inputs do not have this little problem.

thank you for your input. As I am working on a real-time application, I have a pretty strict constraint on the I/O- and signal vector size. But you are right, that is one way to relax the CPU-load! Is there any other tweak you could think of, that I could make use of?

thank you for your input. As I am working on a real-time  application, I have a pretty strict constraint on the I/O- and signal vector size. But you are right, that is one way to relax the CPU-load! Is there any other tweak you could think of, that I could make use of?


128 / 64 setting is fast enough for real time applications.

64 /64 is no real advantage in terms of latency, but it does load CPU more.

I get best resultes with vst~object in max 4, compared to all later versions it can handle

more Instruments and Audio Plugins and perform steady, so that one can take it on stage.

As first, drop the 48 kHz rate to 44.1
128 / 64 setting is fast enough for real time applications.
64 /64 is no real advantage in terms of latency, but it does load CPU more.
I get best resultes with vst~object in max 4, compared to all later versions it can handle
more Instruments and Audio Plugins and perform steady, so that one can take it on stage.


that depends on what he is doing. to run a music sequencer with metro is quite critical already at 64 (i usually run it at 32)

True, that depends on what one does with it, but most of the synths would hickup even when

512/64 is set and one sends a program change to it.

True, that depends on what one does with it, but most of the synths would hickup even when
512/64 is set and one sends a program change to it.


vst~ CPU-usage