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

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.

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.

Have to say I'm strongly in favor of reversing the Alt functionality as well. As in Nuendo, Pro Tools also defaults to group behaviour and the ability to adjust single tracks by use of a modifier key, and to me it seems counterintuitive having to press a modifier key to get the behaviour i already told my tracks I wanted from them. It was actually one of the first things that struck me as odd when testing MIR Pro.

I can confirm this. Going from 256 to 512 in Ensemble made it hang. Protools seemed like it was crashing as well, but after nuking the process in task manager PT was workign again.

It surely is a huge farkup from VSL's side that such potentially high fees can go without any type of warning from their side. My point was, though, that it's bad strategy to burden your customers with high fees and the nuisance of replacing their dongles every two years (I mean, wttf?) because 1. will make your product look weaker in the face of mounting competition, and 2. make crackable alternatives all the more tempting, thus worsening the situation even further for us legit customers.

If we start to find the dongle switch every two years acceptable, then in my view we have become too complacent.

I have to say this whole is issue is VERY worrisome to me as well. I have bought lots of VSL products through the years and would have my wallet fried if the dongle broke down and I had to pay these remarkably high fees per license. Just piling all the additional cost and hassle of protection schemes on top of us paying and legit users leaves one with a bitter taste in the mouth.

Reminds me of Waves' insanely unpopular WUP scheme of yesteryear, which they changed once custormers figured out what a moneyscheme it was and enraged customers hit every music forum around with cries of boycoting. Speaking of Waves, they will be changing their protection methods to cloud and/or personal USB stick and will be getting rid of the iLok, so someone has already started smelling the coffee. Punishing paying customers with expensive and user-unfriendly copyprotection schemes will bring diminishing returns in the face of quickly growing competition on the market. The alternatives are growing fast these days.

Ensemble + MIR Pro with a touchscreen monitor is all you need and will make this look like a Fisher Price toy.

Don't worry, it will work fine.

Indeed you should. As noted, it's considered theft and by already having agreed to giving you back some of the money I would say they made a dumb mistake if they wanted to con money out your pocket. It's evidence that deal and a subsequent transaction of money has been done and that they acknowledge something wasn't entirely right, so question remains what explanation they have for keeping the remaing amount.

Oh, and u can PM me the vendor. Thanks.

I would get a lawyer on it to establish if you have enough evidence to go to court.

Instead of investing in RAM I would invest in a SSD. You can easilly load 10 times as many samples into RAM when your libraries reside on a SSD. Of course it can become a little expensive if your VSL collection is large, but on the other hand you only need to go for the SSD with the lowest gigabyte per $ for your sample disk(s), since the performance of the drive isn't so important. It's the ultrafast seek rate (0.1ms) of SSDs that enable us to minimize what we load into RAM.

Well, as I wrote above, that is actually not obvious. It's simplifed logic that doesn't relate to real world results.

I have better things to do with my life than policing manufacturers of converters and informing them of the absurdity of their "higher samplerates=better sound" marketing claims, but I will spend a little time trying to disspell fiction from facts here on VSL's great forum.

Really, Beat, I'm not trying to bust your balls or anything. It's fantastic that you spend so much time on making tutorials available to others, but I think you will agree with me that making open, technical reccomendations brings with it added responsibility in being factually correct. I'm only trying to help you in this endavour.

Imo there needs to be a distinction between the recording scenario and the sample playback scenario:

THE RECORDING SCENARIO

You will be recording real world instruments or voices. The recordings will go through the AD process and end up at the samplerate the session is created at. Here it makes sense to record in either 48, 88.2 or 96KHz for best precision in the audible range of the converted signal, but any higher (like 176.4 or 192 kHz) is likely to have a negative effect on the precision and fidelity of the low frequency range, or at best there will be no audible difference. No matter what medium the final master is going to there can be advantages to record at a samplerate that optimally suits the mix (classical, hiphop, rock etc) and the way the converter works, even though it may not perfectly divide in 2.

In the end it all comes down to converters working differently, with some yielding better results 48k and others at another frequency, but in the words of legendary converter designer Dan Lawry there is absolutely no sense in moving above 96KHz. He theorizes about the optimum samplerate being around 56Khz, with enough precision in the mid and upper range of the frequency spectrum to provide for extreme clarity and quality, while not compromising the low frequency response.

THE SAMPLE PLAYBACK SCENARIO

You will only be playing back samples, either by having virtual instruments in your session or streaming them from a slave (network stream, digital audio transfer or DA-to-AD analog transfer). In the case of VSL samples, that are all delivered in 44.1KHz, there is nothing to be gained fidelity-wise by running the session in a samplerate higher than the frequency of the original samples. It will only introduce a higher CPU load due to the realtime conversion that has to take place, but one upside that has to be mentioned is that it will lead to less session latency (the hardware buffer is reduced the higher the samplerate is). Quality of audio is not improved, though. Even post-processing like time compression and expansion will not sound better if you bump up the session samplerate higher than the rate of the source samples. It's a matter logic, really.

Last, don't buy into the "higher is better" marketing hype that most converter companies try to sell us. They project the logic that a higher samplerate will get more of your real world sound into the computer (which in theory is true), but ignores that the conversion process will completely negate this and likely provide an inferior result to a lower rate, on top of heavilly burdening your system with high storage requirements, heavy CPU loads and lower voice counts.

