VEP 7 has been extremely unpredictable and inconsistent, temperamental, or the system is temperamental with it. Yesterday learning automation from BFD3 would beach ball o' doom each time. Today not at all.
I experienced slowness in other ways and then didn't. All very stable and responsive today.
-
-
Same issue here.
I rolled back to VE Pro 6 for the time beign
Ve Pro 7 with Cubase combo was just impossible to work with. Cubase would take an hour and a half to load up and would take an hour every time I was exporting a mixdown...... well its back to normal with Ve Pro 6 now. Hope they can figure it out soon
Sounds like coupled behavior on crack. I run decoupled with Nuendo, I don't see that at all. The load of VEP 7 has definitely been snappier here. Systems differ widely.
-
There are already two updates - less than a week after the initial release.
Anyway I notice a slight increase in idle cpu compared to last version of VE6 but absolutely no other issues - this is on a project inovlving 77 channels/VIs, and 900 articulation sets within all custom matrices, MIR pro on every channel. Works exactly like VE6 except with all the new features. So this is one system not experiencing any of the issues reported here.
Though - this is the standalone version - a single VE running 4 MIDI ports on a 12 core Xeon Windows 10 slave wth 64GB ram.
-
Based on these reports, I did another comparison of CPU usage between VEP6 and VEP7 on Mac. Here is an excerpt of my findings:
- 100 instances of Vienna Instruments Pro, Staccato String patch
- Logic project playing back 2 bars of random notes
- VEPro instance uses narrow channels in mixer, regular channels in channel pane.
- VEPro window maximized on 3840x2160 monitor (full resolution, no Retina tested)
Observed average process CPU values during playback and (idle):
VEP6 Maximized: 136% (37%)
VEP7 Maximized: 100% (31%)
VEP6 Minimized: 37% (29%)
VEP7 Minimized: 30% (22%)An Instruments run of both version also confirms the above findings. VEP7 also feels more responsive during playback compared to VEP6.
-
I had the same good results using VE7 that MS mentioned from my latest project - a MIR mix of my Romantic Symphony. It uses 923 separate articulations on 80 custom matrices performing very smoothly and loading quickly the following instrumentation:
8 Flutes
5 Oboes
4 Clarinets
4 Bassoons
Contra Bassoon
2 C trumpets
B flat Trumpet
Cornet
2 Flugelhorns
8 horn ensemble dividied accurately into 2 or 4 divisi parts using a combination of 2 - 4 horn ensembles or 4 solo horn/Dimension horn combinations
4 Trombones
Bass Trombone
Tuba
Vienna Konzerthaus Organ
Timpani
Percussion ensemble
5 gongs
cymbals and anvil
glockenspiel
2 sets chimes
Harp
Appassionata Violins
Orchestral Violins
Chamber Violins
Solo Violin 1 & 2
8 Dimension Violins divided into 1 & 2
Appassionata Violas
5 Dimension Violoas,
Solo Viola
Appassionata Cellos
Solo
Cello 2
6 Dimension Cellos
Orchestral Basses
Chamber Basses
4 Dimension Basses
-
Well that is very frustrating. Because VEP7 uses 10-20% more cpu when the window is active for me here. I have reverted to VEP6 and run exact same project and VEP6 is using less CPU. Both VEP6 and VEP7 use a significant amount of additional CPU when the VEP window is open vs when its minimized. Personally I think that is concerni as well. Its even worse with a retina display. VEP7 is just a little worse then VEP6, those are MY results. I spent an entire afternoon running a precise test that would gather the results in a repeatable and exact way to be sure and I shared the test case with VSL. I can observe the additonial CPU usage as a percentage in the activity monitor and I have observe it in the loadavg value. they are correlated values.
If their answer is that their results are opposite of mine, I don't knwo what to say other then we have opposite results and that is frsutrating because my results are what they are.
I will not be able to run any more tests because the past few days I wasted of time with VEP7 and I am now reverted to VEP6 and will not try VEP7 again until at least a month goes by and poblems are more resolved.
regards
-
does the slave machine have a window showing the GUI? Is it a mac? If its a mac and you have a screen, then run the test with VEP window open and closed, watch the CPU when you have the VEP window open for a bit and closed for a bit. I think its probably a mac issue as well. I have found that the problem is worse when I have my monitor in retina mode as well.
-
You guys got me to do more work....
Here is the test I ran and the results....
The test was performed by using a tutorial score from VSL website, specfically the E.T. Score, but you can perform the the test at home with any project you like. I basically ran the following command during the same 3 minutes of playback for the score I chose.
[code]iostat -w 3 -I -c 60 | awk '$1 !~ /^disk/ && $1 !~ /^KB/ { print $10 }'[/code]
That looks at average user CPU% every 3 seconds and spits out 60 samples over a 3 minute period.
So what are the results? You can see a more complete collection of the data here:
https://drive.google.com/file/d/1H40bkgaJ0F7VDcjhQvZlUEqCARCVLb_b/view?usp=sharing
But to summarize as average CPU% over 3mins period:
Vep6 minimized Retina display: 38.82%
Vep6 Minimized Non-Retina: 38.12%
Vep6 Active Retina Display: 51.62%
Vep6 Active non-Retina: 49.37%
Vep7 Minimized Retina: 39.12%
Vep7 Minimized Non-Retina: 38.10%
Vep7 Active Retina: 57.93%
Vep7 Active Non-Retina: 47.93%
Summary
- The VEP gui on both VEP6 and VEP7 takes significant CPU overhead for whatever its doing when its not minimized.
- With the VEP gui minimized, VEP6 is slightly more efficient then VEP7 but by less then 0.5%, which is statistically irrelevant.
- With the gui Active in non-Retina mode, VEP7 is slightly more efficient then VEP6 by a factor of 1.5% difference, which is also somewhat insignificant.
- With gui active in Retina/HiDPi mode, VEP7 is less efficient then VEP6 by a factor of 6%, which is somewhat significant.
Overall I think the fact that VEP needs 10-20% of CPU just to display the GUI is concerning, apparantly this was the case on VEP6 as well. VEP7 appears to be slightly more efficient in the GUI in non-retina, but signficantly worse with Retina display. The above is on my system, which is MacPro 5,1 12x3.33 ghz cores, 128GB ram. Metal-capable display adapter. Nothing else running during the tests.
-
ps - I ran tests with Cubase earlier, but don't have the exact results now, but in general I say that Cubase performs much much worse then LogicPro, which is what I used for the above. Add 20-30% CPU for each of the results above, as far as what to expect from cubase, which I often saw peaking at 95% cpu utilization with the VEP gui showing. the test above also did not have any cpu heavy plugins. All just ViPro instruments and VSL instrument playback, MIRPro and one instance of Miracle. Projects with synths and more FX processing I would expect to be worse.
-
Same issue here.
I rolled back to VE Pro 6 for the time beign
Ve Pro 7 with Cubase combo was just impossible to work with. Cubase would take an hour and a half to load up and would take an hour every time I was exporting a mixdown...... well its back to normal with Ve Pro 6 now. Hope they can figure it out soon
Sounds like coupled behavior on crack. I run decoupled with Nuendo, I don't see that at all. The load of VEP 7 has definitely been snappier here. Systems differ widely.
Yeah I run the VE Pro decoupled as well. It might also be network or cpu related, ve pro 7 hangs every time cubase tries to "change the condition" for exaple connecting to the server, starting mixdown, closing the session.
-
First of all, let me reassure you that we take any reports about CPU usage seriously, since we want VEPro to be as efficient as possible.
A busy GUI code, updating meters, peak displays, MIDI activity and other things, will always use some CPU power. The cost for updating such things tend to be a bit higher on MacOS than on Windows, due to blitting being a more expensive operation on MacOS. I don't find the CPU usage of VEPro as such to be in any way abnormal for the amount of work that is done.
In order to shed some further light on this topic, I created a performance comparison project, trying to isolate the impact of GUI updates on project performance. The results from this test, and the 16 possible test permutations, can be found in the linked PDF.
If anyone wishes to look further into the measurement data, or reproduce these findings - I am also enclosing the project files
Test Results (PDF)
Raw data and project files (ZIP)Thanks,
Martin
-
Try some larger hidpi settings. My system is performing much worse in hidpi mode non minimized, and vep7 is worse then vep6 in this regard by 6%. My tests were using my normal working resolution of 3200x1800 hidpi. You will need a 4K monitor and decent video card. The fact that vep needs 15% of cpu over and above all the internal mixing engine to display meters and articulations on a Mac is disappointing. I hope vsl will look closer at that in years to come.
-
Try some larger hidpi settings. My system is performing much worse in hidpi mode non minimized, and vep7 is worse then vep6 in this regard by 6%. My tests were using my normal working resolution of 3200x1800 hidpi. You will need a 4K monitor and decent video card.
The fact that vep needs 15% of cpu over and above all the internal mixing engine to display meters and articulations on a Mac is disappointing. I hope vsl will look closer at that in years to come.As I wrote in the PDF, I was using an AMD RX570 GPU and a 3840x2160 display for my tests. In HiDPI/Retina mode, this is called 1920x1080 HiDPI. I am not aware of a display that handles 3200x1800 HiDPI, which would be a native resolution of 6400x3600 pixels. Perhaps you mean 1600x900 HiDPI?
As I also wrote before, an application will always require processing power to perform updates of dynamic information on the screen. The more that's updating, the more processing power is required. I believe that VEPro is actually pretty efficient regarding this, many applications perform much worse when continuously updating so many things. We are slightly bound by the limits set by the GUI framework we're using here (Qt), but so are most other applications as well, except for Logic.
-
No you can run 4K monitor at larger hidpi settings then 1920. Mine is at 3200x1800 hidpi and looks great, but slow on vep7
Please be aware that scaling will occur at any resolution which is not 1:1 or 1:2. I have not tested anything at these scaled resolutions, since I really don't recommend using them, but I would believe that it performs worse.