Mulab 8 has allergy to VPS Avenger

[e-crooner]

Maybe Mulab doesn't like AMD processors
There must be some reason why Mulab doesn't handle demanding synths well on some people's computers. When there are several people reporting the same issue, one can assume there is something to it.

Yes, Mulab spreads the load evenly across the threads, but very thick on my system.

[mutools]

Sorry but that's technical nonsense. With this statement you prove you don't understand the underlying technology. I'm getting more and more the impression you simply want to stick with some personal irrational illusion. Unless your next post contains rational scientifically measured numbers that prove your statement, within the context i explained (no multicore VSTs!) i'm gone close this topic as it's going nowehere and costs precious dev time and contains false statements.

[mutools]

There is nothing unrealistic about using an instance of Repro or Lush in a project.

Who said that that is unrealistic??? Pfew you're really mixing up things.

[e-crooner]

On my system Repro runs most efficiently with Mulab set to 1 thread and Repro's own multi-core support enabled. The other way round, namely Mulab set to 4 threads and Repro's multi-core support disabled, it is a disaster and overloads Mulab's audio engine.

Sorry if you don't like to hear that, but sticking your head in the sand and telling people their specific observations are wrong, won't solve anything. I know what I hear and see, you don't.

[e-crooner]

There is nothing unrealistic about using an instance of Repro or Lush in a project.

Who said that that is unrealistic??? Pfew you're really mixing up things.

Here is what you said:
"Of course that makes a difference if you're testing a single plugin. But in a realistic project there are many parallel racks and plugins and in that case a VST doing multicore inside will steal cpu from other plugins and you gain nothing."

How can I make what you call a realistic project with many parallel plugins when one instance of a single plugin already pushes Mulab to its limits, especially when that plugin's MC support is disabled?!

[mutools]

On my system Repro runs most efficiently with Mulab set to 1 thread and Repro's own multi-core support enabled. The other way round, namely Mulab set to 4 threads and Repro's multi-core support disabled, it is a disaster and overloads Mulab's audio engine.

When testing just a theoretical project with just 1 instance of that synth, yes that's the expected result. Explained it many times already.

Sorry if you don't like to hear that, but sticking your head in the sand and telling people their specific observations are wrong, won't solve anything. I know what I hear and see, you don't.

Not sticking my head in the sand, imho. I'm open to any critical numbers wrt MuLab's audio engine. But you don't understand the technical info i give.

[mutools]

There is nothing unrealistic about using an instance of Repro or Lush in a project.

Who said that that is unrealistic??? Pfew you're really mixing up things.

Here is what you said:
"Of course that makes a difference if you're testing a single plugin. But in a realistic project there are many parallel racks and plugins and in that case a VST doing multicore inside will steal cpu from other plugins and you gain nothing."

How can I make what you call a realistic project with many parallel plugins when one instance of a single plugin already pushes Mulab to its limits, especially when that plugin's MC support is disabled?!

As explained already many many times: When a synth does mc inside it steals cpu from other synths. Pls don't fool yourself.

[e-crooner]

I get what you mean, but it is irrelevant when one instance already pushes Mulab to its limit. Whatever I add on top of that, even something very efficient such as an instance of Sylenth1, only makes things worse.

Anyway, in the Mulab audio setup it asks about the number of threads to be used. Does it really refer to threads or to cores? When I enter the number of threads my processor has, the result is a disaster. When I enter the number of cores, though, it works much better.

[mutools]

Anyway, in the Mulab audio setup it asks about the number of threads to be used. Does it really refer to threads or to cores? When I enter the number of threads my processor has, the result is a disaster. When I enter the number of cores, though, it works much better.

Please see http://www.mutools.com/info/M8/docs/mul ... setup.html
The most recommended value is the number of real cpu cores (not hyperthreaded cores) minus 1 for the GUI thread. And with multicore disabled in VST plugins.

[e-crooner]

OK, so maybe it would make sense to replace the word 'threads' by 'cores' in that question

[mutools]

In which question?

[e-crooner]

The field "Num Audio Processor Threads".

[mutools]

Replacing "Threads" by "Cores" would be technically wrong for that's not how computers work. "Threads" is the only correct term there. As Dakkra also already explained well earlier in this thread. (Threads vs Cores)

[Michael L]

If you search e-crooners posts, you may observe he likes to troll threads by being obtuse.

[e-crooner]

If you search e-crooners posts, you may observe he likes to troll threads by being obtuse.

Says the guy who hasn't made a single useful post in this thread, like this one...