Vienna Symphonic Library Forum
Forum Statistics

180,802 users have contributed to 42,141 threads and 254,364 posts.

In the past 24 hours, we have 1 new thread(s), 7 new post(s) and 73 new user(s).

  • Change IP Address = Template Loses Connections to Instances

    Hi,

    I set up a template in Logic when my orchestral slave computer's IP address was 192.168.2.2. For various reasions (which I won't bore anyone with) I had to change the IP address of the computer. So now when I load my template, none of the VEP server plugins connect to the instances, and this means I have to reconnect about 70 track's worth of instruments.

    While I think I understand the process here, I'd be grateful to get feedback/clarification on my conclusion:

    When a Logic project is saved, the VEP Server plugs hosted in each instrument channel remembers the IP address of the host computer, not the Server Name (as established in the VEP preferences). Hence, if the IP address of the host changes or is changed, the only way to re-establish the connections is to manually re-connect each VEP Server plug in the project.

    So that's my conclusion. Is it correct? Also, if there's a way around this I'd love to know about it.

    Thanks,

    Peter


  • Hi,

    I've asked this question to several of my colleagues who also run slave systems, and they've arrived at the same assessment of how this works. Assuming we're all correct here [;)] I'd like to offer a feature suggestion for a future version of VEP: that the IP address of each VEP Server Interface plugin ("VEP plugin") be stored with the project data, just as the Preserved Name is stored. But not just stored... it should be editable too! This way, if the IP address of my slave computer gets changed -- either by accident or by design -- I can change the IP address of each VEP plugin with a very simple procedure: 

    1) copy the new IP address to the clipboard

    2) open each VEP plugin and paste it into the (new) IP address field, thus re-connecting the VEP plugin to the correct instance

    I think this would make for a much easier remedy than what we have to do now in this situation, which is to go into every single (now disconnected) VEP plugin and re-link it to the correct instance in a VEP metaframe.

    Food for thought? [D]


  • Bump...


  • Hi ski, 

    [quote=ski]Food for thought?

    We´re digesting. Sounds like a good idea for the next bigger upgrade, but, as Karel likes to phrase it: "No promises". 

    Best, 

    Paul


    Paul Kopf Product Manager VSL
  • Thanks for your reply Paul! Re, "No promises", of course I understand. But thanks for digesting! Much appreciated,

    Peter 


  • Bump.

    As an alternative, just use the slave machine name instead of IP address.  In these days of mDNS, Bounjour, etc, there's really no reason to ever use IP addresses.

    I connect to over a dozen instances, so connecting them all manually is a pain and I often work onsight for clients on different networks, so my slave IP changes frequently and a static IP is not possible.  I don't care how you solve it, but would love it solved as it's a serious usability issue for me.  Many of my fellow professional composers have complained about this particular misfeature on many semi-public professional forums.

    - Longtime VE Pro user


  • I come across this situation quite often, but I have just finished working on a project where the composer I am orchestrating for provided me with his orchestral template, specifically the Metaframe he is using.

    Now, the only thing cannot be granted to be always the same between different configurations of different professionals is the IP address of our slaves. Sometimes they are in a different range (i.e. 192.168.0.x vs 192.168.1.x), so even reassigning the correct IP address is not always an option.

    Currently, upon opening a project, the VEPro plugin scans for the available servers, looking for the specific IP address the plugin was connected to when the project was saved last time. If it finds it, it looks for the right preserved instance. If it does not find it, it stops searching and stays disconnected.

    I think the searching strategy should be a little different. The plugin - in case it does not find the server at the expected IP address - should ask the users whether they want to scan all the other servers, searching for an instance with the same name of the one saved within the project.

    Please find my idea illustrated in the following flow chart (reading left to right).


  • It should do both (favor instance name over IP, and follow Gemini's proposed logic when it can't find an instance).

    Another, simpler solution would be to enforce unique instance names across the LAN. Thus, when connecting, VE Pro should just ignore IP and hostname altogether and just find the instance name, whereever it is on the network.  That solution would likely work for the average home user, though it may not work for large music houses with multiple composers working on the same LAN.


  • Has this ever been resolved?

    My slave PC has decided to lose its static IP address several times over the last couple of years and become dynamic, and each time it has completely trashed whatever projects were relying on that particular IP address.  The problem is that any project created under the new IP address behaves normally until such time as the dynamic IP address changes again, thus trashing all my VEP instances yet again.  So it does this sneakily, but seemingly irreparably, since I can't determine which dynamic IP address the PC may have been using at the time the project was saved last.

    This is utterly unacceptable.  There must be some solution.  I just can't understand why my master Mac VEP server can't at least look at the network and ask if I want to load instances on the PC it sees there.  Instead it tries to load them on the Mac, which of course totally fails.  Nor can I disconnect the Mac instances and load them on the PC instead, because the instances end up totally null, insofar as instances of Kontakt, etc., are concerned.  The mixer on the PC VEP instance looks the same but the VIs in it are unclickable and null.  Only the Vienna Instruments, if any, work.

    Is there a workaround?  Is there a solution?  Is there an update that fixes this extraordinarily hazardous shortcoming of the product?  Please advise.

    --Chuck