Its well known that most DAWS stop at 10 but Reaper goes all the way up to 11

Don't invite that....

OK...FWIW..considering that I spent a fair bit of time downloading the new Cubase in here as well

The set up I am using here...

Asus P6X58D-E mobo
i7 960 3.28GHz processor
4 corsair 4Gb DDR3 Ram
M-Audio US41500C Audiophile 2496 soundcard
and
M-Audio NRV10 firewire mixer (I go back and forth between both inboard and outboard)
2 2Tb Seagate Barracuda XT HDD both at 7200 SATA 6Gb/s
Windows7 64bit
with Vista SP3 dualboot
All latencies are sitting at 44.100 are about 14ms ...

Cubase seems to handle Massive quite well...here it ran 7 instances before crackling and that...GUI had a bit of a lag at around 6 though

Sonar X1d has about 7 instances without crackling and a GUI lag at about 7 instances as well...

Reaper started to click and crackle at 8 instances...the GUI started faltering at 6 instances though

S1v2 though did itself in with 5 instances here. The GUI did not go funny until 5 instances

% wise everything ran pretty close to 80-87% before things went a little funny. I was using the task manager in this one. I'll see what comes up with the previously mentioned CPU metering software...

trimph1, you're wrong. nobody ever said anything about testing or experimentation. you're supposed to use the mat.



i do get the same results though. i'm able to run about exactly the same number of instances/voices/whatever of whatever i try in the hosts i've tested. (reaper, flstudio, energyxt, tons of free ones like mpt, buzz, etc)

with multi-core configuration reaper might be a little better, i'm not sure. if it is it's something like 5% or 10% though, not 1000%.

put that bitch in warp mode.

Bitches love warp mode!

Considering how much better of a processor you have than mine that's not so great. It's definitely not OSX VS Windows, but it looks like DP might be a killer CPU app on Windows, hard to tell until DP8 comes out and someone tests it out?
Just for kicks I'm going to run the same test I did with Reaper using Audio Units instead of VST and see if Cuckoos didn't get better performance that way, but I doubt it, they're neck and neck CPU wise.

when you say instances though what are they doing? just idle?

even if they had a ton of effects and all kinds of idle stuff for continuous modulation i can't see you using up your whole system without 100 instances.

i was going to go and replace the flat list in xhip (is voice 1 active? no. voice 2? voice 3?) with an "active list" (voices 2, 5 and 42 are active.) that's to save an immeasurably small cpu cost during idle. that might not seem important, but if you have 40 instances open it starts to take up 5%, that 5% could be used for a few more voices.

what on earth is massive doing?

I've had 6 voices going..on all instances here.

oh which preset? each preset will take a different amount of cpu power.

I seriously doubt even the most powerful home computer out there could handle 100 instances of Massive on a patch like 1991 even. Maybe if it was staccato, no release time so there wasn't much voice stacking happening....

@trimph1 that you were using 6 voice chords makes more sense, I don't think the voice count was much above two with my test, single eighth note run at 140bpm, roughly the same latency. so your lower instances and roughly 4 or 5 times more powerful computer would probably add up to 24-36 in my test. That i7 3ghz is a quad right?

Wrong logic.

In programming there is ONE best way to solve a problem using as few CPU cycles as possible and the software that gets closer to this best optimized code simply is better than software that complicates things unnecessarily which makes it run slower than the more optimized software.

So the DAW that is optimized better than everything else (looks like on a Mac it is NOT REAPER) IS top notch and everything else is not as good.

Efficiency & complexity aren't related. The most CPU-efficient code can be the most simple, or the most complex.



the thing is that most of the CPU goes into plugins, so that's out of the hands of the host.

Testing using a big CPU hungry synth will not bring you accurate data.

One: it is like trying to weigh something on a balance scale using only big 1 kilogram masses.

And two: if you want to see how a DAW handles plugins, you have to throw many of them at it, because with just one (as said before here) most of the processing will happen inside the plugin, not in the host.


[edit]
Lets test with a freeware plugin like Synth1 set to its "ini" preset - this way everyone can repeat the test without having to buy or "obtain" the commercial plugin.

And test with a high number of tracks to see how the DAW handles internal summing and routing of audio data.
Last edited by Mutant on Fri Apr 13, 2012 1:00 am; edited 1 time in total

For task A, the sum of instructions*cpu cycles that will complete the task will always be faster than more instructions*cpu cycles.

For this reason, a coder who knows how to optimize in ASM (for example using instructions that operate on CPU cache rather than on RAM) will be better than a coder who only knows some mutation of C.

Take convolution, in its simplest form it's just a few operations, in its fast form it's quite complex, involves partitioning using FFTs.

(& even though you wanted to write something that sounds like something that can't be argued, yes it still can. The CPU cycle an instruction takes isn't its only property. Its ability to pair (& with what it can), its behavior with cache, its possible penalties.. yes, more instructions*cpu cycles can end up faster)




Testing with 1 single plugin will only tell you in which host that plugin works best. To minimize error you need a lot of different ones.