KVR Audio

Zaphod (giancarlo) · Post by **Zaphod (giancarlo)** » Sat Nov 12, 2011 3:36 pm

about the original question: nebula in reverb config supports multithreading, it features load balancing, and you could enable optional indipendant multithreading for fft processing. in that way each nebula instance uses more cores. Nebula server works even better, because all threads are started by a different application. But you are right, reaper works in a better way than most of sequencers in terms of multithreading.

LawrenceF · Post by **LawrenceF** » Sat Nov 12, 2011 3:42 pm

Yeah, I'm only saying that the main reason they're different (the thread title) is because they're different. They're coded by different people with different approaches in different ways at different times with different (overall) goals in mind in some cases.

Not all that much of a mystery to me really. I haven't used one yet that used so much cpu it stopped me from getting my work done (mmv on that) so beyond pure curiosity about the technical nature of it all, it kinda baffles me.

We do occasionally ask developers to improve the efficiency of their software if they can but that's generally not the only reason we buy software, it's one of many.

I really don't think if Cubase's audio engine suddenly started out performing Reaper's by 10-15% cpu that Reaper users would be switching to Cubase in droves.

tony tony chopper · Post by **tony tony chopper** » Sat Nov 12, 2011 4:09 pm

all that video showed me is that a simple synth sound in FL can max out 8 cores pretty easily.

..a "simple synth sound" in Harmor, processing thousands (literally, up to 9000 sines/voice) of partials for each voice. If you find a non-FFT-based additive synth faster than Harmor, show it to me.

Fritze · Post by **Fritze** » Sat Nov 12, 2011 4:21 pm

hibidy wrote:Informative how? I found it insulting, then again, no surprise considering.

tony tony chopper · Post by **tony tony chopper** » Sat Nov 12, 2011 4:24 pm

From a software perspective, moving to 64 bit makes sense, not just to remove the 2/3 gb RAM limit of 32-bit software, but also to speed up 64-bit operations, which are useful and sometimes required in DSP code to get the desired precision.

mmh but there is only -one- reason for 64bit mode to allow tiny speedups, it offers more registers, but you know like me that it's not gonna do magic.

There are also reasons for it to be both slower (especially when adapting 32bit code. Also because most compilers seem to ignore the FPU [which is still available] and use SSE exclusively, & thus feature their own trig functions which aren't always the most optimized in their scalar version), and less precise (of course I'm not gonna say that anyone will ever hear or see any difference between the output of a 32bit & 64bit plugin, but what could have been processed by the FPU in the 32bit plugin [& believe me in some cases the FPU is still faster than SSE] in 80bit will most likely be processed by 64bit SSE2 in the 64bit plugin. And with phase counters it can matter).
IMHO someone who doesn't write his own asm & ports plain code from 32 to 64bit would better double-check the compiler's magic. I would trust Intel for this, but definitely not.. Embarcadero (Borland C++).

tony tony chopper · Post by **tony tony chopper** » Sat Nov 12, 2011 4:34 pm

I have no real idea how thousands of lines of code from multiple different people working independently would ever behave the exact same way or what would ever make anyone think they would or should.

For plugin that eat a lot (like, over 20%) CPU, most likely the result will be the same in all hosts that parallelize in a basic way. Where I believe it will differ is when your project has dozens/hundreds of light plugins, not processing very randomly in the song. In this kind of case the multithreading can end up eating MORE CPU than what it spares, so here it will totally depend on how it's done. I'm also sure that a certain type of project will perform better in a host than another, while for another type it will be the opposite.
The host has to deal with 2 unknowns: the plugins (wich may not even be parallelizable & thus will glitch with 2 instances, or will lock itself & block a whole core), and the user (who will set up different kinds of mixer setups). So it's up to the host to know users, up to users to know the host, up to plugin makers to know host & users..

Also important is how much "sliced up" is the processing. In FL it's tick-aligned, which allows aligned automation of VST2 events, without requiring VST3. This also means that the multithreading CPU overhead will be several times higher than in a host that processes in 1 single pass (the full audio buffer), knowing that in that host the only way to properly automate VST2 params will be MIDI CC's.

Fritze · Post by **Fritze** » Sat Nov 12, 2011 5:49 pm

LawrenceF wrote:I really don't think if Cubase's audio engine suddenly started out performing Reaper's by 10-15% cpu that Reaper users would be switching to Cubase in droves.

