golem wrote:

@Another User said:

1) Your statement is simply NOT true: every AU Instrument in Logic floats. And this is inherent to how Logic puts up the windows.

Christian, it is true that by default, when you open any plugin window in Logic, it opens as a floating window. (You have an option to open as non-float by the way)

The big difference is this: ALL floating windows in Logic go to the back when you bring another app or the Finder to the front. This is also the case with all palette windows in most graphic apps and seems to be the default Mac behaviour. I just tried with Stylus RMX, FM7, Korg M1 and 10 native Logic plugins. When I bring the finder to the front, then the finder windows cover the Logic plugins, which is what one expects.

The only exception is the VI plugin GUI - it floats, but does NOT move to the back at all....ever. If I <hide> Logic, all the other floating windows disappear completely, along with Logic's other windows, but the VI GUI remains. This is not "normal" behaviour. If you can change this, I imagine we'd all be very happy.

Regards - Colin

i find that it is even worse than that.

say you're in Logic and change the patch on the VI. the VI actually takes over and sends Logic to the back so that you don't see the transport control floating pallette anymore and does this wierd dick dance every time you re-select logic. it's like the VI is actually in standalone mode while being opened from inside of Logic.

fortunately i only use Logic to house the VIs and trigger them with DP from another mac so i have dodged the frustration bullet and have to deal with it on a minimal basis. I do need to see that the transport is playing so that i know that DP is actually playing Logic though.

It's just not elegant. for the price that we all have paid we deserve something that is of high quality in both sound and in design.

It's like all standards are have been tossed out the window and replaced by lame excuses. i'm just glad that i don't have to use the VI in DP after hearing what all of these other dudes are dealing with.

..........patiently waiting for a version update........

@JWL said:

[...] I currently have to:

-- click out of DP on the GUI Interface
-- do a Console edit
-- click back inside DP (which often highlights some other feature not needed at the time
-- re-click on the DP feature in question to recover the edit points made prior to editing the VI Console
-- hit play
-- hit stop
-- click out of DP on the GUI Interface....
[...]

I'm just re-discovering DP at a client's studio after not using it for a long time, and it seems that it is the only modern DAW I know where you have to "activate" each window by "re-clicking" before you can change a parameter. This special behaviour won't change, I think.

Apart from that - is DP not able to play in the background, or did I misunderstand your issue ...?

i think what he is saying is that since he can't see what is behind the VI in DP he just takes a stab and hits whatever he hits. sometimes it's a knob sometimes something else....?

yes DP can play in the background. it seems that they haven't checked the Patch thru in background button in:

-preferences
-midi solo & patch thru
-Patch thru in background ?

Hello. It's "they" at your service!

Let me try to explain more clearly. When editing midi note information, I highlight the keyswitches or MIDI notes in question. Certainly, going from the Tracks Overview to the Midi edit window, as my preferences are set, necessitates double clicking on a section of the Tracks Overview. Leaving this segment highlighted helps me find my place when moving from window to window.

Once I need to adjust the VI console, I click out of DP and into VI. Once I'm ready to return to DP, I often de-highlight my MIDI note selection accidentally in an effort to activate the proper DP window again. I suppose one could make a habit of clicking on the window frame to avoid this, but this is something I've only tried since my last post.

As for DP playing in the background, mine is set to do so. The issue is that DP's keyboard commands are inactive while the VI console is on top. I can hit play, then activate the VI console and DP will continue playing.

But the more I "hear" myself describe certain issues with VI, the less they seem important. Reality dictates that changes and updates won't be made for a while, and there's no assurance that anything we've discussed doesn't fall into conflict with the VSL Team's vision of how VI ought to work.

Only time will tell, but for now I'll just thrive on the many workarounds being offered throughout the forum.

Cheers,
"They WL"

@JWL said:

[...] The issue is that DP's keyboard commands are inactive while the VI console is on top. I can hit play, then activate the VI console and DP will continue playing. [...]

I see. You could consider either a dedicated little MIDI-transport-control for your sequencer (... maybe your masterkeyboard already offers them ...?), or you could use a combination of MIDI-keys for start/stop, if this feature is available within DP.

Hey Dietz-- wouldn't you rather we saved that same money for more VI updates than for more controllers and triple or quadruple monitor setups?

Of course, there was a thread that discussed having a VI-exclusive contoller. That would be the ultimate.

Having read through this thread and others about the VI and screen behaviour, i have a question.
For those with two screens, can't you put the VI's in the second screen, and will your sequencer respond once again to commands if you do this? I understand the issues involved with the screen priority comments, but i'm at a bit of a loss understanding if a second screen setup would 'sidestep' the current issue or not.

It's not as if a dual monitor card and a second screen is beyond financial reach for many, and given the direction of the sample industry in general, i would have thought this was inevitable, and a possible assist to a more streamlined working method. I'm not taking away from the current challenge or dminishing the opinions of those who have posted comments, but thinking further ahead, is it as big a deal as we may think?

Regards,

Alex.

@Alex:
I don't think a 2nd screen will change anything. I use a 30" monitor and I have quite a lot of space at present, but it alters nothing. When you work with the VSL GUI (AU plugin version on Mac), it brings VI "to the front" - ie VI seems to function as a separate app from the host (eg Logic). You have to bring the host back to the front to activate certain commands.

This behaviour is not unique to VI as a plugin though. Several other Audio Instrument synths also "take control" when topped - arrow keys move around the list of presets for example.

The one thing that ALL other plugins do is move to the back when another app is topped. I've complained about this in a previous post, but will wait until after the Easter weekend for any replies on this.....

Regards - Colin

Exactly Musos.

I'm running VI in standalone AU on MAC patched into ProTools via RAX, and when I bring ProTools to the front, the VI is still on top. This is not normal behaviour, whether u want to acknowledge it or not. No other virtual instrument does that fyi.

@JWL said:

Hey Dietz-- wouldn't you rather we saved that same money for more VI updates than for more controllers and triple or quadruple monitor setups?
[...]

Not a bad idea [;)] ... i was just trying to make your life easier right now.

