Yes, we plan to port all software. Unfortunately I cannot disclose any timelines. As any other developer, we have a bunch of 3rd parties that we also depend on, making it difficult to do any predictions.

Considering that it will most likely be quite some time before Apple introduces silicon powerful enough to replace the Mac Pro line, you'll most likely see developers keeping support for Intel CPU's up until at least 5 years after the last Intel Mac Pro is shipped.

My guess is that Apple will keep selling Intel Mac Pro's for another 3 years, so something like 8 years of Intel support would be expected from devs. Not sure how long Apple want to keep supporting Intel in macOS however, but I doubt they'll kill support for the last Mac Pro's that quickly.

Also remember, that developers will still have to develop x86_64 code in order to support Windows. Given this, supporting Intel alongside ARM isn't too much of an issue.

We haven't done any specific research on settings within Cisco routers. If the settings work well for other low-latency high-bandwidth applications, it should also work well for VEPro.

Alt-Tab?

How many instances of Kontakt are you using?

Is the situation different when hosting Kontakt in another host?

Can you load multiple Kontakt instances inside of Kontakt Standalone?

To my knowledge, Kontakt does not share sample memory between instances. Synchron Player and Vienna Instruments do.

Hi,

please tell us your:
- System specifications
- OS version
- Versions of the installed plug-ins that fail validation

Hi,

first of all, I suppose you have tried revalidating the plug-ins in VEPro preferences?

Could you please give:
- exact OS version
- system specifications
- Which plug-ins and versions of these plug-ins that fail validation

I cannot reproduce these findings. VEP7 does not leak anything here when enabling/disabling channels or inserting/removing plug-ins.

Could you please tell me exactly how to reproduce this, and what tools you are using to observe memory allocations by the VEP7 process?

Also, if you do observe a memory leak when using Kontakt in VEP7, it would be great if you could verify the behavior with Kontakt inside of another host - if it behaves the same way, it is an issue with Kontakt, and not the host.

Hi,

when pressing the pedal on a grand piano, there is no added resistance for the key to push up the damper pin, resulting in more velocity for the hammer, causing a louder sound.

The VSL pianos aim to preserve every nuance and characteristic of the sampled pianos, and will therefore behave exactly like their acoustic counterparts for a given strike velocity.

May I ask, does this issue only occur once after starting the player, or does it occur over and over again while playing?

How many voices are approximately used when the peak occurs?

Thanks,

Hi Brett,

first of all - ensure to close down the Standalone and delete your Synchron Player Standalone preferences file:
%APPDATA%\VSL\Vienna Synchron Player Standalone.ini

This will ensure that we're starting from a fresh situation.

Then, select the RME driver only, choosing your preferred samplerate and latency. Please note that using a samplerate other than 44.1kHz will just cause a higher CPU usage and worse sound, since everything has to run through a samplerate converter.

Switching samplerates with the RME driver should be possible from the preferences window, without any strange artifacts as you have reported.

Regarding ASIO4ALL, I have tested this driver together with RME Fireface UCX, and I cannot make it work at all when switching between samplerates, regardless if I'm doing so in a VSL product or simply just in Cubase or Nuendo. I would not recommend anyone using this driver, if you already have a proper soundcard with a proper ASIO driver. 

Measuring speeds with a fusion drive is not so easy. The drive will most likely have everything cached in the SSD part, and will thus measure as an SSD. When reading more data randomly, from several libraries, it will perform a lot worse than a proper SSD.

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.

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!

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.

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