Old 03-10-2014, 06:04 AM   #81
SEA
Human being with feelings
 
SEA's Avatar
 
Join Date: Jun 2007
Location: By The Sea
Posts: 2,138
Default

Quote:
Originally Posted by serr View Post
Keep the same organization for your system/os/apps/library/etc on the SSD. Keep the samples in the same folder structure.

But only keep the samples you want to use here!

Now keep a folder on your data drive for the EXTRA samples.
Make sidebar shortcuts to both in the Finder (Explorer and whatever sidebar shortcuts are called in Windows) and you can quickly drag and drop back and forth if you want to add or remove from your "working" sample folder.

Reaper will of course be directed to your "working" sample folder on the SSD by default and will know nothing of the extra sample folder on your data drive.

Further though, you can also change default paths in Reaper or redirect the sampler plugin (likely with some setup script) when it works that way.
So basically what samples I use the most I keep on the SSD drive since I have TONS of samples!
__________________
JamieSEA

http://www.facebook.com/jamieseamusic
SEA is offline   Reply With Quote
Old 03-10-2014, 09:48 AM   #82
JGrabowMST
Human being with feelings
 
JGrabowMST's Avatar
 
Join Date: Jul 2010
Posts: 333
Default

In Windows, you can re-map a folder location, meaning you could do it without a script. Scripting an action that you could do once yourself and never have to go back and change is just silly. Complicates the process.

Not something I would do myself, but that's because I don't work with samples the same way (sound design, not music creation).

Mac is a different story, but I'm not sure this thread really applies to most Mac users.
__________________
Pro Tools 9/10/11, Reaper x64, Adobe Audition, SoundTrack Pro, Mixxx
Dual Xeon 2620, 32gb, 240GB Intel SSD & Apple MacBook Pro, 16gb, 750gb HDD
M-Audio ProFire 2626 + Art TubeOpto 8 with Ei 12AX7 Smooth Plate tube swap
JGrabowMST is offline   Reply With Quote
Old 03-10-2014, 01:56 PM   #83
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,505
Default

Quote:
Originally Posted by JGrabowMST View Post
Mac is a different story, but I'm not sure this thread really applies to most Mac users.
No difference. But the point is to run the often used samples from the SSD. Making an alias to the folder on the data drive (what you called 'mapping') would not accomplish that. You'd be running them from the data drive in that scenario. The whole point is to keep often used samples in the limited high performance space and then the rest on the cheap storage.


Now for items where drive speed doesn't matter - yes, making an alias to the new location is the easiest and most convenient way to go.
serr is offline   Reply With Quote
Old 03-10-2014, 03:42 PM   #84
SEA
Human being with feelings
 
SEA's Avatar
 
Join Date: Jun 2007
Location: By The Sea
Posts: 2,138
Default

Quote:
Originally Posted by serr View Post
No difference. But the point is to run the often used samples from the SSD. Making an alias to the folder on the data drive (what you called 'mapping') would not accomplish that. You'd be running them from the data drive in that scenario. The whole point is to keep often used samples in the limited high performance space and then the rest on the cheap storage.


Now for items where drive speed doesn't matter - yes, making an alias to the new location is the easiest and most convenient way to go.
But aren't most samples loaded into ram?

Let's say you have 32 to 64 gigs of ram and let's say 5 to 20 gigs of samples loading from your HDD into that ram, (and your project is on your SSD of course), then there really shouldn't be any performance difference correct?

Of course when you first load the samples when launching your project would take a few seconds longer but once it's all in ram would there really be a performance difference?
__________________
JamieSEA

http://www.facebook.com/jamieseamusic
SEA is offline   Reply With Quote
Old 03-10-2014, 05:43 PM   #85
JGrabowMST
Human being with feelings
 
JGrabowMST's Avatar
 
Join Date: Jul 2010
Posts: 333
Default

Quote:
Originally Posted by serr View Post
No difference. But the point is to run the often used samples from the SSD. Making an alias to the folder on the data drive (what you called 'mapping') would not accomplish that. You'd be running them from the data drive in that scenario.
What I was referring to was if the entire Sample Library was on an SSD for example. Rather than copying files left and right, just map the samples to the SSD, and work on your projects. Always keep a backup just in case, but that would run very very fast.
__________________
Pro Tools 9/10/11, Reaper x64, Adobe Audition, SoundTrack Pro, Mixxx
Dual Xeon 2620, 32gb, 240GB Intel SSD & Apple MacBook Pro, 16gb, 750gb HDD
M-Audio ProFire 2626 + Art TubeOpto 8 with Ei 12AX7 Smooth Plate tube swap
JGrabowMST is offline   Reply With Quote
Old 03-10-2014, 06:08 PM   #86
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Just outside of Glacier National Park
Posts: 12,690
Default

