http://www.vpiano.net/pianosshootout1.htm
An interesting test. not on their sound, but on their performance, CPU and latency aspects.
The most interesting thing is that you can bet on the winner and there is a prize for who bet right.
Guessing Pianissimo will win?

Mostly latency is not a function of the piano software. It is determined by the operating system and audio device drivers. And then they measure loading speed? Who cares? and once again this is determined mostly by the computer hardware and operating system.

What they need to do is have a panel of judges and a double blind test. If you want to bet, let's bet on if they get the procedure right for conducting the blind test. Will they have a statistically significant number of samples? Will they roll the dice to determine which software is used or will they simply relabel each product and tell them which they are hearing? I'm betting they botch the procedures

Would be fun if they also included an recorded acoustic grand piano in the test as a control.

EDIT: I re-read there description. They say flat out "this shootout is not about the sound". OK we can forget about them. "performance and stability" is determined by the operating system and hardware.

Any musician who knows anything about this or who makes enough money to hire someone who does will choose the software based on the sound and playability and then run that software on whatever computer system is best for the selected software.

I think the BEST way to run a shootout is to have teams compete. Each team is give a virtual instrument software and then told "do whatever it takes" to make this sound good That may involve third party plug-ins (for eq and reverb) and MIDI filters that modify velocity curves. And of course getting the best computer for the task. This is that a real user would do if he were building up a system to be used on stage or in a recording studio.

The larger libraries can take a long time to load, and folks DEFINITELY care about this. (myself included). Kontakt 4 has received a huge improvement to instrument loading speed (wrt V3.X), and further improvements are planned. I believe that one way to drastically reduce loading time is to store the pre-loaded attack samples contiguously on the disk, so that the pre-loaded data can be read from disk as rapidly as possible. (I don't know whether Kontakt 4 is doing this or not, but I am reasonably certain that V3.X does not do this, even for instruments that are stored as a single file rather than seperate samples)

Other than the OS, drivers, and sample engine, the instrument design does of course greatly influence the load time. For example, a 4 layer instrument (perhaps using layer blending of some desciption) should load much faster than a 20 layer instrument.

Greg.

All samplers preload a small part of each sample from the disk into RAM. Otherwise latecy would be whatever the disk access time is going in through the file system.

The shootout said it was for people who play live on stage. So given that, how often do you load samples into a computer? Once each time it is powered up. You'd do this during a sound check long before a performance. If you need muliple instrument sounds you can load a half dozen or so in to Kontakt or Logic at the start. It is like the time it takes to unload a DP from a case and set it up on a stand.

Also load time depends a lot on the computer. If you have a solid state disk on a Mac Pro it takes just seconds

By their rules I think 4Front's TruPiano should win. Or maybe if it were in the running the grand piano voice that is built into Apple's Garage Band should win. It is rock solid stable, near zero load time and takes so little of the CPU it is hard to measure. Sound quality is however about as good as my Yamaha DP's built-in sound. But this shoot out is not about sound.

Chris,
I don't think you have understood me at all.

Yes, all disk-streaming samplers do pre-load the attack portion of the samples. What I'm saying is that whilst the OS and drivers do set some maximum load time performance, it can take creativity and ingenuity to achieve that level of performance.

Given that Kontakt 4 is MUCH faster than V3 (if the instruments have been saved by V4), obviously the load performance is NOT governed purely (or even mostly) by the OS and drivers, because otherwise V3 would have already been as fast as it possibly could be.

I then went on to describe a way that load performance might be improved - by storing that pre-loaded attack data CONTIGUOUSLY on the disk, so that it can be read sequentially, without the disk heads seeking all over the disk at the time the instrument is being loaded. Disk drives can transfer data much faster when the data is read sequentially. (as I'm sure you already know)

Greg.
P.S I am not sure that arranging the attacks sequentially is the thing that will result in the largest gain - it may be that the file OPENING is the slow aspect of the loading. One way to address that might be to store the samples in a single file, and avoid the OS having to open individual sample files. I tried this in Kontakt V3.5, though (via the "monolith" save option) but it didn't result in any improvement.

The problem is, that the preload buffer size is adjustable.
It could, however, on first load, build a cache file on disk and on consecutive loads load this. This would be compatible with all old libraries...

Edit:
But they have another strategie. They load in background and permit to start playing while loading. This would not be possible with continuous loading.
End Edit

Peter

Peter,
Yes, I understand that. It would be quite easy, though, to simply choose a sufficiently large pre-load size - one that noone is every likely to choose. The sample engine would simply discard the portion of the pre-load data that is not required, at the time it is performing the load. This may result in a very slight duplication of data on the disk. (and if on the off chance a user DID use an even larger pre-load size than this, then yes, either use your idea, or just fall back to the standard method and read the extra data in the normal fashion, resulting in a slower load time)

Greg.

Also, regarding load times not being relevant for live situations, I don't agree with that either. Yes, sometimes it won't matter, but I can think of some situations where the load time may be important:

1. Someone FORGETS to pre-load the instruments at the pre-scheduled time. ;^)
2. Instruments need to be unloaded from memory, to make room for others.
3. The system needs to be rebooted, or decides to reboot all by itself. ;^)

In general, "stuff happens" in real life, and a fast load time may be helpful.

Greg.

I think Kontakts approach is successful.

Default preload size of Vintage D is 280MB when the preload buffer is 60kB per voice.

After some seconds you can start playing while it continues to load. With a slower drive polyphony is a little bit limited while preloading.

If you have an SSD, you can reduce the preload buffer to 6kB. this results in about 28MB total preload size. It loads virtually instantly and has no polyphony restrictions during preload.

A problem is CPU usage. with my T5550 Centrino I can reasonably use 100-150 voices. I hope they improve that.

I think they did not want to adress the live players only, but also developers and studio producers. There are people that must load large library collections before they can start working. For these background loading is a heavens gift.

It would be genial, if they could decide to cache fast and medium fast sample portions on a SSD and keep the long sustained portions on disk. Then large libraries could be used with almost no load time and, say an affordable 16 or 32GB SSD.

Peter

Thanks Peter. Note that general load performance has also improved, seperately to the background loading, according to a report from a user in the Northern Sounds forums. (3 minutes down to 1 minute!)
As I said - the instruments have to be saved from Kontakt 4 to realise this improvement.

EDIT: Oops - I see that the user had gone from V2 directly to V4 - skipping V3.

Greg.