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.

When running into this issue again, please create a minidump from Vienna Ensemble Pro.exe using Process Explorer. Then please send the minidump to

https://technet.microsoft.com/en-us/sysinternals/processexplorer.aspx

(replace conhost.exe with Vienna Ensemble Pro.exe)

Originally Posted by: Daniel Stenning

Is it not possible to just add the for an "alias" name that us users can optionally just set ourselves?

I think that could be reasonable. I'm just wondering how many would actually use such a feature?

I've tried to make the presented parameter name as short as possible, while still keeping all information required to identify which plugin/parameter it controls.

If you have any ideas on how to improve this, I'd be happy to hear it!

The latest release of VEP should take care of this.

Thanks.

Hi,

thanks for your input on this matter. I believe you are referring to this Juce forum thread?

First of all, VEP is not written in JUCE. However, the issue you describe is very similar to what we're seeing - and the workaround that I have already implemented is just that - a delay (of 500ms) for loading projects upon startup. Perhaps this delay would need to be longer on other systems? Do you recall what delay value you ended up with?

In any case, this is really a bug with Kontakt itself - I think related to the modal dialog it pops when doing loading. We have contacted NI several times about this issue, but have yet to receive a reply.

Thanks,

Martin

Originally Posted by: cgernaey

I changed the Preload Size to 32768.  Right beside that, it tells me that the speed to both paths is around 250MB's.

What kind of drives are these? Usually NVMe drives should show a faster speed than this. Could you run a benchmark using https://www.atto.com/disk-benchmark/ - and paste your results?

Originally Posted by: cgernaey

I am confused at to why when I load Sychron Strings, every section is "sharing" the total voice count?  I can be sitting at the interface for Basses while Violins are playing and it shows me their current voice count usage?

So when you have each section, using all the microphone settings on a super fast NVME drive, because I hit the max voice count (using Vel X-Fade) I get dropouts long before the drive and CPU is saturated.

 

How do you get around this and actually use these strings with all microphones and velocity X-Fade?  What am I missing?  Is this just an illusion?

1. The voices displayed in the interface show the total number of voices used for all Synchron Player instances
2. The "Voice limit" setting on the "Perform" page is applied per instance.
3. You cannot deactivate streaming. You can only raise the streaming buffer up to 32768 samples, which should be plenty - unless you have some severe configuration issues with your drive(s).
4. Using ALL microphones and velocity x-fade is tremendously taxing on the system. If you really want this, you need to raise the instance voice limit.

This is unfortunately not possible. Individual plug-ins allocate memory from the system directly, and we don't know anything about it.

We cannot reproduce this here. Any chance you could make a screen capture video explaining what you are experiencing?

Originally Posted by: Thurisaz

Last night I've sent crash dump files to the Support e-mail. You can check them. :-)

Could you tell me the case number please?

Originally Posted by: Dewdman42

Just wanted to follow up to this.  After upgrading my system from Sierra to Mojave, performance with VEP7 is not only just as good as VEP6, its significantly better.  All the problems I mentioned above went away when I upgraded my Mac to Mojave.  

To clarify - the higher performance in Mojave will come with the next update of Vepro 7.

Kontakt doesn't share any memory between instances AFAIK, so the memory meter you see inside of Kontakt displays how much RAM is used for sample preload by that instance alone.

VSL's instruments can share preload memory between instances; thus, loading up a second instance with the same instruments will only add a tiny bit of overhead. The memory meter inside VSL instruments therefore display the total preload size used by that specific instrument, for the entire process.