SSD worth for Libraries? DAW?

[kingozrecords]

can you tell me if the piping is done efficiently on my machine?

I know we r crippled, half the world is on Windows,
and our machines don't spin up before we have underruns

-I'll be back with the SSD and RAM

this is the system==>
https://www.dell.com/en-au/shop/cty/pdp ... -area51-r5

edit- is quad channel DIMM the right RAM stick?

Your system is very competent, I think the greatest challenge you face like most is having virtual memory (a cache drive) that is accessible to your processor. You could do this with an enterprise pcie ssd. Likely that would be the best orthodox way because you should have an extra x16 pcie slot.

I looked up the details here

In regards to your cpu, it's nice too; am I right in saying it has 6 cores? I'd need to know your exact cpu because there's many options available. I would say eight core is best, but that depends on the single core performance. It would involve a lot of research and comparison.

Quad channel is ok yes, dual would be the fastest. If you were to span 16gb into 4gb sticks though, multi-threading has potential, it all depends on whether or not you're doing video editing. it depends entirely on what your computer is doing. Audio uses less files.

8gb for instance could be spanned into 2gb sticks, allowing for better multi-threading. That would mean the timing (like a piston) would fire very competently for the processing of small files.

8gb+ = gaming/video (even imagery [except hdr] uses less), a very particular niche. a v12 lamborgini diablo is not as fast as many v8's for instance.

In My opinion, it would be best in the way of video editing to be using:
4 x 8 gb 1866 @ddr3
4 x 3200 / 2666 @ddr4

I have been looking at this post on reddit:
https://www.reddit.com/r/pcmasterrace/c ... indows_10/

I'm looking into options for setting up maybe one or two sas hdd's for kontakt / virtual memory so I can make the most out of My ssd running My os.

I'd like to add that pcie, any gen can only provide 4 lanes to a sas connection. I would not recommend bifurcation i.e raid 0. Finding a 12g sas x1 x4 pcie 2.0+ card is a daunting task but I feel it can be done.

The problem is that ssd's, whether sata or m.2 are the same price. This makes Me look for even faster sas ssd's instead or more realistically u.2 ssd's. If I'm to pay the same price, I may as well get more speed.

It can only process so much data at one time. If another (faster, better connection like SAS or U.2) was dealing with the needs of virtual memory that would be a fast system indeed. It would likely be very difficult to move to sas entirely; but bloody sweet for a cache drive, there's nothing better.

Here is a guide of mtbf comparisons (mean time before failure), regardless of warranty.
Brands that do not provide such ratings are omitted.

1tb SATA SSD mtbf comparison:
1,500,000 Silicon Power Ace A55 1TB 3D NAND 2.5 Inch SATA-III
1,500,000 Samsung 980 Evo 1TB SATA 2.5 Inch SATA-III
1,500,000 Mushkin Enhanced RAW Series 2.5" 1TB SATA III 3D TLC
1,750,000 WD Blue 1TB 3D NAND SATA III Internal Solid State Drive
1,750,000 WD Black 1TB 3D NAND SATA III Internal Solid State Drive
1,800,000 Crucial MX500 SATA III SSD 3D TLC Internal Solid State Drive
1,800,000 Seagate IronWolf 125 SSD 1TB NAS Internal Solid State Drive
2,000,000 ADATA Ultimate SU800 1TB 3D NAND 2.5 Inch SATA-III
2,000,000 Patriot Burst 2.5" 960GB SATA III Internal Solid State Drive
2,000,000 PNY CS900 2.5" 1TB SATA III 3D NAND Solid State Drive
2,000,000 WD RED SA500 SATA III SSD Ultra 3D Nand

article: https://www.zdnet.com/article/ssd-relia ... nterprise/
The best news, which was the biggest worry when SSDs came out a decade ago, is that flash wear out is a non-issue. Even after 2-3 years, less than two percent of the rated life is consumed on average. Even the drives in the 99.9th percentile have consumed only 33 percent of their rated life.

Here's a comparison a pcie 1x 2.0 ssd adapter (samsung 970 plus) vs a seagate skyhawk 4tb @7200 rpm.

