Vienna Symphonic Library Forum
Forum Statistics

183,299 users have contributed to 42,291 threads and 255,040 posts.

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

  • Is there a plan to address the file association issues anytime soon?  


  • thanks a lot. can´t wait to test it. but let me submit these 60MB downloads always take between 45 and 60 minutes to downlaod this is like 1998. i can´t stand it. is there something you can do? is there a special bandwith limit for software as opposed to instrument downloads? maybe add a couple of servers? thanks

  • Takes like two minutes to download here.

  • Just tested the new version and that earlier crashing problem is fixed! Great work.

  • While I've been in contact with Paul directly, I wanted to publicly acknowledge the hard work of the VSL team in listening to our concerns.  Since I updated to the 4604 beta the crashes of the 32-server upon loading have stopped, and I no longer have issues with the LASS scripts as I detailed in the earlier threads http://community.vsl.co.at/forums/t/23261.aspx and http://community.vsl.co.at/forums/t/22729.aspx.

    While I haven't yet upgraded to 4657 I just wanted to send my thanks to Martin, Karel, Paul and the rest of the team.

    Cheers - Brett


  • Appreciate that update Brett. Good to know all is working now with LASS.

  • In the release notes, the very first item mentions sticking to the built-in MIDI inputs. As a Logic user who is relying on the external MIDI ports to get around the AU midi limits, can I ask what the issues are...

  • The events will have unreliable latency and jitter. Especially when mixing down or freezing audio. None of this is true for MIDI events passed through the connector plugin.

  • The new build performs sluggishly on my system.

    Mac Pro 8-Core 2,88 Ghz

    14GB ram

    Logic 9

    A single 64-Bit instance with 16 instruments loaded and a setting of 4 Threads will report a CPU usage between 30% and 40% when idle and will go above 50% when playing some instruments.

    OS X Acitivity Monitor shows a CPU usage of about 182% when idle and approaches 300% when playing instruments. It also shows 27 threads.

    The interface is very sluggish to the point, that it is a chore to drag instruments around.

    The last stable version was a smoother interface experience for me.


  • Is it possible to implement a loading time bar? Or at least some indicator that the program is still "alive". The win7 task manager states that the program is not responding even when it is loading something. However it could also mean the program chrashed. You only know after waiting für a looong time. I have issues with jbridge. I can load a jbridged samplelord in the 64bit host on win7 with no issues. I can load tons of samples in it, I can save the project file - but I can't reload it the next time. It crashes. Another thing I do not understand is the fact that 32 and 62bit project files are mixed in the files selector. As I recall I can also see 64bit projects when I want to open a project file from a 32 bit server.

  • Great work!


  • last edited
    last edited

    My project became increasingly harder to work with, but after restarting the computer it works smoothly now. 0% CPU usage when idle.

    @Johannet said:

    The new build performs sluggishly on my system.

    Mac Pro 8-Core 2,88 Ghz

    14GB ram

    Logic 9

    A single 64-Bit instance with 16 instruments loaded and a setting of 4 Threads will report a CPU usage between 30% and 40% when idle and will go above 50% when playing some instruments.

    OS X Acitivity Monitor shows a CPU usage of about 182% when idle and approaches 300% when playing instruments. It also shows 27 threads.

    The interface is very sluggish to the point, that it is a chore to drag instruments around.

    The last stable version was a smoother interface experience for me.


  • Now, where I solved the Program Change problem, I would like to use the VST3 version of VE Pro with multiple MIDI and audio ports. But if I set number of audio channels above exactly 94, then Cubase 5.1 crashes. Either right when creating the VE instance or at least if I enable all audio ports (only the first two are enabled by default).

    It is really odd, the limit seems to be exactly 94 audio channels. If I keep the setting at 94 or below, all works great. Setting 96 or more will make the system unusable - crashes all the time. It is easy to reproduce the problem on my system. Even a new empty Cubase project and a single empty instance of VE Pro (VST3) will reproduce the crash.

    Not sure whether this is a Cubase or a VE Pro issue. Anyone else having this problem?

    PS: Is it advisable to minimize the number of VE Pro instances, or is the overhead per instance negligible?

    System: Vista 64, Cubase 5.1 (32 bit), VE Pro 4657

    Best regards,

    Peter


  • A few problems with Kontakt 3 remain.

    Notes will sometimes hang.

    VE Pro instances that have Kontakt instances in them will often stop working completely for about 20-30 seconds before resuming as normal. During that time VE Pro gives me the spinning beach ball. This happens to me every 3-5 minutes, sometimes during playback, sometimes when idle.

    Mac Pro 8-Core 2,8Ghz

    14 GB Ram

    Mac OS X 10.6

    Logic 9


  • That doesn't sound nice. Is anybody else having similar problems?

  • last edited
    last edited

    @Karel said:

    That doesn't sound nice. Is anybody else having similar problems?

    In Motunation forum I read that one user could get rid of the dropouts by not using his 828mk3 interface, and instead use the Mac Pro internal output. My main interface is 828mkII with 828mk3 daisy-chained. I tried switching the 828mk3 off all together: now after testing the setup for 10 minutes, no dropouts. So this might have to do with the 828mk3, for some weird reason. Let's see after longer use what happens.


  • I don't use an audio interface.

    Everything is done by my Mac Pro.


  • I did some more testing and the problem seems to appear only in big projects that use most of the ram.