let me join this thread in my most popular role, the black-painter [;)]

seriously ... be prepared to re-organize your storage devices in case we can load 8, 16, whatever GB sample headers into memory as well as carefully inspecting data throughput on all busses of a system, because somehow the requested data has to be transported to RAM ... and from there to the processor and back to a sound-device.

the hardware- and configuration-carousel will start a new round ...
christian

Would a quad core mac pro with 1.5ghz dual bus, 4X 7200 RPM internal SATA drives, and 3 firewire 800 buses each with 2 7200 fw 800 drives do the job? (9 drives for VSL in total).

Plus wouldn't it be "relatively" and I stress "relatively" easy to get the VSL server to use "all" available RAM as a type of cache when and where headers were not loaded already - spreading the load if you like - another way of putting it - changing the focus of the engine to being less efficient with RAM for the benefit of drive usage, where there is lots of ram available? So the headers load first, and then a cache is opened up for all of the other data that is streamed.

Miklos.

what i wanted to point out is just something, we could notice after a transition from exs/giga to VI ...
in a first step one loads more, just to have it available. in a second step one automatically uses more, because it is available. after a certain level the underlying components turn up to be a bottleneck, although they worked fine formerly ...
it's far too early for even estimations about specs and setups
christian

I certainly see what you are saying. At some point, some part of the machinery is going to become a bottleneck, if it isn't ram it will be cpu, if not cpu then the motherboard, if not that, software for some reason etc. However, is it not true that the lifting of the memory ceiling, will at least to some point, on presently fast and well configured machines, allow people to load more instances of VI and articulations than presently - considerably more? That's all that is being said, perhaps in an somewhat optimistic way I'll concede that but still, there is good reason for optimism to a degree (what degree is the question on peoples minds, but you've answered that, as you say, it's too early to speculate. Which is a shame! I was hoping it was only a little bit early!! [:)] It's great fun writing with VI but I get so bored waiting for the machine to freeze tracks and so on... takes forever, sometimes I have to go and shave or do my taxes in between freezing tracks only to find out that I want to change something so I have to do it again (freeze the tracks not shave).

Miklos. [:D]

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