I recently migrated to a new PC with an SSD system disk. Being able to boot up so fast is great, but it makes me notice even more how long it takes to open a Cubase project. I’m thinking of getting another small SSD to store just a few “currently in progress” projects. So a question for anyone with experience on this front - Is this a worthwhile thing to do, or will I not see that dramatic an improvement?
Aloha r.
Is this a worthwhile thing to do, or will I not see that dramatic an improvement?
Improvement in this specific case or not IMHO
it is still a worthwhile thing to do because (except for some very special situations)
soon all HDDs will be SSD’s and you will already be there.
‘Don’t look back. Something might be gaining on ya’. —Satchel Paige
But when it come to:
__
how long it takes to open a Cubase project.
That’s a Steiny thang!
{‘-’}
Yup - I agree with curteye.
The loading time is Cubases’ deal, depending on how many things you have to load, ie; Kontakt, HALion, many VSTs, etc, etc.
If you have a spare SSD then, sure - try it.
What I do is save my projects to HDD and also back them up to an external drive as well.
I have my OS & Cubase and related programs on my biggest SSD, with my Kontakt libraries etc. on smaller SSDs for faster streaming.
So if you already have your OS & Cubase on an SSD, you may not see all that much speedier load time improvements, if any at all.
i would say its worth it if you can find a bargain. ssd prices are coming down all the time but if you keep a look out, even the quality ssds are sometimes put on really good offers.
the other advantage for a music computer is they’re silent, when i got a fanless psu i could hear all my hdds spinning away. now i’ve finally replaced them with ssds my computer makes no noise at all
I realized I could test the difference with my current config. I saved a project I have on a HDD as a backup on my SSD system disk. Then I timed how long it took each to open (with C7 already running) and they were basically the same - 13sec for the HDD and 12sec for the SDD. And that one second difference could well be due me trying to click on the filename and start the stopwatch at the same time. 
This test did expose a psychological quirk though. Booting my system in ~12 seconds seems amazingly fast while taking the same amount of time to open a project is a burden.
Regarding supertonic’s comment about noise, I take the point but I wouldn’t be removing an HDD even if I added an SSD.
The real test is mix down, take 50 audio tracks and do a mixdown on HD and copy the project to a ssd and do it again.
Makes sense & good to know.
Time to load Cubase is dependent upon the OS drive transfer rate. If you leave all you VST plugins on the OS drive as well, the scanning of those will also be dependent upon that drive.
Cubase itself does not appear to load up complete files at startup, except perhaps for the small image files so that it can display the waveforms. The audio files themselves will probably not be loaded at all, but just the blocks immediately required once playing. Seek and transfer times of the project drive will play a big part in responsiveness when dealing with lots of tracks.
MIDI is included in the project file, which is small enough to be fully loaded.
We have been all SSD for the last few years, but when I got tired of keeping only current projects on the projects drive, and SSDs were now cheaper, I went for a Samsung 250GB 840 EVO to store them all on a dedicated drive, along the VST(i) dlls, rather than a common data drive, which is now a smaller SATA II drive holding less timing-dependant stuff like documents, etc.
I converted all my 4 discs, 1 TB each, to SSD’s this spring. I haven’t used a stop watch but my impression is that it is no significant difference in loading time when it comes to any music related stuff. Can’t say I can see any difference in mixdown either.
Also “tested” Microsoft Office and FileMaker. No significant difference there either.
The reason for switching was a suspected fault in the OS disc that made programs crash. That problem is gone but this is not an argument for SSDs in general. The SSDs has no moving parts so the SSDs might be more durable. I do not however know if data are retrievable from a crashed SSD disc as the data are from spinning disc after a mechanical crash. Guess if a SSD crash the reason is pretty severe.
I was saving a mix yesterday to the project’s audio folder on an HDD and as a test did it again to my system SDD. Took the same amount of time on both disks. However it was just a simple little midi mock-up of a song. The results might be different for something larger and more complex. Or maybe not. 
Have to remember that a lot of DAW file actions are immediate and only working with the actual audio blocks required at the time. In general operation, there shouldn’t be much difference.
However, add samplers into the mix and load times are different for the first time you load up a library. If you load another then go back to the first, all the required sample blocks are most likely still in memory, so the there will be no difference - they will be the shortest time for both types of drive.
Also, there will not be much difference for small projects as the amount of data to be transferred is well within the capability of a HDD. But push the DAW harder with lots of audio tracks (or higher samples rates), and at some point, SSDs will come into their own.
However, there are many other benefits of SDDs:
- no heat
- no vibration
- very little weight
- no fans required.
Basically, SSDs allow a lot more mechanical flexibility than HDDs, especially compared to 3.5" HDDs. Certainly, SSDs weight less than HDDs, but SSD weights have been coming down, as the Samsung 840 EVOs weigh a lot less than the OCZs.
Where you should notice a difference is when saving across a network, as transferring audio files should be able to be done at 110MB/s, which is wire speed for GbE, but is heavily dependent upon the target’s write speed. Even with my WD Raptors, I rarely got that rate consistently.
I use nothing but SSD’s anymore, 6 internal and 2 external (for portability). I haven’t decided exactly how each is used yet. Must try for a bit, to maximize distributed use, storage capacity and convenience of handling (across machines). My latest configuration use 1 for OS and installation files (for applications and plugins, some require quite a bit of storage), 1 for projects, and 3 for media (via MediaBay). I use the external ones for moving things (e.g. projects and new media files) elsewhere. I still have network storage for media, but am trying out local copies.
Is it worthwhile then? Absolutely, same situation as when I got my first hard drive back in the Atari days, a 20 MB (or maybe 30, can’t remember anymore), which by today’s standard doesn’t compare, but compared to a floppy it was fast. Compared to HD’s, SSD’s are lightning fast.
SSDs trounce HDDs in every performance parameter.
However, they do not operate in isolation. In a general computer, overall performance is dependent upon CPU, disks and video, each mitigating against huge performance advantages in the others. With DAWS, video doesn’t have to be spectacular to be sufficient, so if disk performance is exemplary, the single limiting factor is CPU.
Considering how much the CPU is critically doing in a DAW, once SSDs are installed, the limitations in one’s CPU show up. We often see huge transfer rate specs for drives, but rarely see those rates when using the OS to transfer files, just because of the overhead required in the OS, utilities and programs themselves.
Which is why, though SSDs are far superior, the real-life net performance improvements may only be marginal. Mind you, while changing from HDDs to SSDs is not hugely expensive these days compared to the average weekly earnings, to get the same level of performance improvement in CPUs could be the cost of a new car!
5.25" docks like this make SSDs really useful, while also allowing front fans in the drive bay areas (internal bay and behind the lower three 5.25 bays) free flow to cool the computer better.
Forgive my ignorance, but I though that SSD’s still had issues with repeated deletions and re-recording causing dead areas and that this was the reason they were recommended for the C drive, but not for the project drive. This sounds like old info, but no one has mentioned it.
1 Like
Don’t know if it is true. I never delete anything. Using a 1 TB disk and change disc when it is full.
Each block on an SSD has a limit of 10,000 writes for an MLC drive, which is what most consumer SSDs are.
Now, to prevent any one block being thrashed to the limit ahead of others, SSDs use what is called ‘wear-levelling’ to spread the writes evenly over all available blocks, that is, empty ones. The drive only pretends to write to the same block as far as the OS knows, but it is being directed to different ones all the time. This is similar to bad block management on HDDs
To further allow some redundancy for future write-exhaustion, SSDs keep some capacity from being directly used, and swaps blocks with the ‘visible’ ones to further level the wear.
Now, even if a block has reached its last write, it can be read indefinitely, so data is never lost, but the capacity reduces for new writes.
However, even writing the same block five times a day, it would last 5 years, so as long as there is enough spare space on a drive, it will have enough wear-levelling blocks to probably get to fail completely before one block ever reaches write-exhaustion. For project drives, most blocks will be static (recorded tracks) and any one block may go for days without being written to again.
Of course, for sample users, an OS or data SSD that may have started to lose capacity can be used for less used libraries until it fails.
Now, over the years, people have brought up that the Windows page file may write thrash an SSD. However, writes are cached in memory, so that, as telemetry has shown, there are many small reads from the page file, but few writes, and mostly of 1MB.
Thanks. That is an interesting answer, I will have to think about investing in SSD drives when I commission my next computer.
Where you’d really see a difference is with large sample libraries. an SSD can cut the loading times of these by more than half (all the way down to a quarter.
So if your projects relay on “heavy” sample libraries (Kontakt, etc), then they will load considerable faster.
Mainly because it is a fairly unimpeded read (by the OS or the program = less CPU overhead) of a whole lot of large blocks (initial blocks of each sample in the patch).