Vienna Symphonic Library Forum
Forum Statistics

194,415 users have contributed to 42,920 threads and 257,965 posts.

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

  • last edited
    last edited

    @Another User said:

    again, we thought this being a treat rather than a bug:
    1) When you close the GUI Window you actually hide it - clicking "Show GUI" makes it appear again
    2) You can minimize standalone.
    3) Staying on top: Consider if VI GUI won't be a floating window - it will disappear whenever you click another window - then you start searching for it.



    I'm not sure who wrote this, but it's seems a little arrogant to say that the VSI window should float when none of the other virtual intruments by other manufacturers float. This means we continually have to keep moving VSI out of the way to get at other VIs, not to mention accessing the valuable screen real estate of our sequencer. Hey, we're all used to VIs not floating, why throw this monkey-wrench? In an ideal world, we would have an option to float or not float all our windows. But there are just SO MANY things about VSI which are truly annoying, while none of the other VIs I use interfere with my work flow as much as this one does.

  • last edited
    last edited

    @garylionelli said:



    I'm not sure who wrote this, but it's seems a little arrogant to say that the VSI window should float when none of the other virtual intruments by other manufacturers float. This means we continually have to keep moving VSI out of the way to get at other VIs, not to mention accessing the valuable screen real estate of our sequencer. Hey, we're all used to VIs not floating, why throw this monkey-wrench? In an ideal world, we would have an option to float or not float all our windows. But there are just SO MANY things about VSI which are truly annoying, while none of the other VIs I use interfere with my work flow as much as this one does.


    It was me who wrote this ...

    1) Your statement is simply NOT true: every AU Instrument in Logic floats. And this is inherent to how Logic puts up the windows.
    2) There is this extra button indeed. It seems to be redundant. It is. But we have devised some different architecture which has a bunch of benefits - tho not all are fully explored - and this extra button is the tradeoff at the moment.
    I say at the moment. We investigate to get rid of this, however.

    Nevertheless I can still consider this as a feature: Since AU always floats, you can arrange them on one side of the screen ( I will make this window much smaller, just to hold the Show Button) one below the other and thus you can quickly access the VI GUIs. Think of this as a handy chest of drawers.
    The "normal" procedure would be - provided you work on sequence view (Arrange) - bringing up mixer window and clicking the corresponding button. Truly more impeding the flow.

    Check it out.

    christian teuscher
    development

  • Christian,
    In the DP world, nothing floats. To have VSI float, for me, is an inconvenience. I want VSI gone when I click elsewhere, and right now I have to close it and then deal with a slew of mini-windows to reopen. Of course everyone has different work prefs and I respect that, but VSI still floats even when you change to a background app like a web browser, and that is arrogant behavior by an application, in my book. Often times as a diversion, we all check our email, browse the net, etc., but there VSI remains, omnipresent, breaking the Mac's inter-application etiquette protocols.

    I've been unusally vocal about VSI's behavior because I'd like to see these things change, and we have received little feedback from VSL regarding their intentions. The issue of floating windows, however annoying they may be to me and others, pales in comparison to the problems of license recognition and slow loading time due to Syncrosoft. If I'd spent maybe $1000, I wouldn't be so bothered, but I had to sit and think about whether upgrading to the full VSI library coming from owning the full Pro Edition was warranted enough, given the high price for the upgrade. I finally decided to buy the full version only to be slammed by having it be barely working, and then when it did work, having to deal with all the user interface quirks. I might have been better off not being an early adopter, because trying to get work done with VSI has been an ordeal for me so far.
    Thanks,
    Gary

  • Well...

    Tinkering with Logic, VSL V.I. AU, and V.I. standalone revealed the problem. I'm running Logic 7.2.0. I had not attempted to run the standalone V.I. prior to working in Logic. My Logic setup covers the *entire* monitor screen with Logic's arrange page and other associated stuff- the counter, plugs, etc. This is key. I would click on 'Display GUI' and again nothing would appear. As I quit Logic, I noticed for a brief second a window in the Mac's Finder asking me to 'Select a custom Matrix folder', and then the window disappeared. I then ran the V.I. standalone, and this time (because the standalone does not use the entire monitor screen as does Logic) I was able to see and respond to the window, which popped-up in the background of the standalone V.I. I was able to see it this time and chose a folder, then the instrument interface appeared. Back to Logic- I guess because I had already chosen a folder in the standalone, the window did not pop up again in Logic, and instead the correct interface displayed. Note to Mac developer: the dialogue window is popping UNDER all of my Logic Windows, so I didn't know it was there. Is there a way to make this window pop above all other windows (including Logic's) so that it does not become obscured?

    Looking forward to jumping into the VSL V.I. now [:D]

  • I think I need a third monitor. Does IMAX make computer monitors? [:D]

  • last edited
    last edited
    well, if could afford, this would be my favorite ...

    and remember: only a CRAY can run an endless loop in just three seconds.
  • i'm with gary on this one.

    in DP, the most annoying thing is having to click on a DP window after making any alterations, in order to be able to play a midi keyboard to hear any sounds. whenever the VSI window is on the top, the midi keyboard won't play any sounds. this means that any tweaks i make on cross-fades, keyswitches, patch changes, etc, i then have to click EVERY time on a dp window to find out how it's going to sounds. a massive waste of time, and very frustrating. similarly, having to drag the window out of the way, just to be able to access any of the other windows. i've got 2 23 inch monitors, and still this ruddy VSI sindow is clogging up way too much space - would like it to work like the spectrasonics stuff - the window's always there, but it's up to you where in the screen it is, and whether it's got other windows above or below it - it's not exactly THAT hard to find a window when you want to. F9 on the mac gets all the windows up there in a second so you can see where you are.

  • last edited
    last edited

    @cm said:

    well, if could afford, this would be my favorite ...


    OMG!! That monitor is incredible. I'd never seen that configuration before!

    Yet, for the floating window issue, I would even settle for just being able to start and stop my DAW when the VI Console is on top. That, imho, is more awkward than opening and closing windows. At least we can whoosh any number of Consoles onto the dock in a pinch.

    It may sound a little picky, but the clicks add up quickly. 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....

    ... and on, and on. One can easily do a dozen or more refining edits with each pass, and that one little extra click can easily turn a 6-7 click process into 72 moves or more.

  • last edited
    last edited
    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........

  • last edited
    last edited

    @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 ...?

    /Dietz - Vienna Symphonic Library
  • 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"

  • last edited
    last edited

    @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.

    /Dietz - Vienna Symphonic Library
  • 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.

  • last edited
    last edited

    @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,

    /Dietz - Vienna Symphonic Library
  • 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.