I have worked out a way to reproduce the Expression Map randomly changing the articulation bug every time.
Directions:
Create MIDI events with data on at least 6 tracks using VSTi’s with Expression Map changes. Preferably
using articulations that are easily discernible from the articulation in Slot 1 of the Expression Map.
Create a Tempo Track with at least one node.
Create a Signature Track. (optional)
Press play
Select all and duplicate.
Result:
Expression Maps for all tracks revert to the Slot 1 articulation and Cubase, from that moment, is unable to process any articulation changes.
This should demonstrate that when Cubase is busy processing a command that requires a lot of CPU resources, Expression Maps are not prioritised.
I was trying to create this and I had 1 occurrence while playback and 1 occurrence when stopping starting the project in different places, once when locating to position while playback. That was in about 10 min of trying… ( I have return to start on stop enabled. And I didn’t need a tempo track or the last step)
In some cases all instruments reverted to the top one, in other cases some didn’t. I will try with different vst later. (was using RealStrat).
Wow! That is a lot of issues. It really does look like it is a processing speed issue. From my specs you can see that I built a PC with enough processing power to do the task. But apparently not quite enough to overcome (entirely) this bug.
this uses Kontakt 6 and a Kontakt factory library patch Double Bass
twice in around 5 minutes of normal playback on loop provided examples of EM reverting to the uppermost expression during regular playback. (in my other test I had occurrences while starting playback OR while locating, too)
In this test I placed the ‘tremolo’ articulation on top so it is audible.
Expression maps are not busy, very regular programming.
It doesn’t seem to be a issue with a particular VST, but behavior with Realstrat on the start/stop occurrence seemed to be worse.
When reducing the number of tracks the issue seems to vanish.
On one test I let it run with me away from computer for around 15 minutes and nothing happened (no random change)
It seemed to occur more when I am at computer using mouse etc…
My midi controller is not powered on.
I have run Latmon to confirm I am not having latency spikes.
My thoughts is it’s not a computer spec issue but a limitation or perhaps a resolution (timing) issue.
ty
Ok. I tried it. First everything went without problems. But then I thought, what if my system is too fast for this and I built a modificated benchmark with lots of kontakt instances. The more kontakt instances I had, the quicker I ran into problems. I ended up with 120 instances, ymmv depending on buffer settings and system power. So at least in my case it is clearly system spec related. I don’t know if it is more of a RAM issue, or a CPU issue, or whatever. An easy way to trigger the faulty behavior if it doesn’t do it on it’s own is quickly stopping and starting by hitting the spacebar twice while the test is running.
Anyways, here is my project, if you want to try it with an easily scalable test project that is bigger than the one by J Buckingham, but very similar. Just duplicate the tracks (some tracks) if you have a very beefy system or delete some. Requierments: Kontakt w/ factory selection.
Another propably related thing I ran into, when testing some of my bigger projects: sometimes the articulation wouldn’t switch (because it already was on slot 1/default or no articualtion selected at all) but the sound would cut out for a moment on various tracks just to come in a moment later. Clearly something that isn’t happening when on Cubase 10.0. Tried it kinda side to side.
My system specs: Win 10 Pro, i9 9900k, 32GB RAM, NVMe system drive, Samples on external SSD connected via USB 3.1.
Gonna crosspost this to the other big thread, just so it doesn’t get lost.
