bruno

I use GEN in conjunction with a 3rd party c++ framework to build virtual instruments/audio plugins (vsti, au, etc...), thanks to the CODE EXPORT function.

Everything seems to work properly, but I would ask for a specific "scenario" : the multi-CPU/Core/thread one.

I would ask if Gen EXPORTED C++ CODE (.cpp / .h / libraries), does support multi-CPU/Core/thread processing, or if it has any limitation in this.

If I embed Gen EXPORTED C++ CODE into WDL-OL or JUCE, (and then I build a plugin), that plugin does support multi-core/cpu/thread dsp audio execution?

run 1 instance of the Plugin across different cores,

or run multiple instances of that Plugin across different audio thread,

Obviously assuming that the Audio Host does support multi audio threads.

Thank you so much in advance to anyone that could help me, it is a VERY important topic for me.

I use GEN in conjunction with a 3rd party c++ framework to build virtual instruments/audio plugins (vsti, au, etc...), thanks to the CODE EXPORT function.
Everything seems to work properly, but I would ask for a specific "scenario" : the multi-CPU/Core/thread one.

Example:
run 1 instance of the Plugin across different cores,
or run multiple instances of that Plugin across different audio thread,
etc...

Thank you so much in advance to anyone that could help me, it is a VERY important topic for me.


gen-and-cpucoresthreads-audio-parallel-processing

gen~ code export doesn't provide any multi-threading capabilities built-in. But if a host can run multiple copies of a gen~ State over separate threads/cores, I can't see anything in the exported code that would be a problem -- so long as each instance of a State (effect/instrument) is only performed from one thread. (Effectively this is what happens when you run gen~ within a poly~ with multi-threading enabled.) I can't see any global state or any such limitation that would prevent this usage.

Just need to be careful that for a given State, reset() or destroy() is not called in one thread while perform() is being called in another.

gen~ code export doesn't provide any multi-threading capabilities built-in. But if a host can run multiple copies of a gen~ State over separate threads/cores, I can't see anything in the exported code that would be a problem -- so long as each instance of a State (effect/instrument) is only performed from one thread. (Effectively this is what happens when you run gen~ within a poly~ with multi-threading enabled.) I can't see any global state or any such limitation that would prevent this usage. 

Just need to be careful that for a given State, reset() or destroy() is not called in one thread while perform() is being called in another.


Thank you so much for your support Graham,

yesterday I made a testing on a 2-core CPU (1 thread per core, 2 threads total, no hyperthreading) and Cantabile Lite.

When my VST Plugin was loaded, I noticed that the GUI side was executed by "core 0" and the DSP side (gen) was executed by "core 1".

so I loaded a second instance of my VST Plugin (the same plugin) and I saw:

So it was the origin of my fears :) - that for the DSP side (gen), multiple plugin instances could be allocated only to the same core/thread!

BY THE WAY, after that, I loaded the same VST Plugin in a different host (FLStudio), having:

so I loaded a second instance of my VST Plugin (the same plugin) in FLStudio and I saw:

So this time the workload was shared correctly between the cores/threads. I suppose it is all about how the host engine creates threads and allocates the plugins instances, there are not limitations in GEN/CODE EXPORT itself.

So this, together with your words/explanation, saved my day :)

"Just need to be careful that for a given State, reset() or destroy() is not called in one thread while perform() is being called in another. "

My apologies Graham, I didn't understood exactly. What does it means in a practical way? Any kind of limitations?

Obviously I execute "perform()" in the framework's main audio dsp processing class...

Thank you so much for your support Graham,
yesterday I made a testing on a 2-core CPU (1 thread per core, 2 threads total, no hyperthreading) and Cantabile Lite.
When my VST Plugin was loaded, I noticed that the GUI side was executed by "core 0" and the DSP side (gen) was executed by "core 1".
CPU "core 0" hit was 10%
CPU "core 1" hit was 50%
so I loaded a second instance of my VST Plugin (the same plugin) and I saw:
CPU "core 0" hit was 20%
CPU "core 1" hit was 100%
So it was the origin of my fears :) - that for the DSP side (gen), multiple plugin instances could be allocated only to the same core/thread!

BY THE WAY, after that, I loaded the same VST Plugin in a different host (FLStudio), having:
CPU "core 0" hit was 10%
CPU "core 1" hit was 50%
so I loaded a second instance of my VST Plugin (the same plugin) in FLStudio and I saw:
CPU "core 0" hit was about 50%
CPU "core 1" hit was about 50%
So this time the workload was shared correctly between the cores/threads. I suppose it is all about how the host engine creates threads and allocates the plugins instances, there are not limitations in GEN/CODE EXPORT itself.
So this, together with your words/explanation, saved my day :)

Just a question Graham, if possible:
You wrote:
"Just need to be careful that for a given State, reset() or destroy() is not called in one thread while perform() is being called in another. "

My apologies Graham, I didn't understood exactly. What does it means in a practical way? Any kind of limitations?
Obviously I execute "perform()" in the framework's main audio dsp processing class...

Yes, it all depends on how the host handles threads -- and I'm sure most DAWs do this safely, if not all can utilize many cores.

I misunderstood and thought you were talking about a 3rd party system that was a new host, and had some control over it.

Yes, it all depends on how the host handles threads -- and I'm sure most DAWs do this safely, if not all can utilize many cores. 

I misunderstood and thought you were talking about a 3rd party system that was a new host, and had some control over it. 

Gen and CPU/cores/threads (audio , parallel processing)