Vienna Symphonic Library Forum
Forum Statistics

186,589 users have contributed to 42,469 threads and 255,880 posts.

In the past 24 hours, we have 6 new thread(s), 19 new post(s) and 45 new user(s).

  • [SOLVED] VEPro 5 - connection problem

    Hi folks,


    Need help urgently: VEPro  is not connecting my two OS X computers anymore. It used to do this fine a couple of weeks back, now when coming back to work it does not.

    I have two computers, a mac mini and a macbook pro, both running High Sierra and VEP5 (the latest update of 5). I'm primarily using VEPro with Sibelius (Ultimate). The two computers are connected with an ethernet cable, without a router.

    I'm attaching a picture of my network settings from both computers (the other machine OS has the Finnish language, but the idea should be clear...). I tried having both fixed and dynamic IP addresses, no luck. Left it right now at fixed.

    Anyone? Will mail support of course if no answer here.




    Jussi L.




  • Hi Jussi,

    Please set the Subnet Masks to (instead of on both machines.

    Best, Marnix


    The subnet was the answer! Although I get along with computers somhow decently, any network related things drive me more or less crazy, and this is the first time I've had to touch the subnet settings. What does it do anyway, why is the automatic setting not good?






  • In short the subnet mask defines which IP-Adresses are directly and physically reachable from the given local IP-Adresses interface. Those are the IP-Adresse that are „on the same wire“ as the local interface. A netmask of in the given case means the all packets to IP. adresses (with xxx being 0 to 255) can be sent out directly over the interface to reach their destination. For all masked parts (with the first three bytes = the first three dot separated parts of the IP address) the packets will be sent to the default gateway configured on the interface (typically set via DHCP), that then knowns to whom to route those packets in order to reach the destination IP. So, a means that no other IP can be reached via the interface (not even the gateway). Can not work this way ;-)

  • ok, thanks! Got it somehow....

    But actually, the problem persists:

    Didn't have time to check last evening if it indeed was working. The dialog in Sibelius reported different static IPs than I had specified in the network configuration-dialog (ending in .142 and .194 for my two computers). Also, the local machine (Mac Mini) now showed an IP address in the VEPro connect-dialog, that has previously been listed only as "localhost etc..."

    Also, the sound from the slave was severely distorted and with a big latency, and turning of Wifi confirmed my suspicion that it was trying to connect via Wifi (or so it seems).

    So the manually set IP-addresses still don't show up (Master:, host:, subnet mask255.255.255.0)

    Sent to Marnix by email as well


  • You may try to enter the respective IP adress directly. “localhost” is the default name for IP adress that is internal (or virtual, you have that even if your computer does not have any physical network card at all). This IP simple means “this computer itself”. So, after configuring your network card (NIC) your master computer has indeed two IP adresses: the on the NIC and (localhost) internally. For the software running locally it should not really matter which one to use. To see wether it works on the lowest level you can open a terminal window on the MacMini (simply use spotlight to search for “terminal”) and enter e.g. “ping”. That sends special “test” packets to the given IP and sees wether it responds. Simly understand that an IP adress is “per interface”, not “per computer”. In your case that may be e.g. (internal), (dynaminally set on the WiFi card via DHCP), and (manually set on the LAN NIC) all at the same time. If an other computer connects to you via then the connection will be via WiFi, if it connects via it goes via LAN in this example. The same target computer, just an other adress (and route).

  • yes, thanks all for the help.

    Case is now closed, the subnet mask was at first the critical thing, that had to be manually corrected to

    After that it still tried to connect via wifi (saw only and, the wifi ports presumably).

    After that, disabling wifi on the slave forced the manually set IPs to come alive, and now it seems to work again.

    Just have to remember to not use wifi on the slave....