Vienna Symphonic Library Forum
Forum Statistics

199,044 users have contributed to 43,151 threads and 258,882 posts.

In the past 24 hours, we have 3 new thread(s), 10 new post(s) and 61 new user(s).

  1. Home
  2. Sample Libraries
  3. Vienna Instruments Libraries
  4. VE Mac 64 bit?
  • C
    C

    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
  • S
    S

    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. 

  • J
    J
    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.
  • M
    M
    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.
  • C
    C
    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
  • C
    C
    Julian, I couldn't have said it better........ Ditto.... Chuck
  • S
    S

    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.  
  • C
    C
    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
  • S
    S

     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.

  • C
    C
    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