Quote:
Originally Posted by SEA View Post
But aren't most samples loaded into ram?

Let's say you have 32 to 64 gigs of ram and let's say 5 to 20 gigs of samples loading from your HDD into that ram, (and your project is on your SSD of course), then there really shouldn't be any performance difference correct?

Of course when you first load the samples when launching your project would take a few seconds longer but once it's all in ram would there really be a performance difference?
I think your right SEA, I'm assuming that loading the samples would be quicker from a SSD but other than that I don't think the performance would be any different.

However, a good sampler now days will use DFD mode (Direct from Disk). These samplers will use buffers for each sample which do go into ram. Like I mentioned in an earlier post, I've got these bufferes set up at 30kb in K5 however, for the best performance I think they should be set to 60kb which I think is default. The way I think this works is that Kontakt puts these buffers in ram and then uses them to pinpoint where the samples are and get a start on them.

So my earlier question was, can these buffers be set lower with a SSD drive?
__________________
Kontakt Vid Tutorials->Create Outputs / Create Templates -|- SMDrums Free drums -|- Elk Video Productions -|- Tod's Music
Tod is offline   Reply With Quote
Old 03-10-2014, 07:40 PM   #87
serr
Human being with feelings
 
Join Date: Sep 2010
Posts: 8,505
Default

Quote:
Originally Posted by SEA View Post
But aren't most samples loaded into ram?

Let's say you have 32 to 64 gigs of ram and let's say 5 to 20 gigs of samples loading from your HDD into that ram, (and your project is on your SSD of course), then there really shouldn't be any performance difference correct?

Of course when you first load the samples when launching your project would take a few seconds longer but once it's all in ram would there really be a performance difference?
For samples that load into ram, that is correct. You'd only see them load quicker - which could be desirable in a live performance situation.

If a sampler plays from the drive, you'd see more improvement. They come in both flavors.
serr is offline   Reply With Quote
Old 03-10-2014, 07:56 PM   #88
lachrimae
Human being with feelings
 
lachrimae's Avatar
 
Join Date: May 2010
Location: Austin, TX
Posts: 790
Default

I've been meaning to share my recent SSD/Kontakt experiences with the board.

