@JWL said:
...if the CPU won't increase in speed substantially, then Apple opts to put more of them in one machine. Very odd in a way.
But other things will have to improve to get the best out of VIs-- hard drive speeds and transfer rates as a standard would be my first desire for improvements. Bus bandwidth would also be among the most important improvements.
While I'll never expect that one computer will run much more than a handful of instances of VIs needed for a full orchestral realization, it remains a little strange that more can't be done on one computer than is currently possible.
The "multiplying" of CPUs seems pretty much unavoidable to me -- unless they come up with a fundamentally different paradigm for processor design. There are physical limits to how far the current approach can go (power consumption vs heat dissipation), which we first saw when the early 90-nanometer chips hit the shelves. It was a bit of a fiasco, really...
But the RAM thing is still a strange and interesting problem to me. I think you're absolutely right about hard drive and bus speeds being the primarily focus for the work we do. Some of the advances in flash-based drives, like Samsung released back in the summer (I haven't looked into this lately... any improvements?), are quite promising. IMO, we're kind of looking for the wrong solution by wanting all our samples to be loaded into RAM. The speed of RAM today is necessary for *calculations*, but is basically overkill for playing back samples. Yes, when you've got loads of samples to play in that time it's a somewhat different story, but that could also be dealt with using a flash-based HD on an appropriately designed bus (don't know the numbers, but PCIe is probably already capable). But if you keep in mind the fact that all the samplers we've been using for the last few years have been "streaming" samplers anyway, then it's quite clear that it's only the first few milliseconds of playback where there's a major issue. With a device that could deliver in those first milliseconds (i.e., the next-to-zero seek time of a flash-based HD) we should be able to stream to our heart's content. Anyway, I don't think loading more and more into RAM is the only, or the best, way of improving sample-based work.
The other solution, which I mention whenever I get the chance, is to merge the sequencer and the sampler at the lowest level possible. I keep pestering everybody with a VSL-designed and created notation-based sequencer because I genuinely think that will be the best solution. The fact is that, except for those times when we're literally *playing in* a new part, we absolutely *do not* need all those samples to be loaded in RAM! For the most part, the incredible speed that RAM is capable of is wasted on storing samples for music that is played back in precisely the same way everytime we hit the "play" button. If VSL authored a sequencer, even if it wasn't notation-based, they could address the preloading of samples based on the information contained in the sequencer track. In the simplest possible model, they could create a system whereby, once a passage is recorded, a sample list is created, with timestamps for sample preloading. The preload timestamps would be placed an appropriate period before each note, say 50 milliseconds (overkill, probably) and the sample head would be buffered in that window. I built a system like this in MaxMSP and Java which actually worked quite well (though, not being a sequencer itself, it needed to analyze midi files to build its sample list), and those are definitely not the best-suited languages for this kind of work! (In a more sophisticated version, the timestamp could be calculated dynamically, in order to more efficiently distribute the workload in busy passages.) But of course, if you don't know what note's coming, then you can't buffer the sample to play it, so unless VST is given a view on the entire sequence (does VST 3 support this?), then we won't see this *extremely* simple solution implemented, since plugins remain completely blind to the future.
Anyway, the point is that unless we plan on having 50 keyboard players on stage, all playing a single VI each, *live*, then there's absolutely no need to have all those samples playing from RAM on each and every pass.
J.