Who wants to think and analyze so much? Go get some more RAM!!!

AFTER 30 MINUTES OF PLAYING 1 PRESET AT A TIME:

Processes: 46 total, 3 running, 43 sleeping... 166 threads 22:31:51
Load Avg: 0.89, 1.02, 0.86 CPU usage: 24.2% user, 22.5% sys, 53.2% idle
SharedLibs: num = 139, resident = 32.7M code, 3.44M data, 7.58M LinkEdit
MemRegions: num = 10667, resident = 551M + 6.79M private, 120M shared
PhysMem: 126M wired, 107M active, 1.35G inactive, 1.58G used, 432M free
VM: 5.43G + 93.0M 18967(0) pageins, 0(0) pageouts

PID COMMAND %CPU TIME #TH #PRTS #MREGS RPRVT RSHRD RSIZE VSIZE
225 top 9.7% 2:13.34 1 18 22 452K 348K 884K 26.9M
224 tcsh 0.0% 0:00.02 1 15 20 400K 604K 916K 31.1M
223 login 0.0% 0:00.01 1 16 36 144K 364K 552K 26.9M
221 Terminal 0.5% 0:07.62 4 93 139 2.20M 7.57M 6.89M 230M
219 vsldaemon 0.0% 0:00.59 2 64 106 1.64M 9.77M 6.87M 231M
217 Synsopos 0.0% 0:02.49 1 55 136 14.7M 2.09M 15.9M 167M
216 VSL-Server 22.5% 7:35.00 18 327 5753 479M 30.6M 489M 762M
214 MIDIServer 3.6% 1:16.21 4 92 59 480K 1.57M 1.58M 30.7M
213 Plogue Bid 51.9% 13:27.13 8 218 357 14.7M 49.6M 40.3M 317M
206 ntpd 0.0% 0:00.15 1 11 18 156K 480K 380K 26.9M
204 mdimport 0.0% 0:00.27 4 65 94 1.07M 2.59M 3.16M 71.8M
198 automount 0.0% 0:00.01 3 41 29 300K 816K 1.05M 28.7M
193 mds 0.0% 0:00.24 8 92 66 1.96M 1.80M 3.51M 42.7M
174 automount 0.0% 0:00.02 3 43 34 304K 836K 1.09M 29.0M
170 rpc.lockd 0.0% 0:00.00 1 10 18 104K 332K 200K 26.7M
168 MAFL 0.0% 0:00.02 1 30 25 276K 744K 940K 27.2M

Bruce my recording studio machines have 8 Gig EACH.......you load more stuff....And I always make sure to leave a gig free!!

THERE is something really wrong with the MAC versions....Im inclined to believe there is a memory leak AND polyphony overloads with release samples turned on or something.



The sessions breakdown...

SvK

ANOTHER 15 minutes later....now only 291meg is free....still playing only a single preset at a time.......

Processes: 46 total, 2 running, 44 sleeping... 166 threads 22:52:35
Load Avg: 1.16, 1.10, 1.04 CPU usage: 19.2% user, 31.4% sys, 49.3% idle
SharedLibs: num = 142, resident = 33.7M code, 3.59M data, 7.85M LinkEdit
MemRegions: num = 10683, resident = 552M + 6.79M private, 120M shared
PhysMem: 128M wired, 107M active, 1.48G inactive, 1.72G used, 291M free
VM: 5.44G + 94.4M 19246(0) pageins, 0(0) pageouts

Oh yeahhh....

And If I load just 3 instances of VI one with Celli Sord leg, 1 with Celli Flaut, and 1 with celli Trem and try playing apregiated triads in 8th notes circa 140bpm......

complete stuttering and drop-outs??

what's up?

SvK

I have about 4.5 gig in each G5. What seems to happen is that the machines start to bog down after just so many VI instances especially if they're fully loaded. I can only go by real world testing on my own G5's. The Quad makes the dual 2.5 look sick in comparison. In using DP 5.0 I have increased the Host Buffer Multiplier to 2 from 1 in the Quad and the CPU meters go down about 30-40%. It seems that with each VI instance the CPU gets busier. So performance is just as big a factor as Ram.. I keep loading stuff and the only limit I seem to reach is overall polyphony and yes that 7 minute start up time. I am also using Kontakt 2 which probably stretches out the Ram a bit as you have pointed out.

BRUCE,

I really am not trying to be this analytical "told ya so" guy...........I'm a composer and wish as all of us do, to make what I hear in my head (that'll be the day[;)]