I have i7-920 (oc'd to 3.6GHz),24GB RAM, Intel X-25M OS drive & (as of recently) a Samsung 750GB Evo SSD for my samples (Reaper portable install lives there too).

The Evo utilizes Samsung Magician's Rapid mode which basically caches 1GB of the most commonly accessed data (from that drive only) in RAM.
I actually get my best Kontakt performance when I set DFD to 6KB. The performance degrades when I increase DFD which I presume is because there is some sort of RAM swapping issue between Kontakt DFD & Samsung Rapid.

I've tested performance using 6KB DFD + Rapid against Max. DFD with Rapid disabled and I was able to get the best performance (most voices w/out clicking sounds) using 6KB + Rapid. If memory serves I was getting around 450-600 simultaneous voices before the clicks started.

I wish DAWBench would update their test to Kontakt5 so I could run their VST benchmark.

Apparently Samsung is working on a future update to Magician which would allow Rapid to cache additional RAM. That'd be very useful for huge projects where 1GB cache with an SSD backend might not suffice.
lachrimae is offline   Reply With Quote
Old 03-10-2014, 08:56 PM   #89
XITE-1/4LIVE
Human being with feelings
 
XITE-1/4LIVE's Avatar
 
Join Date: Nov 2008
Location: Somewhere Between 120 and 150 BPM
Posts: 7,843
Default

6kb makes perfect sense when using SSD caching.
RAM caching is what we have been using for years, since Conexant/Gigastudios Endless Streaming Technology first came along.
Kontakt is the best streamer since then. PLAY and VSL make excellent instruments but their lack of options for streaming/editing and overall size using uncompressed audio make them difficult when you have a 16GB template loaded.
Samsung acquired that software company and only allowed it to be used with the EVOs in hopes they would sell enough, so they could then turn around and offer that software to their 840 Pro line.
What I love about Kontakt is the options.
For example, I prefer lots of RAM for certain instruments.
Chris Hein Horns is a great Section/Solo choice for horns.
Often Section swells are timed and ineffective in realtime as there's no way to really measure the length necessary. But loading more into RAM allows the user to control the length of the Section Swells via the Mod Wheel, which is awesome for Funk, Nelson Riddle/Sinatra type stuff.
I even hold the swell, then smack down a Section Shake at the swells climax for a second, then have the section Fall set up to follow the release of the Shake.
Such options are not available in PLAY or VSL, and also why I study Kontakt as much as possible per developer, as some developers have tricks not mentioned in their manuals, or forums at KVR.
Kontakt is also the very first sample app that allowed developers to satify Pianists by having Sostenuto Pedalling, which was only done on a real Piano, Stage Piano (Korg/Yamaha/Roalnd/Kurzweil) or PianoTeq.
Orange Tree is that developer, and the Rosewood Piano is awesome.

So it's good to know about Samsung having a boost with smaller buffers, as then they serve as nanosecond targets for the SSDs.
One thing is still certain in the world of sample playback still. More smaller SSDs works really well with several tracks in realtime or recording an entire template on the fly.

Until my new rig is finsihed and tested for summer, I am using 3 x 128GB OCZ Vertex 4s at 510MBps, the SATA III 6GBps maximum, and they work fine.

I really like shaing battlefield stories about different tricks with Kontakt and SSDs/RAM. They really have advanced their application, and while not being a fan of their softsynths, I played around again with Reaktor and it's envelopes respond like hardware almost.
4 years ago they were mushy like most Native synths, so NI is constantly getting ahead and for anyone not using Kontakt, you have my sympathy.
__________________
.
XITE-1/4LIVE is offline   Reply With Quote
Old 03-11-2014, 04:20 PM   #90
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Just outside of Glacier National Park
Posts: 12,690
Default

Thank you for your post lachrimae.

Quote:
The Evo utilizes Samsung Magician's Rapid mode which basically caches 1GB of the most commonly accessed data (from that drive only) in RAM.
I actually get my best Kontakt performance when I set DFD to 6KB. The performance degrades when I increase DFD which I presume is because there is some sort of RAM swapping issue between Kontakt DFD & Samsung Rapid.
So you're talking about Kontakts main Options/Memory/Instrument preload buffer size, right? If so, that means you can load 5 times as many samples as I can now at 30kb and if I set it to what I think the default is (60kb), that's 10 times as many samples, would that be right?

I hate to ask what caches 1GB of the most commonly accessed data (from that drive only) in RAM means, because it conjures up a lot of questions that only shows my ignorance. But what the heck, could you explain that a little bit, in real time and terms, what does that mean? How and when is this 1GB alotted? Heh heh, yeah I'm pretty ignorant about this stuff.
__________________
Kontakt Vid Tutorials->Create Outputs / Create Templates -|- SMDrums Free drums -|- Elk Video Productions -|- Tod's Music
Tod is offline   Reply With Quote
Old 03-11-2014, 08:25 PM   #91
lachrimae
Human being with feelings
 
lachrimae's Avatar
 
Join Date: May 2010
Location: Austin, TX
Posts: 790
Default

Interesting info XITE, thanks for sharing...

Quote:
Originally Posted by Tod View Post
So you're talking about Kontakts main Options/Memory/Instrument preload buffer size, right? If so, that means you can load 5 times as many samples as I can now at 30kb and if I set it to what I think the default is (60kb), that's 10 times as many samples, would that be right?

I hate to ask what caches 1GB of the most commonly accessed data (from that drive only) in RAM means, because it conjures up a lot of questions that only shows my ignorance. But what the heck, could you explain that a little bit, in real time and terms, what does that mean? How and when is this 1GB alotted? Heh heh, yeah I'm pretty ignorant about this stuff.
Warning, LONG POST. Run away now.

Hmmm, I'm not sure that my explanation was very good, not to mention that I'm a hardware (datacenter) guy so I don't really know the inner details of how a program caches & uses data, but I'll try to clarify with an example:

As a test I loaded up the following instruments:
Alicias Keys
Vienna Grand
Upright Piano
The Giant
NY Grand
Berlin Grand
Scarbee A-200
Scarbee Clav Both - Phase In
Scarbee Clav Both - Phase Out
Scarbee Clav Full
Scarbee Mark 1 Stretch Tuned
Scarbee Pianet

Using 6KB DFD (Kontakt's Preload Buffer size) Kontakt allocates 485MB to cache RAM (i.e. 485MB is pre-loaded into RAM for quick access).

Using 240KB DFD Kontakt allocates 4.95GB to cache RAM (I assume this means that every sample is pre-loaded into RAM for quick access).

In a typical scenario the 240KB option would be ideal assuming you have enough RAM, but thanks to the caching feature on the Samsung Evo (only available on that series as far as I know), I'm getting better performance using 6KB DFD combined with the 1GB of caching that's done via Samsung. Basically Kontakt is unaware that Samsung is loading any samples into RAM, so when it receives a (musician's) request for a sample that's not loaded into it's 485MB of cache, it makes a request for the sample via the OS which would normally grab it from the hard drive causing a delay. If Samsung happens to have cached the requested sample in it's 1GB of RAM, the request will be returned very quickly back to Kontakt and there will be no delay. Samsung is masking it's 1GB cache as part of the hard drive so that when an app (Kontakt) requests a sample it unknowingly gets it from RAM instead of the hard drive.

Assuming that any of the above was coherent, you can see the problem that would arise when large numbers of instruments are loaded at the same time, as in my example:
Kontakt is only loading 485MB of samples in cache, and Samsung is loading only 1GB at best*... so any of the 3,559MB worth of samples that aren't loaded in cache/RAM would have to be accessed from the SSD (not slow, but certainly not as quick as RAM).

*Without knowing Samsung's algorithm for caching, it has some way of analyzing which data is commonly accessed, and then picks the most common items to load into it's 1GB of cache. If it doesn't analyze which data is commonly accessed in real time, but instead does an analysis every x minutes or hours then there's a good chance that the library you just loaded into Kontakt will not be loaded into Samsung's cache (at least until it meets their criteria for 'commonly accessed').

If someone that really knows this stuff wants to chime in that'd be great, but otherwise I'll leave it at this:
If you typically load less than 1GB of samples at a time you'll see great performance benefits from the Evo's caching feature, but if you are loading large, multi-GB libraries you're probably better off disabling the Samsung caching feature and using a large Kontakt DFD instead.

Hope that makes sense .
lachrimae is offline   Reply With Quote
Old 03-12-2014, 09:29 AM   #92
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Just outside of Glacier National Park
Posts: 12,690
Default

Quote:
Originally Posted by lachrimae View Post
Warning, LONG POST. Run away now.
Thanks lachrimae for the very informative report.

It sounds a little like Samsung's caching could be somewhat hit or miss. I'm not sure how the caching would know how many samples are being used so that it could allocate what it needs to.

Have you been able to use 6kb successfully without any problems on all your projects?
__________________
Kontakt Vid Tutorials->Create Outputs / Create Templates -|- SMDrums Free drums -|- Elk Video Productions -|- Tod's Music
Tod is offline   Reply With Quote
Old 03-12-2014, 12:19 PM   #93
lachrimae
Human being with feelings
 
lachrimae's Avatar
 
Join Date: May 2010
Location: Austin, TX
Posts: 790
Default

Unfortunately I'm not a big midi guy so I haven't put my settings through their paces in a large real-world VSTi environment though I'm interested in doing so. If someone wants to share a big midi project that uses Komplete 9 Ultimate instruments I'll load it up and provide the results.
Thanks!
lachrimae is offline   Reply With Quote
Old 03-12-2014, 03:04 PM   #94
Tod
Human being with feelings
 
Tod's Avatar
 
Join Date: Jan 2010
Location: Just outside of Glacier National Park
Posts: 12,690
Default

Quote:
Originally Posted by lachrimae View Post
Unfortunately I'm not a big midi guy so I haven't put my settings through their paces in a large real-world VSTi environment though I'm interested in doing so. If someone wants to share a big midi project that uses Komplete 9 Ultimate instruments I'll load it up and provide the results.
Thanks!
Okay lachrimae, thank you. Unfortunately all my own big midi projects and major productions over the years using Kontakt have been with a combination of paid orchestra libraries and my own custom orchestra library so I wouldn't have anything I could send you to check out.

So if we put Samsung's caching aside, do SSDs have a definitive improvement for running Kontakt in DFD mode?

Also thank you XITE-1, you say this:

Quote:
6kb makes perfect sense when using SSD caching.
RAM caching is what we have been using for years, since Conexant/Gigastudios Endless Streaming Technology first came along.
Kontakt is the best streamer since then.
So are you using Kontakt with a 6kb preload buffer size and making it work consistently with SSDs without any problems?
__________________
Kontakt Vid Tutorials->Create Outputs / Create Templates -|- SMDrums Free drums -|- Elk Video Productions -|- Tod's Music
Tod is offline   Reply With Quote
Old 03-27-2014, 12:26 PM   #95
SEA
Human being with feelings
 
SEA's Avatar
 
Join Date: Jun 2007
Location: By The Sea
Posts: 2,138
Default 2x Intel Xeon E5-2620 or i7-4930K?

JGrabowMST has made a few good points regarding using the Asus Z9PA-D8 vs. Asus Sabertooth and the fact that you can put 2x Intel Xeon E5-2620 into a Asus Z9PA-DA vs. only 1 Intel i7-4930K in the Asus Sabertooth MB.

Of course if I went with the Asus Z9PA-DA, I'd start out with 1 Xeon E5-2620 and then bump up to another later (if needed) but that fact that one can do this makes the Asus Z9PA-DA very attractive!

Thoughts?
__________________
JamieSEA

http://www.facebook.com/jamieseamusic
SEA is offline   Reply With Quote
Reply

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT -7. The time now is 04:10 AM.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.