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)

@MS said:

we are looking into the possibilities of how to optimize workflow with VI on Mac

Indeed, software is evolutionary by nature. You can rest assured that these forums are constantly monitored by several of our team members. Any ideas are discussed within the company and if considered useful or appropriate - scheduled for implementation.

Cheers

 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! [:@]

@Edgar Rothermich said:

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.

 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) 

@MS said:

On Windows by the way, there are possibilities to embed pretty much any application window into another.

Vienna Ensemble was designed from scratch to be running as a standalone application, alternatively as a network/local slave host. There are some certain considerations to be made if an application is intended to be controlled from a plugin window, one of the reasons is that various host applications tend to mess about with the Windows event handler in one way or another. This is why you won't see that many plugins utilizing keyboard commands. Running as a separate application we are not enforced to obey whatever rules the host sets up for us.

never mind

 Martin,

I don't see much of a priority to deal with the key focus issue in your last post if I read between the lines correctly.
A standalone version is all good for its own purpose, but when working with a host, you want to stay in that environment and don't want to be forced to click constantly between two apps not to mention the headache when you mess up one or the other app because you thought the key focus was in the other one.

A good workflow provides speed and that has a lot to do in my opinion with having your Key Commands customized and "flying through" the commands as a second nature. That however is extremely compromised when you have to constantly check what app is in focus before you hit a key.

I know, not many plug-ins use their own key commands and that is a good thing. It would create too much confusion. That confusion is already happening to some extend in Logic8 where you can have key commands performing different tasks depending what window inside Logic has the key focus.

Software developer give us amazing tools and  let us be creative in ways we couldn't even imagine a few years ago. But we as the grateful user have to make ourself heard when some developments seem to go into the wrong direction or going out of hand that will be counter productive in our creative process, i.e. messed up key focus and GUIs that force us to make unnecessary clicks over and over again.

And William,
it seems that you have a problem with "workflow". I hope it is just the word you don't like because I'm sure YOU have one in your work unless you work in utter chaos which is fine as long as it suits you.
I have no desire to use VE inside the DAW because it duplicates features that are already there in the DAW (Mixer) and just makes routing (Sends, Returns, Reverb plug-ins) more messy. But I have a desire of using the VI as a plug-in like any other plug-in inside the DAW as long as it doesn't interrupt my (yes you guessed it) workflow. The "outsourcing" of memory and CPU independent from the host is the right step as long as the GUI and Workflow (here we go again) doesn't suffer.

I worked many years with a configuration of one machine running the host (Logic) and three PCs running Gigastudio. Now I'm down to two 8-core MacPros, one running Logic as the main Sequencer and the slave machine running Logic as a playback Sampler that gives me the same firepower as the 3PCs.
I wished the technology of distributed processing and grid computing would move a little faster in the audio production world. The fragmentation of our production tools (Master and Slave computers) creates too many problems. Why would you build a mixing environment with 5 patched up Mackie mixers when you can run the same thing on a big 100+ channel mixing console where everything is centralized.
This is the direction were the developers should push it. But that is just my opinion

 There is one other major problem with key focus I want to point out.

In OSX there is always one app in the foreground, the one that is displayed in the menu bar. Let's say "Logic Pro" now all the key strokes apply to that app except the system key strokes or any other third party utilities (i.e. QuicKeys).
If I run VSL as a standalone app then I could switch between the two apps (Logic - VSL) for example using QuicKeys commands. The menu bar always gives me a visual feedback what app is in the foreground.

The VI pug-in however screws up the whole GUI concept. It operates still inside Logic Pro, so the menu bar doesn't switch and tells you that you are still operating in Logic Pro - but you are not. The GUI tells me that Logic is still in the foreground when actually VI is in the foreground without telling the GUI . It is living in this "GUI twilight zone". Excuse me for making the comparison, but this kind of GUI functionality could come straight from Microsoft. How this concept could pass the developing stage and considered to be acceptable is beyond me.

Doesn't Apple set strict guidelines regarding the GUI? Martin pointed out some technical reasons for making that decision, but they should have never settled  with that bad compromise. If a small scale garage based developer come up with something then it would be ok, but for such a big player with a big bucks product, I think we as the user can ask for a "... please, try harder!"

What worries me in the previous post from Martin is that it seems that they made that GUI decision and are somehow ok with it. No word about, "... sorry, but his is just a beta release and the next update will fix that ...".