News from one of those 'other' sample library companies:
This was just posted on their forum:
Some really good news regarding memory access with PLAY
Some really good news for all PLAY product users, our software programmers have figured out how to open up the Mac 32-bit memory limit to use all of the installed ram you have IN YOUR HOST!
PC users already have a 64-bit version that enables them to do the same thing, however this will be enhanced shortly with PC 64-bit VST support.
For Mac users this FREE update will be available as soon as it passes QA and will enable users to load many more instruments, even without a 64-bit host. That means instead of waiting for Logic, Digital Performer, Cubase etc. to go 64-bit the major advantage of 64-bit computing will be available to you in a matter of weeks, and it's compatible with older versions of Mac OS X also.
This was available in Logic 8 for EXS users, but it was not available to third party plug-ins ... until now. Others have opted for standalone hosts to solve this issue, but we think our solution is more elegant as you get all of the advantages of PLAY residing inside your host, plus accessing as much memory as you have installed. Now you will be able to use all those wonderful PLAY convolutions without them choking your system, and load many more instruments with more ram installed, and once all current conversions to PLAY are complete, have a huge selection of instruments and sounds that you can load from one browser, eliminating screen clutter.
We are are rapidly reaching a point where memory limitations are a thing of the past.
Ha!
-
1) The entire film post/production community around the globe is dominated by studios and production houses running MAC based DAWs.
2) The BEST sound-libraries available fror Orchestra are Vienna bar none...
3) The entire film post/production community starts buying PCs in order to run VSL smoothly
you guys are forcing our community into using PCs........it's not fair
SvK
-
SVK:
The folks at VSL say they are committed to release of an OSX compatible 64 bit version of VE. I have no reason to doubt them. They also have every motivation to come through on this as they know the facts you cite. I am sure they can figure out that all the professionals who use Logic or DP are simply not going to start learning equivalent Windows applications. Meanwhile, by making use of multiple instances of the standalone (possibly in combination with the plugin) one can achieve the same result - - one can exceed the 2.5GB limit imposed by 32 bit systems.
In my experience, on my dual 2.5 GHz G5, I run out of processing power long before I run out of the ability to load samples. (This is why I am looking forward to next generation of Mac Pro desktops equipped with Penryn processors and 8 processor cores.)
-
The description of how Play functions (offering 64-bit memory access while functioning as a normal AU within the sequencer) matches what I originally -- mistakenly -- assumed VE was designed to do. Needless to say I was simultaneously delighted by what VE could do, and disappointed to discover that the main issue remained tantalizingly out of grasp.
It's enlightening to see that EWQL have found a way to make it happen -- a sizeable competitive plus, with the exception that EWQL's libraries are much less huge and detailed and hence are less likely to hit your RAM limit regardless. The idea of VSL finding a way to allow VE surmount the obstacles the EWQL people have somehow conquered makes me salivate, which is bad for my keyboard.
--Chuck
-
VSL, as I understood, also uses memory space outside of the host, however, it must be implemented differently because I do hit a memory wall after a certain number of instances is reached (hosted by Digital Performer). I'm getting much better results using Vienna Ensemble Standalone alongside DP, so this suggests that VSL may not be using all of the memory space outside of the host app. It can't be, if I get better results and can load much more into VE Standalone.
-
Conversely, I run out of the ability to load samples much quicker than processing power on my 8-core.
-
I'm sure that VSL as any good company has a product strategy in place. What I do question is the marketing priorities within the strategy based on what the user base is asking for. It is very clear to me after reading several discussions on this issue that I am not alone in wanting an instrument that addresses ALL available memory on a single box. I would hope that the priority in the VSL company is to make the Vienna Instrument capable of addressing ALL available memory. I say Vienna Instrument because it is the reason why I purchased approx $17,000 US worth of VI modules. I love the playability of the instrument but it's short-coming in my opinion is the implementation of RAM management. I have never been happy about the fact that I have to play my score (or freeze the track) in order to then release the unused samples. This is a very time consuming process that hinders work-flow and in very large scores, I find myself doing that a lot. That being said, the advent of bigger machines such as the Mac Pro 8-core with more RAM and processing power moves us in the direction of minimizing this impact by being able to access ALL available RAM on a given machine thereby overcoming this RAM Management issue. Vienna Ensemble as I understand it was designed for those users who are using slave machines. For us single box users with large CPU processing capabilities, hard drives and memory, Vienna Ensemble does not solve the root issue. We should not have to add additional hardware or implement shareware (unstable at that) in order to route audio back to our sequencer. It is obvious to me that what the user base wants is an application that will incorporate seem less into any sequencer of their choice without the complex routing of audio, additional hardware, resulting in additional use of screen real estate. I understand the VSL is a small company but I would hope that the development team places a high priority on making the Vienna Instrument capable of using ALL available RAM regardless of machine, operating system or sequencer. Unlike using the Pro or Horizon samples where one could just use a different sampler that fits the bill, we are locked into using the VI engine -- an engine at this point that is missing the mark.
-
Gary:
I don't know how much RAM you have, but if you have a lot, you can run multiple standalones on the same computer by just duping the VE application and renaming it. Each of these instances can hold about 2.5GB of samples.
Chuck:
It's no big deal to route audio from the standalone(s) back into a DAW. You don't need shareware. If you have an RME interface you can do it in the software that comes with the interface. If you have an interface likethe MOTU 2408, you can do it by connecting a short, inexpensive ($8-10) ADAT cable from the outputs of one bank to the inputs of another. If you run the standalone or multiple standalones, you can use them in addition to the VI or VE plugin as each will inhabit its own memory partition. Thus with a single MOTU 2408 you could have 4 standalones each with discrete stereo outputs, each with 2.5GB of samples + an additional 2.5GB of samples instantiated as plugins within your DAW - - if you have the RAM and the processing power.
-
Yep, I know I can use standalone VE for this, but I was referring to VSL as a plug-in, where it has been stated that the plug-in version does use RAM outside of the host app, but apparently not to the extent of the standalone version (or VE). Maybe the new East-West Play memory addressing deals with this by gaining access to as much RAM as their standalone versions.@stevesong said:
Gary:
I don't know how much RAM you have, but if you have a lot, you can run multiple standalones on the same computer by just duping the VE application and renaming it. Each of these instances can hold about 2.5GB of samples.
Chuck:
It's no big deal to route audio from the standalone(s) back into a DAW. You don't need shareware. If you have an RME interface you can do it in the software that comes with the interface. If you have an interface likethe MOTU 2408, you can do it by connecting a short, inexpensive ($8-10) ADAT cable from the outputs of one bank to the inputs of another. If you run the standalone or multiple standalones, you can use them in addition to the VI or VE plugin as each will inhabit its own memory partition. Thus with a single MOTU 2408 you could have 4 standalones each with discrete stereo outputs, each with 2.5GB of samples + an additional 2.5GB of samples instantiated as plugins within your DAW - - if you have the RAM and the processing power.
-
Hm, I do wonder how much RAM I'd realistically be able to make use of within the computational limit of a 2x2 mac G5 (3.5gb RAM), assuming a fairly busy piece but maybe only a single convolution reverb ...
My next machine will likely be an 8x3.2 penryn mac pro with a healthy big dollup of RAM.
--Chuck
-
Chuck:
So far, I'm having more luck running under OS 10.4.11 than 10.5.1 in terms of processor overload. (I have two startup disks - - the one with 10.5.1 is a clone of the main disk which I updated to 10.5.1 for testing purposes.)
My experiences with processor overload could be related to the fact that I have been using Finale 2008 to drive the standalone. Finale 2008 seems, itself, to be a bit of a processor hog - - and can only make use of one processor - - even if you have 8 processor cores. Its compatibility (or lack thereof) with OS 10.5.1 might also be a factor - - as, a few seconds every time after I quit under 10.5.1, I get a message that Finale 2008 has "unexpectedly quit" - - and find its temp files in the trash. (This does not happen under OS 10.4.11.) Logic might be a more efficient driver here as it can make use of multiple processors, but my habit, when composing, is to write notation in Finale. When the score is done I transfer it via a MIDI file to Logic if a recording of a MIDI performance is necessary.
In any case, I have about 2.5 GB of samples + Altiverb loaded into the standalone at the moment. This leaves about 1.5 GB of free memory on a dual 2.5GHz G5 equipped with 7GB of RAM - - no doubt because of numerous openings and closings of VE during the attempt to launch Finale which also, unfortunately, initiates a launch of VE to no purpose). Playing a dense passage of orchestral music, Activity Monitor shows that Finale is using about 70% of CPU while VE varies between 80-103%. I don't hear any digital artifacts - no clicks and pops. I will continue testing. Like you I plan to purchase an 8 processor core Penryn machine when it becomes available.
Update:
Playing the same file - - with the same VE setup - - under OS 10.5.1 results in artifacts (clicks and pops) presumably produced by processor overload. This did not happen under OS 10.4.11. After a fresh restart, free memory was 3.4 GB in OS 10.5.1 - - in other words plenty of memory, but not enough processor. CPU readings were 80-90% for Finale and 90-108% for VE under OS 10.5.1. I will try later after I've turned off the (very convenient) "Spaces" feature - - and anything else I can think of that might cause excessive overhead in terms of processor usage.
-
Having dipped in and out of this rather long thread a have one or two observations, hopefully not too contentious. Firstly we have reports (some close to the VSL mothership!) indicating that developing for Windows then adapting development for Mac takes up to 3 times longer for the Mac side. Then we have opposite views that developing for Mac is actually much quicker than Windows as the whole system is rather more "this century" Given this Ying/Yang state of affairs a neutral observer might offer up the suggestion don't have your team develop for Windows and Mac but have two teams - the Windows guys and the Mac guys - if what this thread indicates is true it would be quicker, more efficient and perhaps please the respective users more. There might even be scope for some graphics tweaks (is it me or are the VSL GUI's more Windows in appearance than Mac?) Of course if developing for two platforms by the same team is actually more efficient then I guess a lot of the comments in this thread are off the mark! As this thread is sort of software development based I thought I'd offer a further view - maybe more contentious this time - One of the massive benefits of the DAW's and their increasing incorporation of plug-ins was the all in a single box solution. This has evolved over the years from a few toys to a genuine replacement of a lot, if not all, the huge number of rack mounted studio processors. From a professional viewpoint this can have huge benefits. However there now seams to be a shift away from truly integrated plug-ins to hybrid affairs that often "fight for attention" with the smooth operation of the host DAW. I do hope that however brilliant Vienna Ensemble is (I'm waiting a while before incorporating it into my front line kit) that VSL developers do not move away from tighter integration of the VI plug-ins into the main DAW's so that the operation feels part of the same production environment rather than 2 apps. Perhaps a large number of users of this forum use the VSL devices as a sole production resource then set up their computer system and modus operandi accordingly, whereas I suspect an overwhelming majority of users/facilities use VSL programmes as part of a diverse multi-source set up where ease of use and accessibility is paramount along with common basic operation methods between plug-ins. To use a rather blunt simile, VSL certainly produce the best engine but it's better if it fits in the engine bay rather than the trailer! Julian PS I did format paragraphs but for some reason it is previewing (and posting?) as a single block.
-
I think the main problem is that their core code - that makes the engine possible and as efficient and clever as it is, is written in a language that the programmer (s) understand well and can tweak and bend to their advantage. The reason for the frustration is that cocoa the api for mac osx is not a language per se - it is a framework which means they give you the building blocks and you piece it together, basically, whereas c++ although, in many ways probably very limited, overly complex and time consuming for MOST application development, for something like vienna instruments where the programmers already know C++ and want to make the software interact with the hardware in as "custom" a way as possible, it is probably frustrating on the surface. The point is that they at this time I assume most likely only know how to make such customisations work using C++, because that is what they know well enough to create such cutting edge software. I mean, if you are french and you speak a few words of english, maybe you can write a direction to the train station, but you can't write lord of the rings. In this case I think VSL speaks french and cocoa speaks english, so to speak. So they are fluent in writing "lord of the rings" in french, but then translating it into english is a painful task for them, frustrating, and much is potentially lost in translation that has to be in effect, rewritten so that it's meaning (efficiency) is retained. That is why carbon api was used on the mac until now because it allows them to port much of their c++ code straight into the mac and use windows as their primary development platform for all that tricky clever code they make. The problem that has now arisen is that, unexpectedly, apple has chosen to abandon upgrading the carbon api to 64bit capability. It should be noted that carbon was always intended as a legacy api not the preferred api on the mac. carbon allows C++ to be ported easily as it was designed for windows developers porting to the mac and legacy mac apps to be able to upgrade to the mac osx interface and other benefits without starting from scratch. Cocoa is designed for apps written from scratch for os X and I suppose it is also useful for many aps written for unix / linux and wanted to be ported to OS X as well. In the end it is a modern api or framework, and C++ is yesterdays platform that doesn't mean that it is bad. the point of my reply to you is that that core clever coding that VSL has generated that makes their software magic possible is not simply something you can rewrite over night. You could argue that the interface and other simpler facets are easily recreated using an api from scratch, relatively speaking, but re-writing that hardware interaction in another language. I would think cocoa allows directly adding code though? Anyway, since there are basically one or two very clever brains behind that core coding. However I think the core issue here is simply that they have not had the time or inclination to deal with cocoa as a new language. If they did with the same intention as they have delved into C++'s capabilities in order to pull out from the mists of possibility the VSL engine, I think, in fact I am confident they would find a superior platform, and then they would have a new problem of saying "how can we get this kind of performance and ease of design and upgradability over to the windows side! I am confident if one knows C++ and cocoa and it's language to equal degree's one would undoubtedly find that cocoa is the more modern, logical (for the most part) easier to use, reliable and efficient (ie CHEAP) platform for development. The problem is simply in getting both platforms developed on. Miklos.
-
Steve, I've noticed a change right away between Tiger and Leppard from a CPU usage perspective. I was working on a sequence with Tiger (56 tracks 8 Altiverbs all Vienna) that was playing at approx. 70% CPU. When I switched to Leppard, the same sequence choked on the first beat. I changed latency setting and was able to get it up and running again. I believe that there is more going on in the background using CPU resources in Leppard than in Tiger. That's only a hunch. Chuck
-
-
Chuck:
What was your previous latency setting and what is your new latency setting? What audio interface are you using?
As far as virtual instruments being completely integrated as plugins within a DAW, it has pluses and minuses. I could be mistaken, but as far as I can tell, in Logic (in contrast to DP which has a virtual rack that can be used in any number of songs), I have not found a way to get third party virtual instruments to stay loaded with their samples when I close one file and open another. In this situation having a preloaded standalone template saves a lot of time. Similarly when using a program like Finale which cannot instantiate plugins other than those made or "powered" by Native Instruments, the VE standalone presents a viable alternative to the setup I was using previously in which the plugins were instantiated in a special Logic setup designed for the purpose - - so that Finale could play Logic's audio instruments.
-
Steve, At that time I was using Presonus FireStudio at 256. The FireStudio drivers did not work with Leppard. I went to CoreAudio at 512. Then purchased Apogee's Ensemble and went back to 256. The more I think of it, it may not have been the operating system as much as the difference in audio drivers...... I'm currently setting up 8 standalone instances of VE. I do not have them fully loaded yet but it appears that external is more efficient on the CPU than internal. Just need to get beyond the routing of Audio back to the sequencer. The Ensemble Audio interface is new to me and tech support didn't know of a way to route the audio back. Maybe hardwiring as you suggested is the solution. I'm pretty weak when it comes to audio routing--still learning. Chuck
-
How many instruments are loaded in each standalone? How many patches are loaded in each matrix? Are you using any legato instruments?
I'm afraid I can't comment on the Apogee Ensemble as I've never used it. The online advertising blurb seems to suggest that you can connect inputs and outputs via software - - but I have no idea if that is really implemented.
-
Steve, Still setting up ensemble. The jury is out but I should know sometime tonight. Techs said that Ensemble can't through software at this point. Symphony can and he was not sure if engineering will be making ensemble capable..... Chuck
