Hi CM,

I'm certainly with you on the view that increasing one element of a computers system can just transfer potential bottle necks somewhere else.

However what I am wondering is that when the VI's are playing there is probably, amongst other things, a CPU overhead for 3 additional elements:

1. Drawing the sample (beyond the header RAM) from the hard disc
2. Creating a join between the RAM sample and the streamed sample
3. Decoding the lossless codec that the sample are encoded with.

Now if a computer system was flush with RAM (let's say to the tune of 64GB) but there were still limitations on the processor buses or hard disc busses caused by the required number of simultaneous voices (samples) could an option such as "CONVERT AND IMPORT TO RAM" on the VI create a significant increase in sample count.

If the CPU now only had to play samples from RAM without hard disc steaming access or the overhead of decoding wouldn't the VI system be able have a greatly increased amount of polyphony?

This may be impossible to achieve within the software architecture of the VI's but I would be interested in your thoughts.

Julian

I find that the CPU on my slave PCs hardly takes any hit when playing back Vienna VI. They are also old, slow machines, so I would be very interested to know what the CPU hit would be on a 64bit machine running (for example) XP64 with 8GB instruments in RAM and around 30 tracks playing.

DG

I've managed to load about 7GB on a 2 x 2.5 G5 and have it work fine. (Using the old "stand-alone outside DAW and plug-in inside DAW" trick.)

And yet interestingly a very short cue I just did with low memory usage but eight Vienna Instruments players wtih only perf legatos clicked and popped like crazy. Well, I did also have an Ivory Grand and two Kontakt players. But the V.I. players only had one patch, so it was relatively lightweight.

I'm still trying to figure out some of the rhyme and reason behind what works and doesn't work. The next step is to see whether running stand-alone instances outside Logic would work better.

What's interesting is that the offline bounce of the cue was fine.

@Nick Batzdorf said:

I've managed to load about 7GB on a 2 x 2.5 G5 and have it work fine. (Using the old "stand-alone outside DAW and plug-in inside DAW" trick.)...

I'm still trying to figure out some of the rhyme and reason behind what works and doesn't work. The next step is to see whether running stand-alone instances outside Logic would work better.

What's interesting is that the offline bounce of the cue was fine.

This is still a mystery to me. As I watch Activity Monitor, it seems that Virtual Memory is accessing all available RAM no matter if the instances are inside or outside of DP. I'm not sure which works better because the amount of data on deck to page to/from VM always exceeds the amount of RAM I have.

What's really odd is that at one time VM used to kick in with a lot more available than it seems to do now. More often the latest readings appear to be tapping in to a lot more available RAM as VM data increases. I no longer see the 3-4GB brick wall.

The more I learn the less I understand.

By the time that any of us understand this we will all be running 64bit OS and not worrying any more.

DG

"What's interesting is that the offline bounce of the cue was fine."

In all my RAM, disk, and CPU limitations, never once have my offline bounces been affected. Offline bouncing gets me through the thickest of tuttis. When the real-time factor is removed, most bottlenecks are irrelevant.

clicks and pops are because the buffer is overrun usually, and the cpu can't keep up with the audio stream. Also, the cpu meters are very deceptive in some cases, while you may not think the audio engine is "taking a hit" it in fact is, and it will rise up exponentially at a certain load point.

Nick: there is a bug with Ivory if using Logic your process buffer should be set to small, or something similar perhaps in whatever DAW you are using, or try freezing Ivory everything should clear up then.

Miklos.

Oddly enough I have found that freezing Viennna Instrument tracks in Logic, when the matrix is fairly complex, there are frequent cell changes (using both keyswitches and CC messages) and lots of CC data streams modifying different performance parameters does not work well - - the results often exhibit wrong patches and other inaccuracies. Perhaps this happens because the keyswitches are on a separate track assigned to the same MIDI Channel as the VI (which I do since the music starts as notation in Finale where using keyswitchs on the same staff with the notes can create problems and make the score look unreadable)? I get the best results when bouncing each track in real time - - except that when I do this, Logic freqently (approx 1 time out of 5) announces that Audio and MIDI have lost synch. Possibly things would be better if I merged the instrument and keyswitch tracks?

one of the reasons it's helpful to freeze is because when jumping between song positions you don't have to worry about going back to the last keyswitch because it's audio.

@mpower88 said:

one of the reasons it's helpful to freeze is because when jumping between song positions you don't have to worry about going back to the last keyswitch because it's audio.

Miklos.

You could try this: force legato on yor key switch notes (you will have to do this manually or put keyswitches in a seperate track and do it automatically) Then wherever you start Logic as long as you haven't got the "no transpose instrument" selected Logic should pick up and send the current keyswtch whereever you start. If you jump between sections with the transport continuously running I'm not sure this will work but each time you hit play the keyswitches should update.

Julian

That's interesting, Miklos. Thanks, I'll check that. Yes, this is in Logic.

"By the time that any of us understand this we will all be running 64bit OS and not worrying any more."

This is what I like: an optimist. [[:)]]

My fear is that we'll be running a 64-bit OS and worrying about something else. [[:)]]

Looks like it will all take longer than we all hope unfortunately. I'd say don't hope for the bugs to be worked out and everything smoothly "64bit" on either Vista or OSX before Christmas... and I'm usually optimistic... but we'll see [:)]

@Nick Batzdorf said:

That's interesting, Miklos. Thanks, I'll check that. Yes, this is in Logic.

"By the time that any of us understand this we will all be running 64bit OS and not worrying any more."

This is what I like: an optimist. [[:)]]

My fear is that we'll be running a 64-bit OS and worrying about something else. [[:)]]

Well, I'm considering changing to XP64 very soon, so I'll keep you posted.

DG

Switching to XP64 for other software, obviously, right?

I would of thought Leopard or Vista (in about 3 years) once they work out the bugs, would have been a better choice for 64 bit??

Miklos.

@Nick Batzdorf said:

Switching to XP64 for other software, obviously, right?

No, I'll be using FXT, same as usual.

D

Sorry that was an involuntary anti windows slip, I'm seeing a professional about it and working through the issues if you can be tolerat with me....

[:P] [:D]

PS windows sucks! he he he I'll never forget what you did to me Gates, All those YEARS!!!!!!! NEVER!!!!!! [6] [6] [6] [6] [6] [:D]

Oh darn, well that looks like three more sessions for me next week at $350 an hour...

[:D] [:D]

@mpower88 said:

Oh darn, well that looks like three more sessions for me next week at $350 an hour...

[:D] [:D]

Well, come back and chat when you've calmed down. [8-)]

DG

he he, ah, I was only playing around... [:D]