Although you have no clue whatsoever who I am, you dare to (dis)qualify me in a manner completely extraneous to the spirit of this forum. I welcome an open discussion here, but despise your arrogant out of place attitude.

@Another User said:

Here you contradict yourself.  First you say you don't agree with me, which basically means, you say it is "necessary" to have RAID.  Then you go on to say that whether it matters or not depends on what you are trying to accomplish.  So which is it?  Is it necessary, or is it just your preference?

The OP made it clear what he was trying to achieve and also stated he didn't want RAID.  Never did I claim that it wouldn't increase performance, as again I do this for a living.  It will actually massively increase throughput.  The problems arise though with simple users having to maintain more advanced setups.  If he loses that RAID 0, any drive, he will be rebuilding from scratch.  AFTER he replaces the drive.  So place all your samples on a RAID 0 and then lose 1 drive and watch you sit there waiting for that failed drive replacement.  Versus having seperate SSD's housing different sections/libraries and only losing a small portion until it's replaced.  Additionally, you can get and should have a backup drive to backup your data on.  You could keep a copy of all samples on this huge backup drive, and in the time that one drive fails, use it to cripple your way through until you replaced your failed drive.  But this is all much more advanced than what Peter was asking for.

Typically RAID just becomes to much headache for the average user and with SSD's speed it isn't a "necessity".  The good thing is I know Peter, and he is a very smart man and will be able to decide for himself after he reads all the advice given to make the decision that is best for "him".  Especially based on his already voiced requirements and opinion of not wanting RAID.

Let me remind you that it was you who brought up the term "necessity", not Peter, not me. And what maybe "necessary" for you is not necessarily so for anybody else. Thus my disagreement. You are asserting, I'm simply sharing my point. And yes, the decision to use RAID  or not is up to the end-user.

I do run multiple instances of VEP5/MIR with multiple instances of VIP, Kontakt, and sometimes Engine, with concurrent multiple libraries streaming at the same time. I can certainly confirm that the RAID arrays I use now have enabled me to run a heavy template, on a single 12-core i7 PC, totally issue-free. I could not do this before. That simple.

To finalize, Peter, from previous threads I've seen, VSL will unlikely provide a recommendation to your question, now. And if you're wondering why, for what it's worth, my opinion is that because the library is still not complete, they don't necessarily know the final size, amount of samples, complexity, etc., thus it'd be irresponsible to advise at this point. Also, the way you use the library (matrix programming, number of instruments, etc) will also impact the required resources to run it, the way you need it to run. What they do say now is (posted on the DS page):

RECOMMENDED

• PC Windows 7 (latest Service Pack, 64-bit), Intel i5/i7/Xeon
• Mac OS X 10.7 (latest update), i5/i7/Xeon
• Fast separate hard drive (7200 rpm or faster)

Dear all,

while we like passionate discussions in this forum, we ask you to stay polite and well-tempered. It's not about peoples' lifes. ;-)

Thanks!

Sorry Dietz :).  None the less, there is plenty of good information in this that should help Peter make his decision :).  I am really tempted to keep it going, but after reading it a few times it could all just be internet misunderstanding.  Emails and electronic information is so easy to misread :).

Maestro2be

@Dietz said:

It's not about peoples' lifes. 😉

Is that an empirical observation???   You are not constantly reading a gazillion individual random notes when your prebuffer runs out. Even if it did, do you know how large a single note sample is? 50KB? 200KB? If you are reading that single note from disk in contiguous "pages" of 4KB (per Windows default size), then you're indeed reading 12 to 50 pages sequentially. On your system drive, where the OS constantly R/W the drive, data do tend to become fairly randomly disaggregated. And chances are that there will be a fair amount of 4KB pages alocated all over the place. Not the case with your typical sample playback drive.

@Vlzmusic said:

Gusfmm You have to make order in those calculations.

Typical full Vsl instrument - 5-7 GB on disk. You play G4 sustain, then legato jump to C4 - there is physical distance between those two - you are not playing back something sequential, as in file copy or movie watching.

Now multiply this for 20-30 instruments you might use in a track (150-200 gb of data spread on the disk) - if you use layered patches, multiply each voice by 2-4 as well.

-----EDIT------ Now I re-read your last post and got your point. You mean each note within itself is not fragmented. Ok - it might not be, if you defragment (those large files can be fragmented as well). But when you play - notes are triggered, and that`s called random in my book, even if each note isn`t fragmented. I am glad if someone`s Caviar black does the job, but prefer SSD solution, specially once the dimension series is now about full orchestra individualization - that`s about 50+ instruments.

