I'm interested in giving this a try. Assuming one can get Soundflower working properly (haven't used it yet), how is one routing MIDI from, say, DP to a standalone instance of VE?
--Chuck
-
Activate the IAC driver in Audio MIDI Setup. Do this by double clicking on the IAC driver. A dialog box will appear. Make sure that "Device is online" is checked. Creat the requisite number of ports (each port is capable of 16 channels). Once you've done this, DP will see the IAC ports as another MIDI interface and you can choose them as MIDI outputs. Then you assign the IAC port and channel in VE so that it receives the MIDI data from VE.
I don't recommend SoundFlower as, every time I've tried it, I've gotten random artifacts (clicks and pops) during playback. If you have an interface such as those made by RME that has the requisite software, you can connect any input to any output and use it (the RME or equivalent audio interface) as the output device. If you have a interface such as the MOTU 2408 which does not currently have such software but does have 3 ADAT inputs and outputs, you can run a short fiber optic cable from Bank C's ADAT output to Bank B's ADAT input. Then assign each instance of VE's to output on a Bank C stereo pair (e.g. assign the first output to channels 17-18. etc.).Then create an AUX channel in DP, assign its Input to channels 9-10 and its outputs to channels 1-2. Thus the audio signal will be sent back into DP allowing you to use whatever signal processing is available within DP. I am currently using this setup without any problems. If your MOTU 2408's ADAT Inputs and Outputs are already occupied, you can purchase a 2408 I/O Expansion unit (the PCI 424 card allows for 4 I/O units).
-
Thanks, that's great information!
I use a MOTU 828 Mk2 which I gather will allow me to use lightpipe cable to route up to 4 stereo pairs out of and back into the mac, which assuming stereo outs would be enough for 4 instances of VE. The digital ins and outs are lying fallow now anyway.
Excellent!
--Chuck
-
-
Thanks Christian, you have answered my question, and that does make sense. I will do some more research into this when I have a moment, as I'm interested also. I suppose if a framework can give you more flexible options in as far as programming for hardware, it can potentially be more efficient performance wise. Thanks for being so up front, candid and honest here on the public forum, it's just another reason why VSL is such a superb company, and I apologise for any pressure however small - I admit do have an issue with windows, and it IS personal.... I put up with it every day at work, I get called in on my days off to deal with it all the time, sometimes more than once. I do not like it at all. If I could run only mac osx, then 99% of my IT problems would absolutely disappear. Currently I run everything on mac osx at work, with the exception of some windows apps that we need front of house, so you see, I'm in a somewhat opposite position to you - where windows is really the costly backwards pain in the butt legacy item and if not for those legacy apps that I cannot get re-written, I would never touch it again. I've come to understand IT and development concepts better than the average bear just by the virtue of the fact that I have had to troubleshoot so much at work over the years. If carbon offers more flexibility to programmers to access performance features of the hardware, then it would certainly be a mistake of apples to not push forward and do the hard work on turning it into a 64bit platform, however, perhaps it is a fair question to ask you - you have answered in a generalised form - can you say that your answer is true specifically of cocoa? I mean, apples frameworks are frameworks but, they are frameworks that are very thin and efficiently and tightly tied to the system and hardware are they not? at least for the most part - I would assume that the intention of such frameworks is simply to offer the developers a more simple environment to develop in while doing all the hard work of performance enhancements and efficiency for them (out of the box). Is that true of cocoa? Miklos.
-
miklos, i understand it would be nice to keep a process within only one platform - however this is not possible in many cases and one has to pay attention to specific behaviour (eg. character sets). too many proprietary features make it sometimes expensive to find the common denominator.
frameworks are basically a good idea to speed up development of applications - they provide a large range of prepared elements the programmer doesn't need to *re-invent* (simple examples are selectboxes, on-click events, menu trees, ect). however they are only of little use if it comes to individual elments and an existing codebase. and they are of no or almost no use if they don't allow to compile the application for all needed destination platforms.
as far as i know cocoa does not allow to compile win32/win64 applications and only a former version of visual studio allowed to compile mac versions (and i'd assume also not for leopard because of the same reason QT does not currently).
but all this goes much too far into speculation because the guys who have to sort the bytes know best what to use how and when, all that i know (and is commonly known) is, that currently it does not work and a few, but essencial, reasons for.
someone who is exclusively developing for mac might be well served by xcode/cocoa, someone developing exclusively for windows might choose visual studio - for the latter and the .NET framework i know it works well for web or more generic applications, but the result lacks performance when high performance client solutions are needed.
it's that simple, resp. it's not that simple ;-)
christian
and remember: only a CRAY can run an endless loop in just three seconds. -
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.