If that would be 100-150% I would concider going back to that crap interface. Or is there now a solution in the latest Cubase to switch plugin windows when choosing another track like in Reaper? Those dozens of windows opened got on my nerves. At least they had a shortcut to flip through these windows. Ctrl + TAB was my most used shortcut.

Fritze · Post by **Fritze** » Sat Nov 12, 2011 5:58 pm

tony tony chopper wrote:Also important is how much "sliced up" is the processing. In FL it's tick-aligned, which allows aligned automation of VST2 events, without requiring VST3. This also means that the multithreading CPU overhead will be several times higher than in a host that processes in 1 single pass (the full audio buffer), knowing that in that host the only way to properly automate VST2 params will be MIDI CC's.

Could you please go into more detail about these things? That sounds very interesting.

LawrenceF · Post by **LawrenceF** » Sat Nov 12, 2011 6:00 pm

chacka wrote: If that would be 100-150% I would concider going back to that crap interface. Or is there now a solution in the latest Cubase to switch plugin windows when choosing another track like in Reaper? Those dozens of windows opened got on my nerves. At least they had a shortcut to flip through these windows. Ctrl + TAB was my most used shortcut.

Yeah, 100-150% would not be a small difference.

As to the plugin window thing, no idea. I stopped using Cubase about a year ago so, no clue if Cubase 6 handles that any differently or not and I don't recall if you could preference Cubase 5 to have the current plugin UI follow the track selection or not. Dunno.

I think I remember it doing that but I can't be sure about that and I may be confusing it with another host, dunno, after awhile it's one big host blur.

Fritze · Post by **Fritze** » Sat Nov 12, 2011 6:04 pm

LawrenceF wrote:I think I remember it doing that but I can't be sure about that and I may be confusing it with another host, dunno, after awhile it's one big host blur.

Hehehe, thanx.

helium · Post by **helium** » Sat Nov 12, 2011 6:40 pm

edit: deleted

tony tony chopper · Post by **tony tony chopper** » Sat Nov 12, 2011 6:54 pm

Could you please go into more detail about these things? That sounds very interesting.

Normally, an old "problem" with VST2 (not VST3) is that MIDI CC events were timestamped, but not parameter changes, meaning that automating a plugin through CCs could be precise, but parameters would change on processing block boundaries. If that processing block is the size of the audio buffer, then the timing will be unreliable, depending on the driver latency you picked. In FL & some other hosts, buffers are processed in tempo-aligned ticks, which allows tempo-aligned automation of VST2 parameters.
This is also what makes FL processes random-sized blocks (like sometimes just 1 sample), which some badly coded plugins don't like at all, that's the drawback.

Fritze · Post by **Fritze** » Sat Nov 12, 2011 7:28 pm

tony tony chopper wrote:
Could you please go into more detail about these things? That sounds very interesting.
Normally, an old "problem" with VST2 (not VST3) is that MIDI CC events were timestamped, but not parameter changes, meaning that automating a plugin through CCs could be precise, but parameters would change on processing block boundaries. If that processing block is the size of the audio buffer, then the timing will be unreliable, depending on the driver latency you picked. In FL & some other hosts, buffers are processed in tempo-aligned ticks, which allows tempo-aligned automation of VST2 parameters.
This is also what makes FL processes random-sized blocks (like sometimes just 1 sample), which some badly coded plugins don't like at all, that's the drawback.

Now it get's even more interesting! Very cool what you do there. How many plugins are know to not work with that? Do you have a list of them somewhere? It would be important to know that all my goto plugins do work flawlessly.

tony tony chopper · Post by **tony tony chopper** » Sat Nov 12, 2011 7:36 pm

How many plugins are know to not work with that? Do you have a list of them somewhere?

no, but we have an option for a workaround anyway

hibidy · Post by **hibidy** » Sat Nov 12, 2011 7:56 pm

Hmmmmmmmmm.

Well, some good points (and of course a bunch of stuff I don't understand)

I can only comment from the consumer POV. If I've got a choice of product and have a high powered computer, I have to say that my expectation is similar results. Maybe it's not fair but once you've modified and tweaked and turned and workarounded (not a word.......YET

) and some hosts still outperform others then it should make the user think twice.

Multi processor support differences in various hosts