There will always be a bottleneck somewhere: either buss speed, processor speed, available RAM or disk throughput. And as soon as computers get fast enough to run 800 voices with 50 Vienna Instruments on a single computer, I'm sure VI2 will be announced. [;)]

But this makes me want to upgrade my system, at least to a Core2Duo with an upgrade path to a quad.

@Nick Batzdorf said:

Cakewalk and Steinberg were hawking 64 a couple of years ago (but they aren't really doing that now), and some audio hardware companies have 64-bit drivers, but in general I haven't heard software companies tout this as much as you'd expect if it's really close on the horizon.

Same here.

J.

@mpower88 said:

RE hard drives: if the drives are slow loading just buy more drives! if you have 10 X 20 gig drives on a PCI card, 128 GIgs is going to load REAL fast don't worry. Just distribute the instruments over the drives.

Miklos.
[H]

Hi Miklos,

The VI's appear to load at between 15% - 25% of the rated transfer rate of the hard drive. Also when a number of drives are utilized these figures do not scale at anything like 100%. I can currently load up a single 2GB file into RAM (from a 4 disc SATA raid) in a few seconds but to load 2GB of VI stuff takes a number of minutes.

The net result is unless there is a significant speed increase (x20) in speed of file transfers of the VI type switching between songs would become impossibly slow with RAM amounts approaching 100GB.

However what would speed the whole process up immensly (even now) is if the VI's (when used within a host) could scan current RAM to see what was already loaded - like the "keep common samples in RAM" function in Logic.

.... and what would be even better if a similar function could occur even if the song you were opening was replacing one that was being closed.


Julian.

Here's a thought (and pardon if it's not reasonable):
In Digital Performer you load VI's into a "VRack" which allows you to switich between sequences in the program with no waiting. Of course when you close or open up another file with say, another film cue and Qtime file etc., everything reloads and you sit and wait.

What if the program itself allowed a VRack type host to remain open or at least allow samples to remain in ram (as mentioned above) untill you actually quit that part of the program?

This may be of no help, but I just thought that I'd share my brilliance with you in case there is an application for it in your case....!

I was finding that when changing projects it was taking 15 minutes to load samples and as soon as I wanted to switch projects they were all being dumped and I was having to load again. I am using FX-Teleport as a host and this is where my genius comes in. I load my whole template for each PC into Forte on my DAW, but using the LAN version of VI. In other words I do exactly the same thing as loading in Nuendo, but instead I'm doing it in a VST host. Now the clever bit. When I open my project I load exactly the same samples, but this time using Nuendo as a host. Of course VI knows that these samples are already loaded into FXT so it doesn't load them again (actually it takes about an extra 79MB up). Now my template is up and running immediately, I can change projects, close Nuendo and all the samples are still loaded when I open the project up again. This means that I can change projects instantly and have all my samples available without loading. I just have to make sure that either Nuendo or Forte (or both) is open ay all times.

DG

Okay so basically you load all your samples outside of the DAW in a VST/AU host so they remain in RAM but you don't use the external host. Of course that begs the questin of why not just use the host program. Fotr me the answer is I have never been able to run Plogue outside without performance issues.

Do I undestand your idea correctly?

Loading in the DAW is much more convenient when it comes to mixdowns, using plugs etc. I can also have almost unlimited VST outputs, whereas using the Host I'm limited to what my hardware has.

Regarding performance issues in the host, as I don't have any MIDI input or audio outputs enabled there is no chance of a problem

DG

Right, of course.

Julian sounds like cpu will fix that eh?

Nick: why would OSX be 64bit in Leopard, with 64bit Apple apps coming soo after? Why would they bother if it wasn't the direction of the future.The fact is that 64bit is necessary for the coming years because of hard drive/storage and memory access. It's like people used to say why would you record in 24bit when you're mastering to 16bit! What a rediculous argument, yet people made it earnestly everywhere I went, but I always said you can't compare 24bit to 16bit even on a master.

Miklos

@mpower88 said:

Julian sounds like cpu will fix that eh?

I think that will help. When, for example, you are doing a Retrospect back-up and large files are being archived the data transfer rates are as much as a hundred times quicker than when the system, library and cache folders are being backed up when tens of thousands of files are being copied.

So the consideration with VI's is not only the RAM amount but the number of files (headers) and currently the sheer number of files requred - which is a direct by-product of the quality/flexibility of the library - appears to be the limting factor in load times.

So although many users (me included) want to load more VI instances and larger matrixes, once we head south of 10 GB's of RAM I suspect the limitatons will start to come from the drive/cpu access and load speed. I'm not an expert but it is possible CPU increases will help, alonge with I suspect further, VSL software evolution.

Julian

No question, Miklos, we're headed to a 64-bit world. Absolutely, 100%.

