Though I think it's a long way to go for the benefit of being able to play a sample from some point other than the start...
It's more than just being able to do that. It reduces instrument load time as well, and it removes the "process" of pre-loading, which may simplify the system design. I.e - the fact that the attacks no longer have to be treated any differently to the rest of the sample may ease the system design a bit. I don't necessarily think it's "a long way to go", either. I think it is a long way for YOU to go, because it seems so foreign to you. ;^) The East West Play documentation mentions that it has now been optimised for SSDs, which reduces instrument load time. There's a bit of real-world evidence for you that it's a worthwile thing to do - even when using SSDs.
(it's a bit vague on detail - I think it does still use a pre-load, but a much smaller pre-load. The way it is worded suggests that it may actually use no pre-load for a certain percentage of samples in any given instrument though, which would be interesting) EDIT:
Well, that's not really evidence that they feel it worthwile to try to eliminate the pre-load completely. However, I don't see why they wouldn't completely eliminate it if they could.
Anyway, just to be clear (and I think you know this), it's not the case that a computer could operate with a hard drive but no RAM at all if it weren't for the fact that the hard drive is not fast enough.
It most certainly IS the case. All that matters is that the data be able to be loaded into the CPU, so that it can operate on that data. I completely disagree with that statement.
Even if a hard drive (or in this case, SSD) was fully as fast as RAM, the processor "sees" them differently, and the NAND flash used in SSD is seen as storage and not as memory, so the data still needs to come off the storage mechanism (SSD) into RAM on its way to generating the sound.
Again - I completely disagree! The SSD, whether it uses NAND FLASH, NOR, or magnetic core memory from 70s, can look EXACTLY like memory to the CPU. All that is needed is the right interface hardware. The CPU generates the address that it wants to read to or write to, and then the interface translates that address into some action on the storage.
But yes, the faster the storage device, the less RAM should be needed for pre-load... and perhaps there is a point where the pre-load can be eliminated completely, and I guess that's really where you're going.
I'm afraid you've lost me on this one... I don't see how that response relates to the part of my post you quoted. Maybe I didn't understand what you meant about the data for voices being "co-located" which is at the core of this question. But basically, what I was saying is that, as access time on a non-moving device is effectively zero, the actual location of any data on the device is irrelevant. (Except to the extent that only certain kind of access can be done at all, and then we're back to NAND vs. NOR.)
Taking the example of playing two notes together, and assuming the SSD has an access time of 0.1ms, can you not see that the minimum time between the two notes must be 0.1ms? Remember - the access time is the time taken for the SSD to switch from reading data from one area, to reading data from another area. Obviously, the sample data for these two notes will reside in seperate locations on the SSD. The sampler reads each sample sequentially, and in little blocks, switching rapidly between the two samples as it proceeds through the two-note chord. Each time it switches, it takes 0.1ms.
Now, for the simple case of a stereo sample, we'll still only have one "sample" file - one stream of data. The two channels will be stored in an interleaved fashion in this sample file, so that as the sample is played, we will always be reading from the same area of the SSD, assuming that the sample is not fragmented. We will be reading sequentially through that sample, and in this case, the access time is irrelevant (except for the Note-On latency, which will be at leasts 0.1ms. We will need to buffer the data from the SSD to ensure seamless playback, too - that's where it differs to DRAM) - what matters here is the sequential transfer rate (which is absolutely huge - hundreds of megabytes per second).
Taking this further, I'm suggesting that what Korg might be saying is that it may store, for example, multiple mic perspectives for a piano interleaved in each sample file, and this is how they get the inflated voice count of 400 - it's still reading from 100 physical sample files, but each sample file consists of 4 channels of audio. (two stereo channels, or four mono channels, etc. They seem to be saying that one voice is "dual stereo", so perhaps it's really 8 mono channels?)
If this is true, the transaction rate is 4 times less than it would be if each mic perspective were stored in seperate sample files, because each transaction would read a gob of data from all 4 channels.