1. The VEPro CPU meter measures real-time thread use only. If you are running at a buiffer size of 256 samples, and samplerate of 44100 Hz, every buffer has to be processed within 5.8ms. If VEPro manages to process that buffer within 0.58ms, the real-time CPU usage would be 10%.

2. Plug-ins may spawn threads that process things in the background. This will affect the process/system CPU load, but may not show up in the real-time CPU meter. There is no way for VEPro to know about these background threads.

I have sent you a PM, I hope we can resolve this together. I'm very curious to find out what is causing this issue on your machine.

What I could think of, is if you have mistakenly added your root drive path for VST plugins. This would cause scanning to take a very long time. To reset plugin paths (and other settings), you can delete your VEP preferences file, and then start VEP again:

C:\Users\YOURUSERNAME\AppData\Roaming\VSL\Vienna Ensemble Pro.ini

Could you tell me which plugins take so long to be scanned? The names of the scanned plugins should be showing.

I have managed to reproduce the issue and have isolated it to a part internal to DP. I've notified the DP developers about this, and hopefully it will be corrected soon!

How many MIDI ports have you got in the VEP plugin settings? Is the issue improved with a single MIDI port?

You may select the microphone positions to download in the Download Manager.

Originally Posted by: iainkelso

Opening MIR is causing a bluescreen/restart.

This usually indicates a hardware / BIOS / driver error. My guess is that the AVX-512 code used in MIR triggers it - Intel has had several issues related to this lately.

To be able to tell more, please provide a minidump from the BSOD event.

https://answers.microsoft.com/en-us/windows/forum/windows_10-update/bsod-finding-and-fixing-them/1939df35-283f-4830-a4dd-e95ee5d8669d

Thanks,

Hi,

we just released an update addressing this issue today. Just go ahead and download the new version from MyVSL.

we had some network related issues under Windows with the batch of releases made earlier today. We have just uploaded new builds to replace them - so ensure to update all software you installed this morning, before trying again.

We had some issues with the first set of updates from today, but just put all new builds online of all software. Please ensure to install the latest builds of all software, and you should be good!

Originally Posted by: Del Gibbons

1) if I try and run Cubase PRO 10.5 first, before I run Vienna Ensemble Pro Server, I get an eLicenser crash. Not a big problem but sometimes when I'm in Cubase I want to start a new MIR project, would be nice to be able to run the server even when Cubase is loaded instead of closing Cubase, running server, going back into Cubase. I could do that before!

Please install the latest eLicenser version from www.elicenser.net - it sound like you have a version installed which was pulled after release. This version could cause the exact behavior you are experiencing.

Originally Posted by: Del Gibbons

2) Moving the window of a plugin loaded into MIR PRO (and this seems to primarily affect KONTAKT) from one screen to another monitor by dragging it onto one of my other 2 screens causes Ensemble PRO 7 to crash completely with an unrecoverable error almost every time.

This should be fixed with v7.0.1048 - released a couple of minutes ago. 

Please update to v 7.0.1048, this addresses this problem.

Sorry for the inconvenience.

Vienna Ensemble Pro 7 network discovery relies on standard Bonjour service.

Please ensure that you don't have anything blocking this service - or have manually turned the Bonjour services off on your master/slave computers.

With version 1048, released today, you should see a considerable improvement in this load with many active Aux channels.

Originally Posted by: dane

Just another question, I'm getting maximal 156mb/s reading speeds within the player (latest update), but I'm running libraries from a RAID0 3x SSDs via Thunderbolt 2 connected to Mac Pro 2013. Usually reading speed goes over 1000mb/s with blackmagic's disk test. I've also tried on another NVME SSD disk via USB3 and I always get max around 150mb/s.

The built-in disk speed testing uses a single-thread random access pattern at 64kB and 4kB block sizes. This will produce a speed FAR lower than a sequential disk speed test will do, but is more accurate in determining the drive's capability for sample streaming.

I'm using an Optane drive for sample streaming myself, which will give ~1000MB/s for 64k block sizes. This is pretty much as fast as you can get.

Originally Posted by: adriaantaylor

Seems to be crashing the server each time i try and add it. 

AU seems to be fine but VST instant crash

I have also emailed support:  Anyone else with the same issue?

We've just released an update (7.0.973) that addresses this issue.

We've identified a regression in the external midi port handling with the latest VEPro, which was introduced when fixing another issue.

We've just patched this up, and will release an update ASAP. 

Originally Posted by: Isaihsan

I've tested this with 2 different drives, the original that came with the mac and an xgp 8200pro, and both are read by VSL at between 17-20% of how fast the drives test in Blackmagic speed test: the original mac tests at 700mb/s and vsl reads it at 135; the adata tests at over 1400 and vsl reads it at 250. I know external drives are preffered for samples, but I'm limited to usb 3.0 since the tb2 ports have virtually no ssd support, esp. no nvme enclosures.

The Synchron Player will test what is relevant for sample streaming - and that is random reads at small block sizes. Sequential performance, as measured by BlackMagic, is irrelevant for determining the proper precache size.

If a disk measures more than 600MB/s on random reads with 64k block size, the disk will also be tested using 4k block random reads. If the disk measures over 100MB/s at this block size, operating system file caching and read-ahead is bypassed as well. This leads to even lower memory/CPU overhead and increased system responsiveness. Currently there are very few drives except the Intel Optane series that handle this kind of speed.

The Intel 905p Optane drive I'm using measures 1084MB/s on 64kb blocks and 179.9MB/s on 4k blocks.

Would you want to constrain to a specific max latency, or simply disabling any plugin that introduces latency? IIRC, Logic just turns off any latency plugin?

I think these are sensible requests. I'll put them on our wishlist!

I cannot seem to reproduce this - is there something specific required in the project to reproduce, or does it occur also from a fresh project?

This is something that would have to be done purely from the NI side - we have no influence over how KK operates.

Originally Posted by: rockstarjazzcat

I wish you luck on any changes made moving forward.  Suffice it to say, I imagine that in any DAW, uniting midi routing out the send with graceful return of audio into a single track is going to make loads of people happier.

Exactly this is what is close to impossible to achieve today, and getting more and more difficult to achieve as time goes by. DAWs have kept moving in the direction of each plug-in being processed in its own little time- and buffer world, and synchronizing between plug-in instances has become incredibly difficult. Some hosts even completely pre-process certain tracks way ahead of time.

Consider this possible scenario:
- One plugin for MIDI events
- One plugin for audio return

The audio return plugin is buffered, and processed 30 seconds ahead of time. The midi plug-in is selected for recording, and is processed in realtime.

Unfortunately it isn't as easy as setting a "port per plug-in", since each plug-in (and instance) may live within its own processing chain - different threads, different blocksizes. 

In fact, the "Event input" plug-in already does what you want, but it also comes with a whole array of  drawbacks when used in a host that handles playback and recording tracks differently.

EDIT: The event input plug-in doesn't allow filtering channels, only ports.