All the best,

the thing is that when the VI is on top (in control) the audio may pass throught the host (if the settings are set to do so) but the transport commands are no longer available since the VI has control (ie: on top). this is where the problem with workflow is. since the VI is on top in control we can't start or stop the sequence without regaining control of the host.

if i have RMX or trilogy or Mach V running in DP land and on top. I can still start and stop performer whether it is visible or not. those VIs don't need to be controlled so they don't need to be in control (on top, sort of). Anyway the point is that the VSL VI behaves very differently than any of the other VIs that I use and I have nearly all of them. It's very annoying and obnoxious VI behavior.

It's an easy fix I hope. maybe just a misunderstood concept.

Yes-- the keyboard being deactived while VI is on top was what I was mentioned earlier.

So, here's a thought:

The keyboard is connected via USB.
Syncrosoft key is connected via USB.
In both cases, there is some sort of communications block.

Could the two issues be related? [[:|]]

@JWL said:

Hey Dietz-- wouldn't you rather we saved that same money for more VI updates than for more controllers and triple or quadruple monitor setups?
[...]

Not a bad idea [;)] ... i was just trying to make your life easier right now.

All the best,

Thanks ! Ihad no doubt about that.
Now, will you update the VI so that at least you get only one floating window ?

2nd monitor doesn't make any difference. i have 2 23 inch apple ciname displays. the mixer sits in one (takes up all the screen, even on narrow view), and i have most of the editing windows, etc on the other display.

it's just all the clicking that's driving me insane!!! totally messes with the workflow!

happy easter, by the way [:)]

(((( bump ))))
Any word from the VSL team? Is there an update in sight? Do all our comments count....?

( bump? what does that mean? )

there will be a nice solution for this problem in 1.06

to be released along w/ VST OSX and possibly RTAS OSX

will enter test department these days

we _do_ listen - don't worry

thanks

christian teuscher
development

@Another User said:

bump? what does that mean?

[:)] When a topic is slowly going down the list because of no activity, one can "bump" it up to the top by writing a new reply. (This is a kind of geeky-forum term)

Thanks for the response and the news Christian - much appreciated....

Regards - Colin

Yes, thanks for this good news

Great news Christian.

Pretty pleeeease with the RTAS version. [[:P]] [[:P]]