That's the downside with the Mac OS, that you have no control over stuff like this unless you go into nerd mode and change it from the terminal. Very few people will venture into doing this, though.

Concerning the performance, do you use SSD or HDD? How many tracks and articulations played back are we talking?

This is actually not correct. Going to samplerates above 96khz will impact audio fidely in a negative way. Without getting into the complexities of converter designs I'll just say that it makes the most sense sticking to 48khz, 88.2 or 96khz if you want the conversion process to work with the highest precision. This is most important in the AD process though, while for samplebased projects it only makes sense to have the session's samplerate similar to the rate of the samples. With this in mind it makes little sense having a VSL session at 96khz, since no VSL samples in the libraries are delivered at 96khz.

Imo the author shows a lack of insight into how computers work under given tasks, and his projection seem to me to be a very unlikely scenario for quite some time. There are entire business sectors built up around the Mac Pro workhorse (advertising, film, TV, DTP) where a Mac Mini just won't cut it. RAM amount, BUS speed, expandibility and GPU power is not great enough for these tasks to be performed at a level that can compete with a tower Mac.

Yes, the tech will move on and the next Mini will be better than the current ones, but if you follow the tech dev players and what they have in their 1-2 year pipelines, then there is nothing to suggest this is imminent. He asks why there is no new Mac Pros yet? Well, Intel are getting ready to release their next enthusiast-level line of CPUs (X79 series) in the autumn, which mark the only real architecture that will be a more than a minor incremental step up from the current Xeons, so perhaps Apple is waiting for the chips to be available and in quantity? Or perhaps the persistent rumours about Apple wanting to ditch Intel and move to the microprocessors from ARM are not just rumours? At least the latter could easilly be a significant and very time costly exercise, compatibility and motherboard design taking into consideration. I hope for the former, rather than the latter!

The Mini is defintely a neat option for computer music though, and very much so as a VE Pro server for that matter, but if you want to use something like MIR or MIR Pro you wont be able to do it on the current models. There will have to be a significant breakthrough in compact RAM size and BUS speed for this to work, and I suspect our good friends at VSL will have come up with something even more spectacular and demanding by the time compact technologies have evolved enough.

No worries though, you can just route virtual outputs from MIR Pro/VE Pro 5 into Cubase tracks and apply the effects there.

Yes and no. There will be a few clicks involved raising the VE Pro 5 user interface, so it wont happen automatically (like if you opened a plugin og VSTi ). You wil get a window where you click a button to show the UI of VE Pro 5, which in fact is a standalone program connected to the plugin inside Cubase.

As for MIR Pro, there is no MIR Pro without VE Pro 5 since MIR Pro runs as an application inside VE Pro 5. If you buy MIR Pro you will get VE Pro 5 automatically, since it runs within it's framework.

It means exactly that. My testing with Kontakt4 I can even get more than ten times the samples packed into memory. Only problem now is capacity and cost.

For my testing of SSDs in a big template setup I found that it was not so much about the amount of RAM anymore, but rather how many SSDs you could lay your hands on. Using Kontakt 4 I could easilly set the preload size to 6KB instead of the default 60KB, so easy math tells me that I'm able to load 10 times more into the RAM I have available. Compared to using HDDs to load a 20GB template you could now make do with only 2GB of available RAM to load it if using SSDs. That's good stuff, especially if MIR is part of the setup, and another huge advantage is of course that the loading speed of this much smaller buffer is lightning fast with a SSD.

You only need SATA3 if using one of the newer SSDs like the Vertex 3 series or the newer Intels (510 etc), since they are the only ones able to completely saturate the SATA2 bus and thus be hampered from using their full potential. But again, there is no idea in using these new super fast SSDs for sample streaming since you won't need all that performance to run your compositions anyway. It makes much more sense going for the SSDs with the best price-per-GB, as they will do the job just as well.

We just need those SSDs to fall in price so we can get rid of all HDDs. Can't wait 'till that's possible.

While your first assumption are not neccesarilly correct, it's true that putting your libraries on SSDs and thus only reading/streaming from them will involve very little work and performance degradation over time. Basically it makes little sense opting for the latest, greatest SSD due to the fact anything but the most crappy 1st gen drive will be able to handle whatever you throw at it, so what matters is finding the ones with the best price per GB ratio so you dont ruin yourself in the process.

Once you go MIR, you'll never go back. Trust me, it's that good.

You're all good and set to go.

That eases my mind. 2048 buffer is usualy enough in my sessions in protools, 4096 when the going gets tough. Worst case one can alway bump protools up to 8192 samples, but of course it would be nice to avoid this for the sake of playability.

One more question, since you are so wonderfully forthcoming about the development:

Previously you have exclusively recommended memory controllers in the X58 league, but have you done any tests or have any opinions regarding any of the dual memory interface options like the i7-based H67, P67 or Z68s? Will they struggle coping with the engine, and if so, do you think overclocking would make them able to handle the high throughput? Obviously the X79/LGA2011 platform will be a fantastic rig for running things like MIR if the rumored specs have any truth to them, but the Sandy Bridge-based platforms does offer quite a bit more value for money than enthusiast ones like the X58 and, very likely, X79s do.

Any thoughts much appreciated.

I second this, otherwise ppl would be led to believe that the MIR instantiation would create a latency that Pro Tools was able to deal with.

What latency do you commonly deal with when using MIR Pro so far, and at what buffer size, of course?