Vienna Symphonic Library Forum
Forum Statistics

182,391 users have contributed to 42,223 threads and 254,774 posts.

In the past 24 hours, we have 3 new thread(s), 15 new post(s) and 44 new user(s).

  • Hi Paul,

    I had hoped that the new version would fix this problem, but I am still having it.

    Michael


  • Hi Michael, 

    Did you try CM´s suggestions yet?

    Best, 

    Paul


    Paul Kopf Product Manager VSL
  • Thought I'd chime in.... Paul, what suggestions by CM?  I'd characterize his post more as a defense of why it's not working, and pointing it in Apple's direction, and how they have done a 'firewall for dummies'..... :)    He does mention that possibly the issue could be fixed by doing something in terminal - but then says he couldn't actually find any info on it.

    The issue we are having is that in OSX firewall, we have set it to allow connections to VEP, but are STILL getting the message popping up asking us to allow or deny incoming network connections.  I just did a quick test -- took VEP out of the 'allow incoming connections' list in OSX frewall, and launched VEP again.  It behaves exactly the same as when VEP is in the 'allow connections list' in OSX firewall.   The only way to make this popup window go away is to turn OFF the firewall completely.

    To me, that sure seems like the issue is with VEP.  I don't get this popup with any of the other apps that I have in my 'allow incoming network connections' list - just VEP. But, it's not like it's a show-stopper or anything, just one more thing we have to do when launching our rigs at the start of a new day.  For me, it's just a small hassle - not that big a deal.  But, it would be great if this could be sorted out so it worked as it should.  

    Thanks.   

    Best,

    Greg


  • last edited
    last edited

    @wgturner said:

    Paul, what suggestions by CM?

    you're right - it was rather a rant than a suggestion 😉

    i digged out an older information about used ports for VE PRO:

    > 6472: 32bit server connection (TCP)

    > 6473: 64bit server connection (TCP)

    > 6474: 32bit server discovery request (UDP)

    > 6475: 64bit server discovery request (UDP)

    > 6476: 32bit server discovery response (UDP)

     > 6477: 64bit server discovery response (UDP)

     

    my suspicion is the current OSX firewall does not discover the UDP ports correctly ...


    and remember: only a CRAY can run an endless loop in just three seconds.
  • last edited
    last edited

    @cm said:

    you're right - it was rather a rant than a suggestion ;-)

    HAHAHA!  Hmmmm... maybe that is what's going on.  I know someone who is comfortable doing terminal stuff, and will ask a few questions.

    Thanks for that info.

    - Greg


  • i just stumbled across some hint related to OSX server http://support.apple.com/kb/ht5413

    it appears apple has moved from IPFW to PF - the article also indicates older rules might remain active in case you upgraded your system from an earlier version ...

     

    i want a 10.9 capable mac please - at best a MacPro ;-) too much unusable scrap with an apple logo here ...

     


    and remember: only a CRAY can run an endless loop in just three seconds.
  • i just learned there are actually 3 firewalls in OS X: IPFW (deprecated, but former rules might remain active), AFL (the one you have basic access throught the GUI), PF (accessible anly throug pfctl or a third-party-tool)

     

    you can also configure AFL through the command line:

    add a computer to the whitelist: /usr/libexec/afctl -w 192.168.0.10 (the IP of the remote computer)

    add a class-C network to the whitelist: /usr/libexec/afctl -w 192.168.0.0/24 (your private or audio network)

     

    if that does not solve the issues we had to dive into pfctl ...


    and remember: only a CRAY can run an endless loop in just three seconds.
  • Great info!  Thanks!!

    Best,

    Greg


  • Thanks for this info, but I am not really comfortable working with command line stuff. I agree with Greg that this is not a huge problem, but it is a bit of an ongoing irritation and it would be great if it could be fixed.

    Best,

    Michael


  • i couldn't agree more ...

    i'll try to get my hands on a mavericks capable mac and dive into the depth of firewalling for a more profound knowledge.

    as suspected earlier - it _could_ be that UDP ports are not read properly.


    and remember: only a CRAY can run an endless loop in just three seconds.
  • This problem persists in the latest VEP update. Again, it is not huge, but it continues to be irritating.

    Michael


  • I also have this problem.

  • I've had this problem for a couple of years now. Alongside Vienna Ensemble Pro, it affects Pro Tools 11 and Ney-Fi too. All in all it's a minor nuisance, but it has that awful "fingernails on blackboard" quality.

  • I has been more than a year since the last post on this topic. I am still having this problem. Paul, is the VSL team still looking for a solution?

    Thanks.

    Michael


  • Hi Michael,

    Looks like we gave up, at least as far as VE PRO 5 is concerned.

    Instead, we´re focussing on implementing many new features from the VE PRO wishlist. Hope this problem can also be solved with the next major upgrade/update (not scheduled yet). 

    Best, 
    Paul


    Paul Kopf Product Manager VSL