I did just figure out that the release samples default to always on......when you right-click in that field you can assign a controller to turn them on, only when needed.

This gets rid of a lot of stuttering (definitely polyphony overload) But there is still stuttering...

The problem is that i need approx. 8 VIs for each string section.

8 for celli
8 for violins
8 for violas
8 for basses


having 2 for each string section is to confusing and limiting. I was hoping on running 16 VI's on each G5 (the ram is there and everything loads up.....but the cpu's can't handle 16 VI instances)

Remember my old VSL lib could handle 70+++ instances of EXS24s



SvK

Well there's no doubt that the EXS's are far more efficient than the Vienna Instruments. And turning off the release samples can help a bit. So we just need a more efficient VI. Time will tell.

Bruce....

I'm in the VideoGames Industry...I deal with people writing code for our Game Audio Engines every day.....

Now,

A great programmer will make an app (plug-in) with all the same features as a not so great programmer BUT the great programmer will make it run super-efficient! (way less cpu load)

That is the problem here. There, I've said it.......... [;)]

SvK

I bet that lossless 24 bit compression is hittin' that CPU like no tommorrow.

SvK

ps: thanx for being there for my rant...i feel much better now

ps: hope your muse is workin' hard for ya [;)]

SvK

BERNARD HERRMANN IS GOD

@svonkampen said:

The problem is that i need approx. 8 VIs for each string section.

8 for celli
8 for violins
8 for violas
8 for basses

Why? I'm running 1 for each section using keyswitch and controllers. It's a hassle but I have only 5 instances and 5 corresponding midi tracks.

@Another User said:

The Quad makes the dual 2.5 look sick in comparison.

Can you be more specific about that, Bruce? You mentioned the buffer in DP, but other than that? In what areas do you notice a big diff?

I haven't heard anyone else report this, so I'm intrigued.

dpcon:

Becuase it is a hassle and more importantly it is limiting.

What If I want to play a simple octave of celli...where the bottom note is a non-trem PFP and the top note is a TREM PFP

and underneath all of that I want to hold a cluster of celli flauts that slowly morphs/ into celli trills?


no can do with 1 instrument per section. There are simply to many times when a composer "splits" his sections for various duties.

Now I can revisit my presets and condense down to maybe 6 per section....

BUT still for 11000$$$ I should have VI plugs that run LEAN like exs24......

If I can run 70+++EXS24s, then asking for running 16 VIs isn't too much.

SvK

I would like to second the observations made by SvK. I am currenlty working on a piece for string orchestra (6 6 4 4 2) in which most of the sections are written for soloists, so basically I have 22 solo string parts. I could easily have 65-70 instances of VSL running on my dual 2.5 G5 with the 4GB RAM that I used to have. Since purchasing the VI solo strings and upgrading my RAM to 8 GB, I am having tremendous difficulty getting even 16 instances of VI running, with only a single combi matrix per instance. The other voices I supplement with VSL patches.

I also notice that memory does seem to be leaking.

Michael Matthews

The thing is "sampler based" plug-ins should NOT take up loads of CPU..

Not even Kontakt 2 does.

As long as all they are doing is crossfading, playing notes, randomising variations and cutting other notes off, some enveloping......the hit to the CPU is minimal.

And that is ALL that VI is really doing!

So the CPU hit per instance is OFF way OFF.

SvK

ps: I've set up miroslav patches in NI Kontakt2.....with randomising variations, crossfading, release samples....REALLY complex patches....In short (minus lossless compression) everything that VI's do...and the hit to CPU is MINIMAL.

SvK

This are our official stresstest results for OSX:

TEST COMPUTER 1

Processor: G5, 2 x 2.5 GHz,
Ram: 4 GB
OS 10.4.2
Data storage: Firewire 800
Host application: Logic 7.1.1
Soundcard: RME HDSP MADI with 648 MADI Interface

Latency at 512 Samples (12ms) / 2.5 GB Ram usage
Maximum Vienna Instrument instances: 24 (CPU 90%)
Maximum Samples loaded: 45000
Maximum polyphony: 300 stereo voices / (CPU 70%)

Latency at 256 Samples (6 ms) / 1.74 GB Ram usage
Maximum Vienna Instrument instances: 23 (CPU 70%)
Maximum polyphony: 200 stereo voices / (CPU 75%)

TEST COMPUTER 2

