Vienna Symphonic Library Forum
Forum Statistics

182,023 users have contributed to 42,199 threads and 254,649 posts.

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

  1. Home
  2. Software
  3. Vienna Instruments Pro
  4. Idle VEP CPU usage

  • Idle VEP CPU usage

    T
    T

    Hello,

    VEP Pro 64-bit server with a couple VI Pro instruments loaded, on a clean install of Snow Leopard 10.6.4, running alongside Logic 9.1.1 (64-bit), is consuming 80% CPU when idling (i.e. sequencer stopped). There is no disk activity so this is not a RAM problem. Granted, it's a very basic Mac (iMac C2D with 4gb RAM), but well within the minimum requirements I believe.

    I'm aware that running Logic in 64-bit is pretty pointless with a 4gb machine. But I'm curious :)

    I would like to know if and why this is normal behavior.

    Thanks.
  • I
    I

    I have Core 2 Quad running Vienna Instruments but one instance of VE PRO is using only one core so my VE PRO gets about the same amount of power as yours. I can't use VI PRO to replace VI at the moment because the CPU usage is high. It's nowhere near 80% with just a couple of instances though.
  • T
    T

    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.
  • T
    T

    And another side-note about something I found when trying to check difference between 32 & 64-bit projects: Kipling fans should definitely open their viframe files with a text editor... 
  • PaulP
    VSL Team
    PaulP

    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

    Paul Kopf Product Manager VSL
  • T
    T

    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.
  • K
    K

    There's more difference between the filetypes. Say when you save a viframe32 that uses an AU only available in 32bit. You won't be able to open this in 64bit VE Pro (or well, you will be able, but the 32bit AU will not be loaded in the project).
  • I
    I

    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.
  • PaulP
    VSL Team
    PaulP

    Hi,

    did you activate the reverb in the VI PRO instances?

    Best,

    Paul

    Paul Kopf Product Manager VSL
  • I
    I

    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
    I

    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.
  • G
    G

    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.
  • I
    I
    last edited
    last edited

    @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.
    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.
  • H
    H

     You can set for each VI PRO instance the voice limit  also to a much lower amount than the old VI offered (64), especially for dedictaed instances which absolutely don't need high voice counts.

    best

    Herb
  • T
    T

    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.
  • I
    I

    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?
  • N
    N
    Glad to find out from this thread that the Kipling poem in my project files is just something that VSL programmers put there. This morning, I've been searching my entire hard drive for evidence of any virus putting that into files randomly, checking the registry and searching my hard drive for an infamous worm that's known to use the same text, and getting ready for a whole lot of time searching for malware to solve that mystery.

    Nice to know that you folks have a sense of humor. :)

    Please, in future versions, consider not scaring us users like that. (This all got started because someone couldn't open my project file and thought there was something wrong with it, but that's probably because he has a Mac and I have Windows.) From a user standpoint, it would have been much nicer if it had said "Rudyard Kipling, courtesy of the VSL team." Also, how about a shorter quote?

    You have a great product though, and I appreciate all the support through the forums. I'm also I'm happy and relieved that it's not there because of some sort of malware.