200,563 users have contributed to 43,201 threads and 259,100 posts.
In the past 24 hours, we have 2 new thread(s), 9 new post(s) and 74 new user(s).
Thanks for the info. I switched everything back to 32-bit (Logic & VEP), and the CPU usage became *much* more reasonable. I didn't know there was such a processing overhead when working in 64-bit.
BTW, to switch back to 32-bit, I saved several .viframe64 files, which I then opened without any apparent problems in the 32-bit VEP server. What is the difference between these file formats? Because it seems they are interchangeable.
Thanks.
Hello Talino,
congrats to the Kipling-finding, I knew it was just a matter of time [;)]
64 bit viframes can load more samples on a 64 bit system with more RAM. So if you load a 64bit *.viframe file with 8 GB in a 32 bit VE PRO, you will get into troubles.
Best,
Paul
Thanks for the quick reply. So if I understand correctly, apart from being careful about opening large 64-bit viframes in a 32-bit instance, there's nothing wrong with opening the "wrong" file format? I personally find the 32/64 transition confusing enough as it is without having different filetypes as well...
In order to make this easier to manage, wouldn't it be possible, in a future version, to simply make the amount of RAM required by the instance part of the viframe file data itself (the amount reported by VI or VI Pro in "used RAM")? You could then verify, upon opening the file, if the RAM needed is above the amount that is accessible by the plugin (or simply when a 32-bit instance tries to open a > 4gb project). If you do that, you will no longer need two filetypes, and, which is more, you'll be a man, my son :)
Just my 2c.
You said that you are using Vienna Instrument PRO and what I was pointing out is that VI PRO uses too much CPU. The regular Vienna Instrument is very easy on the CPU in my 64-bit environment. Did you say that the 32-bit version of VI PRO is lighter than the 64-bit version? I have to try that. Maybe there's a bug in the 64-bit version that causes the difference.
No reverb. I have 61 VIs which I converted to VIPs with the VEP convert function, I didn't do anything else. In addition to using several times more CPU the VIP also loads aa looot sloooweeeer than the VI. With VEP crashing on my XP32 slave and VIP too heavy it seems that I have to go back to the previous VEP and postpone switching to VIP. I'm sure the next versions will work fine. [:)]
I tried both VI and VIP with my template viframe. The VI version has 61 instances and I used the VEP converter to make the VIP version. I measured the time it takes for the VI to show the GUI and for the VIP to get through the progress bar and then looked at Task Manager. I booted between the tests.
VI:
Load time: 5 min 10 seconds
Memory usage: 3.88 gigs
Task Manager CPU usage: 2%
VIP:
Load time: 8 mins 45 seconds
Memory usage: 5.42 gigs
CPU: 9%
Is there a change in the buffering settings or why is VIP using 40% more memory? It takes 70% more time to load that 40% more so obviously VIP would also slower in loading the same amount of data. The CPU usage measurement is certainly very unscientific but still it's four times the load VI has. That's not good considering the amount of instances we need.
Could somebody try this out? My setup is Q6600, P5B-VM, 8 gigs, Vista 64.
Hello,
VIPro has a larger base memory size and CPU usage per instance, than VI. For example, VIpro has a default polyphony of 128 voices, compared to 64 voices of VI, and thus will take more memory just for the buffers. Also VIPro contains multiple outputs, all of which need some post-processing.
However the increase in CPU usage with the amount of actually played notes should be approximately the same for VI and VIPro. Thus, the greater idle CPU usage should not really mean a proportional scale in CPU usage when the instruments are actually playing.
As for initial startup loading time, probably there is some room for optimization there. VIPro is different from VI in the fact, that VI will hog the complete system to obtain the resources to load the data, while VIPro is doing this in background.
Thanks,
George.
Ok. Thanks for the info. At the moment I can't even think of a reason why I would need 128 voices or multiple outputs but if some people do then could it be possible to get a slimmer version of the VIP or user definable performance options? All I want is to add the humanizing options, polyphonic legato and background loading to my current setup so that it takes more CPU for those instances that actually do more. Now I'm getting all sorts of unnecessary bells and whistles with a severe performance degradation. I understand that more features means need for more resources but do they all have to be active all the time? It's my fault that I didn't check but I took it for granted that the VIP would replace the VI as the basic workhorse plugin and just add more options but now it seems to be a luxury item that I can only afford to use every now and then.@gyohng said:
VIPro has a larger base memory size and CPU usage per instance, than VI. For example, VIpro has a default polyphony of 128 voices, compared to 64 voices of VI, and thus will take more memory just for the buffers. Also VIPro contains multiple outputs, all of which need some post-processing.
I agree with info_9427. I shelled out for VI Pro immediately, essentially because of background loading and the humanization feature. However I don't need so much polyphony and so many outputs. It would be nice to be able to make these into options.
On my setup, switching polyphony from 128 to 16 on single open instance of VI Pro didn't have any visible influence on idle CPU usage.
Just my 2c.
Exactly. It doesn't make much sense to me to make the VIP better than VI in some cases. It should be better. Period. It should be lighter or at least similar to the VI when loading VI programs and then offer all the power in the world when needed with modularily rising resource requirements. Kontakt can do that, why can't VIP?