Processor: iMac G5 single, 1.8 GHz,
Ram: 2 GB
OS 10.4.5
Data storage: Firewire 400
Host application: Logic 7.1
Soundcard: Built in Audio

Latency at 512 Samples (12ms) / 1.08 GB Ram usage
Maximum Vienna Instrument instances: 11 (CPU 85%)
Maximum Samples loaded: 17400
Maximum polyphony: 250 stereo voices / (CPU 80%)

Latency at 256 Samples (6 ms) / 1 GB Ram usage
Maximum Vienna Instrument instances: 9 (CPU 85%)
Maximum polyphony: 160 stereo voices / (CPU 80%)

HERB,

Processor: G5, 2 x 2.5 GHz,
Ram: 4 GB
OS 10.4.2
Data storage: Firewire 800
Host application: Logic 7.1.1
Soundcard: RME HDSP MADI with 648 MADI Interface

Latency at 512 Samples (12ms) / 2.5 GB Ram usage
Maximum Vienna Instrument instances: 24 (CPU 90%)
Maximum Samples loaded: 45000
Maximum polyphony: 300 stereo voices / (CPU 70%)

Herb I can load 24 instances of VI easy.....BUT I can't play any of it multitimbrally without massive cutting out and stalling.....I'm not making this up and I really do know what I am doing.

The loading up is not the issue.


Any chance of you guys running these tests with current OSX?

10.4.2 is ancient 10.4.6 please

And current Logic 7.2 (7.1.1 is old now)


maybe something happened since Logic went over to universal binary....

thanx [;)]

SvK

@svonkampen said:

dpcon:

Becuase it is a hassle and more importantly it is limiting. What If I want to play a simple octave of celli...where the bottom note is a non-trem PFP and the top note is a TREM PFP and underneath all of that I want to hold a cluster of celli flauts that slowly morphs/ into celli trills?SvK

I can understand and instance per divided part. I just haven't seen many 8 part divisi's in my day. But after all we are talking samples and anything goes really. As far being able to run a lot of VI's I too can only run a very few (either on a 3.4 ghz PC or Dual 2.7) so I'm with you on that. Hopefully there will be an improvement in this.

dpcon,

I'm not writing 8 part divisi's

But I like having a seperate VI for dynamics, legato, trem-trill dyn's, flauts, sord.....this allows me to have a legato line........layered with a pad, and also allows me to crossfade ifrom the leg line into whatever, instead of a "hard" keyswitch".

that is 6....i will re-evaluate my thinking and try to condense to 4 with more key-switching...

BUT...i shouldn't have too [;)]

SvK

@Another User said:

The Quad makes the dual 2.5 look sick in comparison.

Can you be more specific about that, Bruce? You mentioned the buffer in DP, but other than that? In what areas do you notice a big diff?

I haven't heard anyone else report this, so I'm intrigued.

Hi Nick. Like svk says above that it is no problem loading the VI's in a G5 with enough Ram. The real acid test is how well do they perform in real time. I have noticed that the Quad generally outperforms the 2.5 Dual by a factor of about 2:1 when it comes time to use 8 Altiverb 5's and tons of notes including harp sustains and keyboards needing a lot of polyphony, alongside the VI's..So on my system (2G5's) I am using the Dual 2.5 to host just the woodwinds and percussion. All the strings brass and keys + Altis run on the Quad. Also I have been experimenting with the Host Buffer Multiplier in DP 5. This is not the 512/256 regular buffer. It is something else. You can set it at 1,2,3, or 4. I had it at 1. But now I see a huge iimprovement when it is set at 2.

HI everybody,

I just got back from a discussion with our chief Audio Programmer at the video-game company I work for...(He is considered one of the very best in our business)


I explained the differences to him regarding the old EXS24 16bit VSL VERSUS the new VI instrument 24bit Lossless Compression system...

Here are his comments:

When playing back an uncompressed WAV file that is loaded into RAM the CPU takes no hit whatsoever.

When playing back a 24bit Lossless compression Audio file (it is 2to1 compression....meaning the 24 bit file only takes up 1/2 the space it would uncompressed) the computer takes quite a hit....He could not say how much, but it's there....Now factor in crossfades, stacking, each file needs to uncompress on the fly to play (you see what I'm saying), release samples...polyphony builds up quick (each file hitting the cpu)

So ........It stands to reason that if we were able to turn the compression OFF......We would need twice the RAM to load all this stuff BUT the CPU would be able to play WAY more VI instances.

SvK