Description:

When there are numerous CC messages that occur at the same or similar times, VE Pro is missing some of them.

How to recreate (REVISED 8/5/2012):
1)Open VE Pro Server
2)Create an instance
3)Create 4 Kontakt VSTi's (I've used Kontakt 3.5 and Kontakt 5) with each one on a different port
4)Load 16 blank instruments into each Kontakt instance (one per channel)
5)In a sequencer (I used Cubase 5.5.2), copy and paste a midi part that defines CC1 onto a track for each instrument (4 ports x 16 instruments)

6)Enable the midi monitor script on one of the first instruments (click the wrench icon, then script editor, then Preset->Factory->Utilities->Midi Monitor)

7)Enable the midi monitor script on one of the last instruments (e.g., port 4 channel 16)

8)Play the part in the sequencer
9)The early channels will receive the CC1 message, but the later ones will not. Upon further analysis, approximately the first 40 instruments will receive the CC1 message, but the others won't.


Fortunately, this problem only occurs when you have around 40 simultaneous CC messages, which is rare. However, it is a problem because in my projects, I initialize all tracks with copied and pasted CC messages, which means not all the parts are getting initialized with VE Pro. Also, for sequencers that backtrack to the previous CC setting (e.g. midi chase in Cubase), they send numerous simultaneous CC messages, which means these chase feastures won't work with a large VE Pro template.

Workaround:

Breakup a large template in a single instance into multiple instances. The limit on simultaneous CC's appears related to individual instances, not to the entire server. However, this of course requires additional audio channels, and is less efficient. This still doesn't work perfectly because I am still getting lost messages, but it is much less.

Can someone please confirm this bug? I have tested it quite thoroughly on 2 different machines, so I'm hoping it can get fixed.

SOLUTION UPDATE: For others with this problem, the solution is to use Cubase 6.5 instead of 5.5.

This sounds like a different problem. My CPU usage on these tests is around 4% and CC data is being lost. In some cases, it is losing sustain pedal messages when they occur close to other CC changes. I'm ok with imperfection, but this makes it nearly impossible to work. I have to play things back and hope nothing important is lost.

I reported the problem. I hate to speculate, but is it possible there is a buffer that overflows when receiving too much midi data in a short time? If the data isn't showing up in Kontakt, that suggests it is being lost between Cubase and Kontak (i.e. Ve Pro). I initially thought it was Cubase, but if I load Kontakt directly, there are no lost messages.

Also, I have tried all buffer sizes in addition to various combinations of midi ports and audio ports amounts. Thanks for the help.

 If anyone else wants to test it, here are some project files:

(removed)

Here are the instructions I sent to support:

"I attached a Cubase project with identical clips on 16 tracks across 4 different ports (you might want to check that the channel and port setting were preserved). Each clip sets 4 different CCs at the same time. There is one VST3 VE Pro instance in the project that will likely be disconnected. Next, create an instance on the VE Pro Server and load 4 Kontakt instances across 4 ports. Load the attached Kontakt multi (monitor.nkm) in each Kontakt instance, which contains 16 empty instruments with the midi monitor script enabled. Connect the instance in Cubase and everything should be ready to go.

In each instrument in Kontakt, you can monitor the received CC messages as described in the thread (I suggest enabling verbose mode so you can see the entire log). If you check the instruments on the first two ports, they will receive all the messages. If you check the instruments on the last port, they will not receive the messages. On VE Pro 5, I received the messages on the first 2 ports, but not the last 2. On VE Pro 4, I received the messages on some of the instruments on port 3, but not port 4."