Have a great weekend.😊

No disrespect intended, but you've got to understand how a SSD drive writes and reads data to be able to argue this. Let me be very brief and simplistic, as this is getting way off topic.

SSD's should not be defragmented, there is no need to. On the contrary, the nature of the operation of a mechanical drive writes data in a fragmented way, thus benefits from defragmenting. That covers part of your comment.

On the other part, a sampler player such as VIP does not handle these samples as individual notes being randomly loaded from disk. I understand you think your "random" playing may translate into random disk reads, but that is not the case. Keep in mind there is a pre-buffer that is allocated and managed dynamically... too long to explain, but I'm sure this is not the first time I've seen a similar conversation on the topic in similar forums.

Last point, while your symphonic composition may be playing back say 80 simultaneous notes with 2 or 3 layers each (a stretch) at a given point in time, that would be, in your mind, that 240 "random" samples read from disk. First, they are not being streamed instantaneously from disk, there is a prebuffer likely handling a good part of that load; and secondly, if they had to be read instantaneously, my point was that you would have "simultaneous" 240 I/O calls to disk, and the determinant factor for performance would be the sequential read speed, not the random read speed, as each of these samples would most likely be chunks of 200KB, 1MB, 2MB, whatever, that are read on the SSD as sequential "pages" of 4KB each. So take a single 200KB sample. That'd be 50 sequential (likely, ideally) reads, not random reads. The sample is very unlikely going to be highly fragmented. In summary, you are comparing 240 "random" locations on disk, vs. a total of over 10,000 sequential page reads. Hope this really illustrates the concept for you, in an orderly fashion. It was always that way.

Nobody is arguing the superior performance of a SSD.

Things is Vlad, Gus is right. Sample streaming performance is not down to the random read speed of a drive, although that might seem like a logic train of thought. Gus actually explained it rather clearly, but one does need to have a bit of understanding of SSD drives and how they work to fully understand what's at work in a music production usage scenario.

On the topic of RAID, it's not exactly neccesary, but due to the serial nature of loading samples in a template (one VI loading it's samples, followed by the next, and then the next and so on), RAID will give you substantially faster loading times, but ONLY if your drives are of an older, slower kind. Many SSDs of the newest generation will be able to nearly saturate the S-ATA bus in a single drive scenario, so adding two together in a RAID might give you very little bang for the buck, while increasing the likelihood of failure in the array.

I'll agree with you that the files in the VSL folders tells us nothing about how the files are actually read, as Gus seemed to imply. These large files are merely containers for the samples compressed with VSL's own compression routine. But nevertheless he's correct in saying that random read does not govern the performance of sample streaming.

Few (music)people seem to understand that sample streaming performance is largely decided by the drive's ability to maintain high sequential read speeds at high que depths, which is what people confuse with random reads. Just looking at a drive's sequential read speed tells you absolutely nothing about how the drive wil fare once you start hitting it with multiple streams, so knowing how the speed of the drive drops at increasing que depths is the essential thing to look out for. Some of the fastest drives on the market completely collapse at que depths of 32 and more, to the point of having worse throughput of even some of the faster mechanical drives(!), though the crappy seek performance of mechanical drives would make them crackle and pop long before this would become a problem in a SSD-based usage scenario.

Oh and one last thing: saying that larger SSDs have better performance than smaller ones is a stretch. It's entirely down to the design of the drives. Going from a 128Gb drive of same make to 256GB one might yield double the performance in some categories, while going from 256GB to 512GB could show equal or even less speed. Some manufacturers might even use NAND of differing fabrication size within the same model range, making for less transparency in what performance one is to expect from a drive.

These things make it impossible to make any wholesale arguments like "bigger is always faster".

When using VIPro with smaller buffers (2048), you can easily end up with prebuffer sizes of 8kb. This way, the most important characteristic to look for in a drive would be the "8k random read" figure. Normally, reviewers run 4k random read tests - which is the number I generally look at for sample streaming performance with SSDs. 

 Martin,

Let's take your example of a prebuffer size of 2048. So what you're saying is that because the prebuffer per-sample allocation is 8KB (256 samples), the most important characteristic is random read speed. I'd like to understand the rationale behind that. Let's go step by step if you don't mind,

Could you clarify what 'typically' happens when I press three keys on the piano and trigger three 'voices' on a single instance of VIP. My impression is that VIP plays back the 3 x 8KB buffered sample starts while simultaneously proceeds to load and continue streaming the rest of these three samples from disk, is this correct? If it is, what would a typical note sample size be? Let's say a regular legato note?