Hi William,
It's not just Logic, the same thing happens in Cubase also.
-
Hi DSStudio, Yes I remember when the VI interface use to work like you suggest. The other bothersome thing is when one tries to save a custom matrix, the VSL Custom directory is no longer present. I have to Start from the Root directory and work my way back to the folder with the custom matrix's. This all seemed to change about the time the Ensemble was released. This whole interface thing has been very frustrating to me ever since I switched from the PC using Sonar and Cubase 4 to the Mac using Logic and Cubase 4. The workflow using the VI interface with the MAC is broke and workflow efficiency has been severely hampered. I have bit my tongue on this one for some time but felt compelled to chime in. If VI wasn't sooo good sounding compared to the competition, I would can the entire $20,000 library!!! The way I see it, VI need to place some design emphasis on customers that are using the Mac environment / single machine. It seems that the PC world has the definite edge here (interface & memory) even though Mac has the most powerful machine.
-
I agree with you William that it works fine in a VST rack. I've tried various combinations over the past 10 months trying for the best configuration. The issue as I see it is related to the Mac implementation and how the VI interface reacts with Logic or Cubase sequencers. I sure hope that the VI folks get this thing tightening up sooner than later. I was hoping the VE would have solved the issue but I have not been able to run two VE instances on the same machine within the sequencer without either Logic or Cubase locking up about 1/2 way through song creation -- hitting the memory wall with very little samples loaded. Running the VI has seemed to be the most stable in both sequencers, which in Cubase, allows freezing the tracks and dumping all the memory for a given instance. In Logic, I freeze but cannot dump all the memory (Logic limitation) -- therefore need to use the optimize in VI. I guess at some point I'm going to have to break down and buy a few more machines. I purchased the Mac Intel 8-core last fall instead of the three Rack PCs I had originally planned to purchase. Sweetwater talked me out of it and I have not been happy every since. Win a few -- loose a few..... Take Care..
-
I run VE2 standalone on XP64 and suffer many interface bugs. FWIW, I had exactly the same problems with VE3 standalone when I tried it. So the standalone version does not, in fact, work ok.
It only happens with large memory usage (e.g more than 3 GB), so it's probably a case of sample memory overwriting the memory space used by the UI elements. The fact that it happens at the 3 GB mark hints to me that it has to do with some sloppy coding regarding the switch from 32-bit to 64-bit. But I'm no programmer...
I can confirm the issue with multiple instances of VE - I could never get them to work. Major pops and clicks in the audio with only a few tracks running. CPU usage increases very rapidly with two instances - it's much lower with the same number of voices on a single instance.
rgames
-
Hang on a minute. there are multiple different problems being discussed here. I think that they should be separated pout. Please correct me if I've got this wrong:
-
GUI window requiring too many clicks to avoid break in workflow. I think I've given the reason why, but I agree that for some people it would be good if it worked the same as a normal plug, without losing the advantages of the separate memory space.
-
Running out of memory on OSX. This is because there are no 64bit audio apps on OSX. There will be as soon as Apple gets its act together. Be patient. VSL, or any other cross-platform developer, can't do anything about this without the co-operation of Apple.
-
Pops and clicks with large amount of memory usage. This is system specific. My current template is 14GB or so, and I don't have this problem. Make sure that you have done the registry "hack" to increase the number of Instruments from 60 to 100 and turn off your paging file.
-
-
I purchased the Mac Intel 8-core last fall instead of the three Rack PCs I had originally planned to purchase. Sweetwater talked me out of it and I have not been happy every since. Win a few -- loose a few..... Take Care..
A temporary suggestion; run your Mac in XP64 (or Vista64). Two reasons for this:
-
Cubase runs better in XP than OSX, and you'll get lower latency.
-
You could use all your memory for VE by using the 64bit version, whilst still using the 32bit version of Cubase.
DG
-
-
Hi DG, I've been contemplating doing just what you suggest. I've been told that I would have to reload all the Libraries again due to the operating system change. Do you know if that's correct? I have four drives -- 1 for system, 1 for projects, 1 for audio samples, EW and misc sound effecs and 1 dedicated to VI. All drives are 760 KB and I have ALL the VI libraries. I also have four 1TB backups, one for each drive. The files are copied not imaged. I also understand that Windows XP would also not be able to read them which would mean days to reload all the libraries and software from DVD. I kept hoping that a solid Apple solution was just around the corner but not so. I initially was lead to believe that Leopard was going to solve the issue but found out differently. At this point I'm not sure what's the better approach -- changing operating systems or just waiting..... Your thoughts? By the way... I see Cubase 64 bit available for download - Windows Platform.....
-
I just want to jump in to address a few issues that have been brought up in this thread.
Two-stage interface (Mac):
The reason for this implementation is that we made the decision to run VI's in a separate application, due to memory limitation issues of the 32-bit hosts. There is currently no way to embed an external application window inside an AU View, believe me - we tried. Hence the "Show window" operation. On the upside to this, once we release the 64-bit VI update, VI will therefore be able to use the full 64-bit address space, even inside 32-bit Logic.Gui issues on heavily loaded systems:
Vienna Ensemble is rather greedy on GUI handles (GDI Objects). Both Windows and OSX have (from security purposes) built-in limits for these handles, and once you bump into this limit, things will start to mess about in a random fashion. (Buttons not working, mixer strips in the wrong place on the screen etc). This issue has already been addressed in our internal builds, and will thus be fixed with the next update.
Thanks,Martin (developer)
-
Thanks for the update Martin. Over the past year we seen some remarkable improvements to the PC side of the house and it appeared that the Mac side was set adrift. I appreciate the fact that your team is working on a Mac solution. Understand... It's been a long wait....
-
Good news Martin. Please give us the opportunity to suggest features of the UI, success of software depends on gathering customers requirements and implement them. I suggest you open a forum thread for people to put their dreams.@MS said:
we are looking into the possibilities of how to optimize workflow with VI on Mac
Thanks,
Emperor.
-
i just thought i'd throw my two cents in;
yes, the window issue is annoying. but i've gotten used to it by now. when editing between the VI and logic sequence,i just always have my left hand on command+tab, which automatically switches between active applications.
it really doesnt bother me that much anymore. there's workarounds for most issues. I know this is a prominent one for many people, but for me there's bigger things i'd like to see them address. Such as the lack of Con Sordino for basses in the Orchestral Strings 2 set! [:@]
-
Great Discussion, I wished that topic would come up more often and earlier to really demonstrate how much of a problem that key focus is. Anybody who worked with the Word Builder app for the Symphonic Choirs from EastWest knows the pain of interrupted workflow. Every body in the plug-in industry must be struggling with the RAM limitation of a 32-bit system. Most of the user, including me, are no programmer and have to take the word of some experts about what can and what cannot be done about that issue. A lot of good and bad information is posted on all kinds of forums. My understanding is based on what I use and how the stuff works that I'm using. Here are a few examples: 1) Standard Plugins: Plugin is fully embedded into the host and shares its 3GB Memory limitation 2) EXS24: Plugin is embedded into the host but its memory space is separated from the hosts memory space. Each (!) instance shares its own 3GB limitation 3) EastWest Play: Plugin is embedded into into the host but its memory space is separated from the host's memory space. The plugin communicates with a separate 64bit (!) process that is not only separate from the host but it also lifts the 3GB limit. 4) Vienna: Plugin is not really embedded on the GUI level (key focus requires additional clicks) but at least the memory space is separate from the host, although it is also limited to 3GB. Some of you know those solutions or even use them on a daily basis. So how can Martin from VSL come up with the following statement: "The reason for this implementation is that we made the decision to run VI's in a separate application, due to memory limitation issues of the 32-bit hosts. There is currently no way to embed an external application window inside an AU View, believe me - we tried." Maybe they didn't tried hard enough or forgot to look over their plate and see what other software developer came up in the meantime. The GUI of the EastWest Player, although having issues on their own, works seamlessly like any other plugin while breaking the 3GB limitation. If you open up the Activity Monitor app then you can see that little process listed as "Intel(64bit)". From what I understand, that is what Vienna is working on right now, making their VSLserver process run in 64bit mode. Of course, there can give no timeline and I would imagine that this is not an easy coding task but the current state of the Vienna Instruments has too many compromises (for such a price tag). How would you feel if you pay 150k for a Ferrari that requires that you step out of the car, open the hood and push a button to restart every time yo have to stop a red light. Wouldn't you look back to the days when you just could stay in your beloved KIA and waited for the signal to turn green?
-
Maybe they didn't tried hard enough or forgot to look over their plate and see what other software developer came up in the meantime. The GUI of the EastWest Player, "although having issues on their own, works seamlessly like any other plugin while breaking the 3GB limitation"
My statement regarding embedding of application windows still holds up very well thank you. The difference lies in how the GUI code talks to the sampler core. For various technical/performance related reasons (back in 2005), we decided not to rely on inter-process communication for this, but instead run the gui from the same process as the sampler core/server itself. There are benefits to both strategies, one of these which you might find in your statement "although having issues on their own". On Windows by the way, there are possibilities to embed pretty much any application window into another.
Regarding EXS, I seem to recall it uses the Unix mmap call, which basically maps files into memory using underlying operating system primitives. This way you control mmaps as devices, enabling 64bits offsets. This is not cross-platform compatible though, and is not as efficient as a true 64 bit memory allocation.
-
I think that EW PLAY is a red herring. In order to use more than the memory available within Logic (meaning that there is nothing left for other plugs) you have to turn DFD off. In real terms this means that with 32GB or RAM installed you would almost certainly get less samples loaded than with an standalone version of the player.
However, one advantage on OSX is that you can use VI for 2.5GB, VE for another 2.5GB and still not tap into the memory available for your sequencer. This does not work the same way on Windows, as VI uses the same memory space as the sequencer, which is why there is not that extra click.
DG
-
Martin,
thank you very much for your detailed explanation. I think if the developers in general would explain some decision on a technical level as you did, we as a user would stop bitching around too quickly once we understand the underlying issues a little bit better.
Besides that, I still think it is bad decision to settle with the key focus problem. I'm sure once the 64bit version of VI is out, the memory problem is solved. At that point we can start nagging Apple why we can't stick 500GB of RAMs in our shiny silver boxes.
As you can see from the responses on this thread, the key focus is a REAL problem and in my opinion one of the biggest of VI. At the end of the day you judge a good product how it looks (sound) and how well you can use it (workflow). I think VSL nailed the first aspect but has major deficiencies when it comes to Workflow and GUI.
I can imagine that going from 32bit to 64bit is a big undertaking but I wish that improvements on the interface side would come a little more faster.Don't get me wrong, I like the overall GUI, but there are still some minor things that should be addressed faster, i.e. no display of the currently loaded preset, performance configuration are only stored with the preset and not with the matrix, etc …
Keep up the good work
(BTW, is the VSL website not compatible with Safari? If I copy text into the Message filed, all the CR will be deleted and everything is mashed together in one big paragraph. The format tools are also not visible in Safari, I had to use Firefox)