A quick caveat: I realize most secondary ssd's will only use 2 lanes, and pcie mounted ssd's will share lanes (meaning you'll only get two lanes worth of speed). It's a worse case scenario. Maybe you'll get lucky?

Pcie 3.0 and 4.0 can use 4 lanes for m.2. But in version 2.0 there could only be 2 lanes employed. For older pcie versions however, u.2 had more potential.

SSD PCIE x4 (4 lanes)
gen3.0 2010 3.938 GB/s
gen4.0 2020 7.877 GB/s

SSD PCIE x2 (2 lanes)
gen1.0 2003 0.5 GB/s
gen2.0 2007 1 GB/s
gen3.0 2010 1.97 GB/s
gen4.0 2020 3.94 GB/s

SSD PCIE x1 (1 lane)
gen1.0 2003 250 MB/s
gen2.0 2007 500 MB/s
gen3.0 2010 985 MB/s
gen4.0 2020 1.969 GB/s

cheap pcie 3.0 4x adapter: https://www.amazon.ca/PCIe-NVMe-Adapter ... 094D8FSKM/
good pcie 3.0 4x adapter: https://www.amazon.ca/dp/B01FU9JS94/?th=1
cheap pcie 4.0 4x adapter: https://www.bhphotovideo.com/c/product/ ... _pcie.html

[nix808]

I'll read that again, Pentaguishine.
thanks so much,
I understand now a cache drive will certainly help(I have a spare slot)

The system does seem to bottleneck somehow, but I argue that is an intrinsic issue of Windows pcs

There are 20 logical cores of i9 at more than 4.3 under boost
the processor is this==> Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz 3.31 GHz

[kingozrecords]

I'll read that again, Pentaguishine.
thanks so much,
I understand now a cache drive will certainly help(I have a spare slot)

The system does seem to bottleneck somehow, but I argue that is an intrinsic issue of Windows pcs

There are 20 logical cores of i9 at more than 4.3 under boost
the processor is this==> Intel(R) Core(TM) i9-7900X CPU @ 3.30GHz 3.31 GHz

It's a nice processor, I see people saying it's weaker for the quad (which 97% of apps would employ) and it says that it can cause memory latency. You'd want to find the best ram with the least amount of latency, the lower cas the better, and you'd want to avoid adapters like pcie because there would be latency there too, some exceptions.

A real beast, if every traditional hdd you had was a sata3 ssd, that would be a start, and also I think having a secondary ssd m.2 acting as a cache drive would make sense. Many guides warn of only being provided 2 lanes and also pcie adapters sharing lanes, it's all too true.

Maybe x16 pcie ports for gpu's though would not share because there are attenuated into various provisions (x1,x2,x2,x3,x4,x8,x16), as a switch is required. That may mean if you need to use an adapter you could use an x4 ssd m.2 card. Keeping in mind, only 4 * 2 lanes will be used max. 16x can not be used to its fullest by ssd in pcie.

If one of those ssd's was a 128 ssd for virtual memory 1/4 of your bottleneck would be gone. You'd need to look up how to do that (address a drive for virtual memory and cache). There's also primocache, but that's only for slow pc's. The page file and virtual mem is always being used.

[kingozrecords]

here's the best price I could find for hybrid sshd (hdd with ssd ram). You could load one large lib per drive or three small ones.
that would be the same as an ssd, keeping in mind you need to take into account lanes. How many files are being accessed, what file allocation table type etc etc etc. When dealing with many files in the case of kontakt the difference is abstract and it comes down to raw performance. If you follow this as a rule, you will greatly benefit from sshd's.

I'll buy two or three to augment My kontakt library.
https://www.aliexpress.com/item/4000066467986.html

keeping in mind that raw speed does not equal connectivity. a hard drive has more working connections inside. there are many heads and readers accumulating data. there's only two on an ssd. benchmark tests are for one file, not two, not three, not 100 and not 500. there's often more than 100 files in a good library, making ssd's redundant in actuality. Accessible data is the lack of latency to actually access that data. Only if that data is cached can it be continually accessed. If that drive, whatever drive it may be is busy doing other things (like virtual mem for instance), it will be bottlenecked. That is why crystalmark and all these tests are obsolete. They are no substitute for know-how, just the toys of amateurs.

[Guenon]

there's often more than 100 files in a good library, making ssd's redundant in actuality. Accessible data is the lack of latency to actually access that data. Only if that data is cached can it be continually accessed. If that drive, whatever drive it may be is busy doing other things (like virtual mem for instance), it will be bottlenecked.

Please don't try to give the impression that SSDs would be somehow improper for Kontakt library use as-is. I mean, if that is what you are hinting at. The difference in heavy Kontakt library use is dramatic between HDDs and SSDs. A lot of what you say sounds like it combines bits of information from different sources in a meticulous way, yet it comes out in a form that doesn't reflect actual use cases or real-world performance.

So, about those "more than 100 files in a good library" - there are often tens of thousands of discrete samples in a library. They can be individual files, tens of thousands of them, or packaged into monolithic archives. In any case, even many free libraries (of a single instrument) have thousands of separate samples in them these days. One crucial aspect, for a composer working with tools like this, is the random read performance of the chosen mass storage containing the sample data. HDDs are at their best when accessing uninterrupted long sequential strips of data, but they have severe limitations when doing massive random access in a multi-gigabyte data pool. Heavy Kontakt use is the latter.

This has traditionally been mitigated to an extent by preloading a bit of the start of each sample into RAM, by the Kontakt disk streaming engine, so that there is enough time for those random seeks to catch up after the sample is already playing. Even then, running a larger project in realtime from a HDD will just collapse under the required seek times, when in comparison a - nowadays relatively bog standard - SSD will still keep up fine. All this talk about lanes and so on, it pales in comparison when running an actual large real-world project that needs those seek times.

As a result, I'd urge anyone to take this kind of advice, as usual, with a huge grain of salt. I'm usually trying to keep away from these threads, like a while ago when you described how audible aliasing happens when a CPU does more work because of vector-based plugin GUI designs, which "needs more math", and the added complexity and load leads to alterations in the actual audio data. Saying stuff like that is just so out there, and just saying it and putting it there... doesn't quite have real-world repercussions - but giving people (who are planning a new system and what parts to get) these ideas... sort of does.

Just mentioning one specific thing, still: the page file / virtual memory one:

what becomes the thing of extreme relevance is having a cache drive for your vram set to a drive you've purchased just for that task. Something nimble and robust. There's various tutorials to achieve this.

a 128 ssd for virtual memory 1/4 of your bottleneck would be gone.

"The page file and virtual mem is always being used", but how much? I invite anyone to check for themselves: https://docs.microsoft.com/en-us/archiv ... and-writes

The article has been updated in 2013, but the tools are still the same. See how much the page file is actually being accessed while you work. For me, I just tried this out yesterday, and tracked the usage during two hours of my usual real-world workday. The system has 32 gigabytes of RAM, and the tools that were in use were the Unity Editor, running a multi-platform targeted game that is in pre-release status (i.e. practically has a full game's worth of material in the project), Jetbrains Rider, Ableton Live, version control and communication tools, and ShareX taking a couple of video captures. During that time, and with all these tools in use, the pagefile was accessed, in total, for about 300 megabytes. The majority of even that amount was regular maintenance accessing instead of on-demand for work related processes needing virtual memory.

Keep in mind how performative the current SSDs are. In a working scenario like that, during that time, does that sound like "a thing of extreme relevance" and a huge bottleneck?

Okay, enough about this. Just a grain of salt, that's all.

[arkmabat]

The biggest noticable difference with SSD for me was OS boot times and WinDirStat scans.

[kingozrecords]

Please don't try to give the impression that SSDs would be somehow improper for Kontakt library use as-is. I mean, if that is what you are hinting at. The difference in heavy Kontakt library use is dramatic between HDDs and SSDs. A lot of what you say sounds like it combines bits of information from different sources in a meticulous way, yet it comes out in a form that doesn't reflect actual use cases or real-world performance.

I get that looking at every detail seems flabberghasting and overwhelming. It also seems like it's a "coping mechanism", doesn't it? It seems like I'm just compensating by throwing facts out there.

I guess what it comes down to Guenon, is price. My responses have to cater to everyone; and for people who have less money; If I'm to suggest anything, need to help provide them with insight so they can see that using sometimes older technology isn't so bad.

Like in the case of hard drives there is sas, and like in the case of ssd's there is u.2.
But that costs thousands and not hundreds. I'm catering advice to both studios and users alike.

Beyond raw power however, you're right in suggesting that there are libraries that have larger filesets; but they're very rare. In such cases I'd go u.2; but that would cost thousands of dollars, better oriented to commercial application. M.2 ssd (assuming that you have 4 lanes [m-key] and not 2 [b-key]). is why I mentioned lanes, because more often than not, m.2's are bifurcated in that fashion whether pcie version 3.0 or 4.0, there's an m-key (using 4 lanes) and a b-key (only using 2 lanes).

It's only those who are testing real-world who realize that, because we don't believe all of the silver cloud, snake oil sellers on youtube. It's ok for someone to see My advice as fickle and trite, but it's still the state of things. I'm instead glad that I've shared the existance of that limitation so people can shop smarter.

Even 8x / 16x dual m.2 pcie 4.0 cards for instance have the same hindrance and the buyer won't understand that one m.2 will get less power (lanes) without realizing what the term b-key actually means. Raid 0 furthermore is even worse in My opinion because of shared lanes and slower results.

I think for most kontakt libraries sshd drives are best, like the seagate firecuda 1-2 tb with 64 mb of cache and 8gb of TLC ssd memory. I explain why rather succinctly in this video:


Keeping in mind that ssd's, due to cluster size and file allocation type limitations, simply aren't going to be as fast as old hdd's for loading smaller file sizes (0.8mb - 2mb); the SSHD is the best bang for your buck; but it would be better if they had newer versions with 32gb onboard pcie 3.0 or pcie 4.0 ssd onboard instead.

As a result, I'd urge anyone to take this kind of advice, as usual, with a huge grain of salt. I'm usually trying to keep away from these threads, like a while ago when you described how audible aliasing happens when a CPU does more work because of vector-based plugin GUI designs, which "needs more math", and the added complexity and load leads to alterations in the actual audio data. Saying stuff like that is just so out there, and just saying it and putting it there... doesn't quite have real-world repercussions - but giving people (who are planning a new system and what parts to get) these ideas... sort of does.

Just mentioning one specific thing, still: the page file / virtual memory one:

what becomes the thing of extreme relevance is having a cache drive for your vram set to a drive you've purchased just for that task. Something nimble and robust. There's various tutorials to achieve this.

a 128 ssd for virtual memory 1/4 of your bottleneck would be gone.

"The page file and virtual mem is always being used", but how much? I invite anyone to check for themselves: https://docs.microsoft.com/en-us/archiv ... and-writes

The article has been updated in 2013, but the tools are still the same. See how much the page file is actually being accessed while you work. For me, I just tried this out yesterday, and tracked the usage during two hours of my usual real-world workday. The system has 32 gigabytes of RAM, and the tools that were in use were the Unity Editor, running a multi-platform targeted game that is in pre-release status (i.e. practically has a full game's worth of material in the project), Jetbrains Rider, Ableton Live, version control and communication tools, and ShareX taking a couple of video captures. During that time, and with all these tools in use, the pagefile was accessed, in total, for about 300 megabytes. The majority of even that amount was regular maintenance accessing instead of on-demand for work related processes needing virtual memory.

If you are using your hdd, whether ssd or conventional, or sshd; you're also tying up lanes for that data to be accessed and bottlenecking your hdd's connection. You'll be getting ssd 2.0 speeds instead of 3.0 or 4.0, bottom line. You can't have your cake and eat it to. Everything is stepwise.

[Guenon]

I get that looking at every detail seems flabberghasting and overwhelming. It also seems like it's a "coping mechanism", doesn't it? It seems like I'm just compensating by throwing facts out there.

I guess what it comes down to Guenon, is price. My responses have to cater to everyone; and for people who have less money; If I'm to suggest anything, need to help provide them with insight so they can see that using sometimes older technology isn't so bad.

If it was just that, it would be just excellent. And you clearly put a lot of effort in your dealings with tech. What I'm saying is, while you are doing that, you have a habit of also slipping into writing things that really don't represent how things actually are and how they work in practice . But thanks for listening and genuinely reflecting on my feedback, even if it was rather critical this time as well; I appreciate that.

Beyond raw power however, you're right in suggesting that there are libraries that have larger filesets; but they're very rare.

They are not rare at all, and definitely not very rare. Just a random check on a Kontakt library drive here, even libraries from years ago have thousands or tens of thousands of samples. I'm literally picking random ones here one by one. Epic Dhol by 8DIO, 2056 samples. A celesta by Sonokinetic, over 4000 samples. Adventure Strings, 7333 samples. Master Brass, 33708 samples. Even a relatively novelty library (no, really, it's a really nice flute/whistle in actuality ) like Embertone Shire Whistle has got almost a thousand samples. A tiny free Toy Piano from Spitfire LABS has got well over that mentioned one hundred samples, their free drumset over two thousand. And so on. The libraries that do, in turn, have the individual samples packaged inside monolithic archives (and have a seemingly low file count) will still need the random read performance all the same, of course, giving SSDs a huge edge over HDDs in any case.

In such cases I'd go u.2; but that would cost thousands of dollars, better oriented to commercial application. M.2 ssd (assuming that you have 4 lanes [m-key] and not 2 [b-key]). is why I mentioned lanes, because more often than not, m.2's are bifurcated in that fashion whether pcie version 3.0 or 4.0, there's an m-key (using 4 lanes) and a b-key (only using 2 lanes).

In these cases you would go U.2? Just a moment ago you said you were doing this price-conscious-like. It doesn't add up. What I mean is... this is the important thing here: nice (but these days perfectly regular) SSDs run these sort of libraries dramatically better than a HDD, and can be used for serious projects. What you are doing is called bikeshedding, and trying to optimize/solve something for the sake of "trying to solve" it instead of being involved in the actual work that uses thech like this day in and day out, in practice.

In other words, for example, on these systems here, the most voice-count-heavy libraries use M.2, and the rest are on - by today's standards, pretty basic - SATA ones. On the music and Kontakt front, i.e. when not doing sound design or technical implementation, a main use for these setups is game soundtracks and trailers and so on. This stuff has remarkably better performance than HDDs had, the random reads and voice counts are out of this world when compared to those, and you can definitely use them for serious work.

If you are using your hdd, whether ssd or conventional, or sshd; you're also tying up lanes for that data to be accessed and bottlenecking your hdd's connection. You'll be getting ssd 2.0 speeds instead of 3.0 or 4.0, bottom line. You can't have your cake and eat it to. Everything is stepwise.

The point is, maximum throughput performance and massive scale random seek performance into a multi-gigabyte pool of samples are just very different things. Also, consider something like having that approximately 8GB/s maximum throughput for a four-lane configuration, for example. Okay, 8 GB per second. Then consider that the observed swap file access was about 300 megabytes during two hours of real-world game audio work.

In a system with an adequate amount of memory for the work, swapfile use is this minimal, and it's not in any way a "thing of extreme relevance" as introduced. 300 megabytes of routine maintenance swap file access during two hours of work is not going to drop the effective maximum throughput to "ssd 2.0 speeds" ... hmm, in any manner.

[kingozrecords]

Yes, yes - but how many samples are actually being utilized at a given time. I can do the math, and there's no more relevant than a hundred or two; I've yet to see more than two swaps for velocity. You understand what you're talking about but you're using broad facts that aren't always important. Like for instance, I could say a hdd has 300 mb in it, but if I'm only using 20mb why mention the other 280? It's the same with anything.

In relation to file-writes, you also have to turn off write-caching on the drive (which writes to a fancy text file), and make sure that cache file write optimization is turned off also. It eats up ram to check exactly what files are currently being accessed and any relevant changes to the file structure such as deletions and compressed folders. Indexing, and optimization checking is often active too, as would be tpm and bitlocker if encryption is enabled.

Not to forget telemetry is also logging every file used, and file name. The less telemetry the better. The more effectively that the four lanes from a sata hard drive can be utilized, the more like an ssd it can be for smaller files. that's another matter.

Here's the pudding and the proof. I compare a seagate skyhawk versus a samsung pcie 3.0 1tb evo. The hdd was faster in write speed (the file was deriven from a 500gb corsair usb stick, and drive optimization was not turned on).



I'm nearly 50 years old; so working with old hdd's to Me is second nature. Speeds that people have been so amazed about with smaller files has been the norm for Me for over thirty years. I merely had to follow all the tuts and understand the technology that I was working with. SSD is more relevant for larger files (50mb+).
that's pretty straight forward though, given the size of most onboard hdd cache.

[Guenon]

Yes, yes - but how many samples are actually being utilized at a given time. I can do the math, and there's no more relevant than a hundred or two; I've yet to see more than two swaps for velocity. You understand what you're talking about but you're using broad facts that aren't always important. Like for instance, I could say a hdd has 300 mb in it, but if I'm only using 20mb why mention the other 280? It's the same with anything.

I'm just replying to what you said yourself . You said "there's often more than 100 files in a good library, making ssd's redundant in actuality." No, they don't make SSDs redundant, and the claimed amount of files gives a totally wrong idea, in any case, as well. When pointing out that the amount of files/samples is, in actuality, routinely hugely higher, you said "you're right in suggesting that there are libraries that have larger filesets; but they're very rare" (they aren't).

You said the swap file / virtual memory is a "thing of extreme relevance" that impacts performance noticeably. I measured swap file usage in actual working conditions, and it was about 300 megabytes of routine system maintenance events during two hours of working. Consider that an orchestral template has many Kontakt instances (my typical blank template has about 60 instances; they aren't all playing back simultaneously at any given one moment, of course, but you get the idea), and a significant number of them is accessing the library drives concurrently while playing back a project i.e. disk streaming samples of a full work. Add to that the absolutely minuscule load of a couple of hundred MB of swap file activity, during a long span of time, and it's just negligible when considering total performance and total disk activity. Even if not going "full orchestral", swap file activity like this is insignificant in comparison with other disk access happening routinely while working on a full Kontakt-based project.

Anyway, enough of the garden paths, again. Bottom line: SSDs in Kontakt library use are tremendously more capable than HDDs. Even regular M.2 and SATA ones. Obfuscating basic lack of understanding of a certain field with minutiae and trying to "prove" this isn't the case... doesn't really work when contrasting such activities with actually relevant criteria.

[kingozrecords]

Yes, yes - but how many samples are actually being utilized at a given time. I can do the math, and there's no more relevant than a hundred or two; I've yet to see more than two swaps for velocity. You understand what you're talking about but you're using broad facts that aren't always important. Like for instance, I could say a hdd has 300 mb in it, but if I'm only using 20mb why mention the other 280? It's the same with anything.

I'm just replying to what you said yourself . You said "there's often more than 100 files in a good library, making ssd's redundant in actuality." No, they don't make SSDs redundant, and the claimed amount of files gives a totally wrong idea, in any case, as well. When pointing out that the amount of files/samples is, in actuality, routinely hugely higher, you said "you're right in suggesting that there are libraries that have larger filesets; but they're very rare" (they aren't).

You said the swap file / virtual memory is a "thing of extreme relevance" that impacts performance noticeably. I measured swap file usage in actual working conditions, and it was about 300 megabytes of routine system maintenance events during two hours of working. Consider that an orchestral template has many Kontakt instances (my typical blank template has about 60 instances; they aren't all playing back simultaneously at any given one moment, of course, but you get the idea), and a significant number of them is accessing the library drives concurrently while playing back a project i.e. disk streaming samples of a full work. Add to that the absolutely minuscule load of a couple of hundred MB of swap file activity, during a long span of time, and it's just negligible when considering total performance.

Anyway, enough of the garden paths, again. Bottom line: SSDs in Kontakt library use are tremendously more capable than HDDs. Even regular M.2 and SATA ones. Obfuscating basic lack of understanding of a certain field with minutiae and trying to "prove" this isn't the case... doesn't really work when contrasting such activities with actually relevant criteria.

Sure, I understand. for the mid-level pro ssd's seem like a great idea, absolutely. Many of us are spending less is all bro-fessor . btw, I turned off virtual memory, left enable cache write on and disabled indexing. My load time with the seagate skyhawk is now 9-11 seconds for a 2020 game (cyberpunk 2077) that's about 6-7 seconds less than My last test scores with indexing turned on. I guess that's conclusive, but I never believed indexing was using so many resources, now I know. I am curious though, how enable write cache will affect an sshd. Better on or off is the question.



I'm not saying anyone preaching ssd speeds are wrong for larger libraries. Costly though. My aim is to make it "rational" and "appealing" to save money and still have a great experience.

btw, if i got the context of a phrase wrong in the video, missed my morning coffee. having that now

SeagateFireCudaGamingSSHD2TB_3_1024x1024@2x.jpg

edit: found a decent firecuda 64mb cache sshd sshd at 2tb (on ebay): https://www.ebay.ca/itm/224658514146?ha ... SwIEFg894p
seller has a good rating. This sshd can outperform a sata3 ssd, but not an m.2 ssd.

edit: if you don't trust ebay, there's this link (more expensive):
https://tecisoft.com/products/seagate-f ... t2000dx002

I figure this topic is settled and everyone's provided useful opinions, but keep in mind what kontakt calls caching is often just compiling a list of sample files, and then testing each file to see whether or not it is corrupt and loading the psuedo sfz file. That's not to say that all files, from all options are loaded; if they were, it's a poorly made library. There's ways to avoid it. In the case of the bravura brass library I have, it has very specific options to save memory. One thing guenon mentioned which is relevant is the kontakt memory server, it works well and it uses ram. I've read mixed reports about it working in kontakt 6, but longtime users say it still works.

[Guenon]

I'm not saying anyone preaching ssd speeds are wrong for larger libraries. Costly though. My aim is to make it "rational" and "appealing" to save money and still have a great experience.

1) Not preaching, just providing some balance about how things are
2) SSDs are so cost-effective these days, you get a very performant Kontakt system even when going with SSDs costing just a tiny fraction of what the libraries themselves will in all probability cost you.

Back when everything was on HDDs, you needed a higher number of them to match the kind of Kontakt performance that is just regular and commonplace these days. One might have even resorted to secondary system(s) use, that is, playing some sections on separate computers and piping it back into your DAW system, even with project sizes that are pretty trivial these days. Sure, storage performance has gone up across the board since those times, but still the "I'm writing this stuff to help save money" argument doesn't add up; try matching the Kontakt performance of a couple of very moderately priced SSD library drives (say, a nice but budget-friendly M.2 one for the heaviest high voice count ones, and a nice SATA one for the more relaxed ones, as described previously), in actual real-world projects, with a HDD setup that costs less to such extent that it is worth the compromise.

The "HDD vs SSD 2 to 4mb files Windows 10" video you posted above is not at all indicative of mass storage performance in Kontakt sample streaming use. You talk about "emulating Kontakt" with this little test, and conclude that there is "no difference" for the better when using SSDs for Kontakt libraries - and base this on pasting a bunch of files on a drive and observing the write speed. Then you go on describing how much experience you have on drives, through the decades, and how you know better. It is only a display of ignorance, proof of not having real-world experience on the subject (using and configuring Kontakt workstations, in actual working context), and this makes it merely an attempt to obfuscate the fact of not being familiar with these matters.

[Guenon]

I figure this topic is settled and everyone's provided useful opinions, but keep in mind what kontakt calls caching is often just compiling a list of sample files, and then testing each file to see whether or not it is corrupt and loading the psuedo sfz file. That's not to say that all files, from all options are loaded; if they were, it's a poorly made library. There's ways to avoid it. In the case of the bravura brass library I have, it has very specific options to save memory. One thing guenon mentioned which is relevant is the kontakt memory server, it works well and it uses ram. I've read mixed reports about it working in kontakt 6, but longtime users say it still works.

You added this after my previous reply, so a "short" comment on this as well. "One thing Guenon mentioned which is relevant is the Kontakt Memory Server" - I did not mention the Memory Server, as it is not needed when using a modern system, and Native Instruments does not recommend using it when there is no need for it. One almost gets the feeling you are just now hastily hitting some Native Instruments documentation to see how things might be, after the fact.

From the Native Instruments page you linked: "If you are using a 32-bit host sequencer and your computer is equipped with 4 GB or more RAM, turn the Use Memory Server option under Options>Memory on. If you are using a 64-bit host sequencer or running KONTAKT in 64-bit mode, turn the Use Memory Server option off, since this option has no effect in 64-bit applications, and is likely to lessen KONTAKT's performance."

The memory server is not the same thing as Kontakt preloading a given amount of data from the start of each sample. The preloaded data is there to alleviate the effects of the slight delay a mass storage device needs to catch up with the request of streaming the sample data. How well the device can perform random seeks to a large pool of sample data is the important determining factor here; using the same preload sizes on an SSD that you would see on an HDD will give you significantly higher voice counts, as SSDs are so much more capable in this area. In practice, SSDs perform so well you can usually dial the preloads down and have plenty enough voices - and save a nice chunk of RAM while you're at it.

You say, "keep in mind what kontakt calls caching is often just compiling a list of sample files, and then testing each file to see whether or not it is corrupt and loading the psuedo sfz file" - look, it would just... be better if you refrain from writing stuff like this. I repeat, it would be great if you didn't write in a knowing tone on subjects you do knot know enough about.

It's not a bad thing when one doesn't have knowledge on something, everyone learns something the first time at some point, and all it takes is the willingness to learn. That is all perfectly okay. We've all been there, and it calls for positive support and encouragement. It's another thing when one insist on flaunting the misunderstandings even after they are corrected, not once but several times, then offers it all as advice, poses like they know something, and literally repeatedly asserts they are an expert and authority on the matter - and then gets so much of it consistently wrong or half-understood or mixed up. In every... subsequent... reply. Even when you say things containing some correct information, you leave out something that is more relevant, and from there, justify some misguided conclusion that just boils down to giving bad advice.

It always goes like this when someone actually familiar with the area you write about corrects something. That's why it's usually just wise to keep away. However, the very headline of this topic is about whether SSDs are worth it for libraries or not, and you came up with everything seen above. In a nutshell, I know it's "only" a case of someone being wrong on the internet, haha. So pretty much just... anyone needing info on things like this, in order to make actual decisions on how to build a system and so on, a fair warning: just use your own best judgement on whether a source like this is trustworthy or not, and if in doubt, ask directly from the people who actually make the tools you are using and/or who make a living extensively using those tools, year in year out.

The irony of that latest post is, on the very page you linked yourself, Native Instruments advises: "Best performance can be achieved by using a solid state drive (SSD). SSDs achieve read/write speeds much superior than that of traditional drives. Loading and streaming times will be greatly improved when your samples are stored on an SSD."

kontakt memory server, it works well and it uses ram. I've read mixed reports about it working in kontakt 6, but longtime users say it still works.

Hello, a longtime user here. I've been using Kontakt for seventeen years. During this time, my stuff has been released by publishers like Electronic Arts and others you might have heard of. Glad to be of help.

[kingozrecords]

Yeah, many of us aren't pros bro. We don't need the added expense. Things aren't selling like they were audio wise to boot. hard times all over.

Could I call Myself a pro? No. I could probably put something pro together tho. I also wouldn't need to worry about live situations. In the way of games and with conventional hdd's, they work just as fast as sata hdd's, but the caching caches to processor a great deal.

Tis because I'm a mere mid level buffoon (with some skill) that I'll save money. I totally get that most pros would rationalize the expense. You raise good points, mine was for the enthusiast who's getting by. With sales drops like I've noticed lately I felt such a thing was relevant, if not prudent for those with less.

Hello, a longtime user here. I've been using Kontakt for seventeen years. During this time, my stuff has been released by publishers like Electronic Arts and others you might have heard of. Glad to be of help.

And we're lucky to have your advice. When I am a pro, I'll upgrade too.

[Guenon]

Yeah, many of us aren't pros bro. We don't need the added expense. Things aren't selling like they were audio wise to boot. hard times all over.

Could I call Myself a pro? No. I could probably put something pro together tho. I also wouldn't need to worry about live situations. In the way of games and with conventional hdd's, they work just as fast as sata hdd's, but the caching caches to processor a great deal.

Tis because I'm a mere mid level buffoon (with some skill) that I'll save money. I totally get that most pros would rationalize the expense. You raise good points, mine was for the enthusiast who's getting by. With sales drops like I've noticed lately I felt such a thing was relevant, if not prudent for those with less.

Hello, a longtime user here. I've been using Kontakt for seventeen years. During this time, my stuff has been released by publishers like Electronic Arts and others you might have heard of. Glad to be of help.

And we're lucky to have your advice. When I am a pro, I'll upgrade too.

The main idea was, this whole ”SSDs are just for pros” is only your own talking point, and you had so many factual errors in your writings that they amounted to bad advice. From the viewpoint of using an SSD as a library drive, no, they are not an ”added expense.” Returning to the thread by repeating this particular point doesn’t make it so. They really do work so much better in the context of using Kontakt libraries that getting equally cost-effective SSDs - yes, even those affordable SATA ones that are in the same price range as the tech you recommend while getting multiple technical aspects wrong on Kontakt and SSDs - will give you higher voice counts, enable you to run larger projects, and also cut library loading times.

Other technical tidbits aside, this is now the main inconsistency here: on one hand, you have said in your videos that an SSD doesn’t make a difference - and have even implied here that it’s a bad fit for Kontakt. On the other, when commented on, you shift the focus on the alleged cost and say that SSDs are a nice upgrade, and useful for pros, but ”expensive.” See the logical puzzle in that?

Yet, SSD tech is indeed useful to anyone enjoying doing Kontakt pieces, they are recommended even by NI as the clearly most performant library streaming mass storage, and the benefits (of choosing the right kind of hardware for the intended use) aren’t only seen with expensive drives.