My only question is about the timing. It seems to me that we'd be hearing a lot more noise about it if it were just around the corner. So far I haven't seen a single press release saying "XXX announces 64-bit version of YYY."

You could argue that they're just waiting until it's ready, but most companies don't do that. They all sent out press releases saying they were doing universal binary versions, for example, even though they didn't appear for several months (and some are still appearing).

Remember, 10.5 will run 32-bit programs too.

And frankly, the old "run stand-alone version outside your DAW and access all the RAM you can eat" trick has me less excited about 64-bit computing.

Also, I'm not entirely sure the 24- vs. 16-bit analogy is all that à propos. 64-bit processing is unlikely to result in better sound, in fact it's not even a given that it's going to give us any more plug-in horsepower in all cases. What it will do is give us unlimited memory access.

Nick: it seems widely accepted and publicised that Vista is 64bit. AMD have their 64 bit chips, Core2 duo "64bit", which has been marketed as such, and there seems to be a considerable difference in speed over the last gen of intels, how much that is because they are 64 bit or for other reasons I don't know - and of course OSX has been 64 bit for a long time which is now going to be 64bit at the GUI level too. All this is widely known and publicised.

Miklos.

My hunch is that, from a marketing point of view, Apple would very much like to be able to announce 64bit - - versions of its Pro software applications (including Logic Pro) that can make use of as many processors as a machine has - - along with OS 10.5 and 8 processor core hardware. What better way to advertise the advantages of OS 10.5 - - and to give Apple a chance to sell pricey (e.g. perhaps "only" $399.50 for updating to "Logic Pro 64 Xtreme") updates? Whether or not such a time table is practically achievable is another question, but perhaps we will have some hints at MacWorld Expo in January. In the meantime, we have to hope that the price of ECC FB RAM starts to decline significantly.

Miklos, I think you're missing my point.

A 64-bit computer system has the processor, OS, *and programs* running at 64 bits. Without all three you still have a 32-bit system, and the last to fall will be the software. It will happen, but the question is when.

I think it's going to take a while.

Also note that right now Mac OS X is only 64-bit capable for programs that don't use its graphic interface - i.e. UNIX command line programs. As a practical matter for you ane me, that rule out every program on the planet.

Nick: I think I said, that Leopard will be fully 64 bit thoughh and that is not far away.

Ram prices will fall once people start buying more. People will start buying more when they can use it...

64bit apps will become the new marketing fad, because the cup manufacturers are making the chips, now it's going to be, this app is 64 bit this one is not. Properly written apps will surely demonstrate the difference even to modest users I think, well, that part is just a speculative opinion I admit.

Miklos.

@Nick Batzdorf said:

Cakewalk and Steinberg were hawking 64 a couple of years ago (but they aren't really doing that now), and some audio hardware companies have 64-bit drivers, but in general I haven't heard software companies tout this as much as you'd expect if it's really close on the horizon.

64-bit versions have been available to all Sonar customers for two versions now, so... I'm not certain how that qualifies as not "hawking 64". I think for many PC users (at least this one) it's just taken as a given that it's available now (you don't see many headlines about features that have shipped a year ago). At least for me, it's just about the cost of upgrading to a new platform that's holding me back, but I'm saving my pennies...

There's a few links here about the state of 64-bit computing that are interesting, as well as the obligatory promotional stuff from Cakewalk and MS.
http://www.cakewalk.com/x64/

Thanks a lot James, that was a good link and very interesting.

Miklos.

I have been reading this technical discussion with interest but actually understand very little of it other than loading up with lots of RAM will not solve all problems. Could someone please tell me what an optimal amount of RAM is for today's dual processor Intel Macs. Thanks loads.

Hi Jerry, at the moment 5 - 6 gigs is sufficient in a Mac machine if it's a tower I don't think you can get that much into an imac or mac mini or laptop. The softwrae doesn't use more than that so buying more is a waste of time at the moment - with the exception that there are some work arounds people have done where you can launch two lots of VI on the same machine - there are threads somewhere here on the forum which I haven't read haven't got to it yet - perhaps someone can post a link if they know off the top of their head... However once the apps/os and everything is 64bit capable the software will be able to use more than the current limit of approx 3 Gigs of RAM and will be able to access as much as the machine can physically hold - ie. 128gigs will not be a problem, neither will 10,000 Gb ram (not physically possible right now of course!).

For your purposes you need 1Gig for Logic, 3 Gigs for VI to have plenty of room to load samples (although I think it hits the ceiling at around 2.7 Gigs, people have had mixed results I think) and 1Gig for OSX Mac system - that is to leave plenty of room to move you don't want your machine to start doing a lot of hard drive swapping while running Logic. So 5 - 6 Gigs is a good amount, plus you can keep ichat, mail and safari open if you want to as well.

Miklos.