194,184 users have contributed to 42,912 threads and 257,928 posts.
In the past 24 hours, we have 1 new thread(s), 13 new post(s) and 88 new user(s).
I have an update: it seems that this issue occurs most often when soloing one track only.
If I open the key editor for one single track and solo it, then dropouts occur, but if I un-solo it, no longer dropouts occur, at least in this simple test I am doing today
I haven't seen that behavior specifically on my system. for me it happens to my entire song and all instruments in the song. Once it happens to one, the entire song is rendered useless and a complete reboot and reload is required. No amount of unmuting, unsoloing or any other measure resets it and makes them start working again for me. This is true within VE Pro 7, Cubase 10.5, Nuendo 10 and Studio One v4.6.1 and v4.6.2 on Windows 10 Pro.
The search continues. Hopefully we get to a resolution on this as I am weeks behind and losing motivation and steam on my current projects.
Christopher
The plot thickens.
I performed the update yesterday and the results are still the same. Dropped voices. However, now it comes witha new issue. All of my Miracle instances are randomly ignoring their proper decay times. For instance, I have a 9 second length on my Flute, it now plays a length of about 1 second. My Solo Cello is now playing for 9 seconds, with a length parameter of 2 seconds.
I hit the little "power off button" on the plugin, hit the "power on" the plugin again and it works as expected.
I reboot or simply restart the song. It does it all over again.
Christopher
Here’s a hint at what this problem might be. This discussion requires that the plugin is VST3 and is created using JUCE tool set. My understanding is that VSL uses JUCE. If that is no longer true, then please disregard this post. The VST3 assumption applies to VE Pro or individual plugins. Using the VST2 version of VE Pro or the individual plugin instead of the VST3 version will eliminate the problem I am describing.
My mental model of the problem is that there is a protocol mismatch in the interface between the host (e.g., Cubase, Dorico, etc.) and the plugin (e.g., VST3 version of VE Pro, Synchron Player, VI Pro, Pianoteq etc.). The host assumes a single-stream serial MIDI protocol, and the plugin assumes a multi-stream timestamped MIDI protocol. If two or more MIDI events occur with the same timestamp then (depending on what those events are) they might get reordered in the plugin. I’ve seen this issue using Dorico and Pianoteq and using Dorico and VE Pro.
In one example, an All Notes Off event occurred at the same timestamp as a Note On event. They were ordered serially from the host as All Notes Off followed by the Note On. But the plugin reordered these as Note On, followed by All Notes Off. So notes were cut short. This sounds exactly like what is occurring for some users in this thread.
In another example, before Dorico introduced the notion of negative time in its MIDI stream, a condition occurred if you specified an articulation different from the default on the first note of a score and the plugin was using the VST3 version of VE Pro. In this case, a Key-switch Articulation event occurred at the same timestamp as the Note On event. Sometimes the correct articulation was respected. But not always. In every case, the subsequent notes respected the articulation event. So the plugin was causing those events to be re-ordered some of the time. It was repeatable that it occurred, but not repeatable every time. So it was as if a race condition determined which event happened first. Once negative time was introduced then the articulation events moved forward enough in time to ensure the correct ordering.
Both examples above did not fail in a consistent way. They only failed some of the time, but often enough to be noticeable.
I am sure there are other examples where the ordering can cause issues. Particularly because the Synchron Player requires events to be in the correct order for articulation selection in the tree structure. So if your tree structure is using key-switches for some branch and CCs for another, for example, then I suspect this will cause issues. I don’t currently use this plugin for anything, so I haven’t experienced this first hand, but suspect this is possibly a problem.
So here is something while working with the VSL team that was suggested to me and at least seems to temporarily make them go away until it starts happening again. At least I don't have to reboot or close my song and restart again.
When the problem arises, open one of your existing instances of the Synchron Player and go to the Gear icon in the top right corner. Click on the Engine Tab. For the setting of "Streaming Threads" change your number to something other than what it is now. Mine was set to 4. I changed it to 6. I then closed it. Open it again and change it back to your original setting. I changed mine back to 4.
After doing that, the song worked again without having to reboot. Took me like 10-15 seconds total.
I am still working with the VSL Team as needed and they were finally able to reproduce it on their end after doing a teamviewer with me.
Be curious if this helps others in this thread have to not reboot while VSL solves this issue.
Christopher
Hi everyone,
So after a a long session of debugging this issue we are confident to found and fixed this issue.
The more CPU cores you have, the faster the issue could appear.
We would be glad if you could test our current beta build if this solves this issue.
Please PM me, or send a mail to support@vsl.co.at addressed to me and I will send you this beta-build.
Many thanks for all your help, this was a really tricky one, but your information helped us pin this one down!
Best, Ben
Hi everyone,
Thanks to your help we were able to identlfy and fix this issue. The update is now available, so all of you with beta build can now safely update to the latest version.
You can read the changelog here: https://www.vsl.info/manuals/changelogs/synchron-player
Please also update your Synchron Piano Player - it had the same issue.
Here a short technical explanation for what was going wrong:
The sample streaming module could go out of sync if too many CPU cores communicated with it at the same time. Once it was out of sync only a restart of the streaming module would temporarly fix the issue.
For this reason it was unlikely to see this issue with a 4 cores CPU, and even rarely with a 6 core CPU, which made it hard for us to track down this issue.
Best, Ben
