Vienna Symphonic Library Forum
Forum Statistics

180,768 users have contributed to 42,140 threads and 254,362 posts.

In the past 24 hours, we have 3 new thread(s), 15 new post(s) and 57 new user(s).

  • DS and SSD

    I'm running a Mac Pro 12 Core, OS 10.6.8 (everything works!), 26GB RAM, Logic 9.1.8, current VE Pro.

    I have all 7200RPM Drives in my system.

    There are always discussions about usefulness/non-usefulness of using SSDs on the Mac. Do you, VSL recommend putting DS:

    1. on an SSD

    2. OK on 7200RPM Caviar Black

    3. Other?

    I don't want to set up a RAID drive as each drive is dedicated to a specific sampler (Kontakt, VSL, etc).

    Thanks in advance. I've done a little experimenting and DS with FORTI/SERTI is pretty amazing!


  •  I am interested in feedback on this, both for DS and for Hollywood Strings.  (DS performs well on my PC.  HS is bad.)

    While an SSD would definitely speed up load times, I wonder how much difference it would make once samples are in memory.


  • If I understand how VSL works I don't think the entire sample gets loaded in memory.  I think a "stub" gets loaded in memory and the rest of the sample is decompressed as it is needed probably like disk streaming.  So I think an SSD would make a huge difference as read times are much faster than a spinning disk.


  • last edited
    last edited

    @winknotes_282 said:

    If I understand how VSL works I don't think the entire sample gets loaded in memory.  I think a "stub" gets loaded in memory and the rest of the sample is decompressed as it is needed probably like disk streaming.  So I think an SSD would make a huge difference as read times are much faster than a spinning disk.

    Yes this is correct. Like most sample players, Vienna Instruments only loads the start of each sample into memory and streams the rest. However, with an SSD (and VI Pro) you could reduce the amount from the 6-0kb default to as low as 4kb.

    DG


  • Moving to SSD drives was the fastest upgrade I ever felt on my machines.  The speed difference was insane.  And I do not run Raid.  It isn't necessary.  The larger the SSD drive, the faster it will read the samples due to it's technology.  I highly recommend them.  I had recently hit a limit with my 7200 drives when I combined LASS with VSL.  After getting SSD's I lost all issues and pops and clicks.

    Maestro2be


  • Adding SSD's for my VSL and Kontakt samples is by far the better move i've done so far. No need for insane amount of RAM anymore, no more drives glitch and insane loading speed.

    I've put an SSD on my Mac Pro 2009 slave by adding a USB3 PCIe card and buying a cheap USB3 case from OWC. And I've put one inside my iMac on the 6G bus.

    Don't forget to reduce the preload buffer size in VIPro and Kontakt if you want to save some RAM


  • Is the 12 cores Mac Pro support 6G or only 3G bus Speed? If it's 3G you may be better with USB3 PCIe but you can use SSD in the 3G drive bay if you want but will have a speed limit around 250mbs if I remember.


  • That's great to hear.  I'm not using the big libraries.....yet :)  But I'm planning on getting an SSD for the samples.  I have one for the OS and windows never booted up so fast....even for Windows.


  • last edited
    last edited

    @Another User said:

    And I do not run Raid.  It isn't necessary.   

     And I beg to differ with you on this as well. I do actually run a couple of SSD RAID 0 arrays and the performance is, as you'd expect, considerably superior to a single drive performance. Whether it is necessary or not, it depends on what you're trying to accomplish. I have all my VSL libraries but DS split between two 250GB SDD's in RAID 0. I run VIP with a very low pre-buffer, and at latency 128, without a glitch, ever. Will put DS on a similar arrangement when it is completed by VSL.


  • Hi Peter, I'm running a Mac Pro 6 core at 3.1 ghz with 32 gigs of ram. I noticed a big difference putting Dimension strings and the Cube on a 512 GB SSD. I just got a 2nd SSD to put additional VSL and some East West on as well. They were previously on a 7200 Caviar Black. By the way, enjoy your courses :) Bill McFadden

  • last edited
    last edited

    @Another User said:

    And I beg to differ with you on this as well. I do actually run a couple of SSD RAID 0 arrays and the performance is, as you'd expect, considerably superior to a single drive performance. Whether it is necessary or not, it depends on what you're trying to accomplish. I have all my VSL libraries but DS split between two 250GB SDD's in RAID 0. I run VIP with a very low pre-buffer, and at latency 128, without a glitch, ever. Will put DS on a similar arrangement when it is completed by VSL.

     

    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.

    So back on topic.

    1.  No it isn't necessary to have RAID for what you are doing Peter.

    2.  Larger SSD's have faster performance due to their design technology.

    Maestro2be


  • last edited
    last edited

    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!


    /Dietz - Vienna Symphonic Library
  • 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


  • last edited
    last edited

    @Dietz said:

    It's not about peoples' lifes. 😉

    You sure about that, Dietz ?😊

    I feel like my life will be half spent in MIR, playing VSL stuff 😊

    On serious note though - what was previously said about VSL streaming being sequenced - isn`t true. While files are large indeed, and been written in sequence on the disk - individual notes are not stuck together, naturally. So when you play all those different notes/articulations, and pre-buffered portion runs out (split of second actually) - your disk has to pull out gazillion of random notes from their physical placements.

    Vlad.

  • 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.


  • 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.:)

  • last edited
    last edited

    @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.


  • Never said anything about defragment of an SSD. My point was - samples streaming is widely regarded as a random seeking and reading operation, thats why SSD is crucial. You don`t want to see it as such, thats your right. :0)


  • 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.