Strange VST3 Hosting Issue (Dorico 4 and 5)

Brian_Roland · May 27, 2023, 3:22pm

First I’d like to say congratulations on the Dorico 5 release! There is a lot of great things going on with this release!

So, with the impending doom of VST2, I’m slowly transitioning as much as I can to an all VST3 setup (at least as far as Dorico is concerned).

I’ve run into an issue that after a few bars Dorico seems to stop providing information that VST3 plugins can use to build smarter instruments (and some, like Groove Agent, or HALion’s ‘arp engines’ probably NEED to work properly).

Oddly enough, VST2 plugins I’ve tested are working fine in this respect.

To easily illustrate the issue…

I’m looking at two instances of Bidule 0.9784 (and I can snoop this info in similar ways with HALion, and other plugins). One is VST2, the other is VST3.

A ‘sync extractor’ bidule allows me to see/use various bits of information a host sends. The main ones of interest to me at present are:
Playing (1 if transport is going, 0 if stopped)
Tempo (can be used to make better articulation choices)
Bar count (fudge in style or various swaps for soli sections and more)
ASIO Sample count (use to trigger samples or even ‘track’ long audio files at very precise times).

In the VST2 instance of Bidule everything is as expected. The sample count scrolls as expected. The play pin shows a value of 1. Bars count. Etc. Everything works as expected throughout the duration of the entire score.

VST3? It’s a bit different. It’s good for 3 to 4 bars, then poof! No more data! The plugin thinks the transport has stopped!

First three bars it’s looking good…both instances identical:

Somewhere around bar 4…VST3 instance goes poof! It drops all the pins and goes to 0, or default values.

Note: If I run this same scenario in Cubase 12, both the VST2 and VST3 instances of Bidule work as expected. Transport, Tempo, Time Signature, Bar, Sample, Etc…all the pins are correct throughout the entire project.

Ulf · May 27, 2023, 3:31pm

Hi Brian, thanks for reporting this. Do you think it is the same as this case

Brian_Roland · May 27, 2023, 4:04pm

I don’t think so. Most VST3 plugins work great for me in their most basic configurations and usage scenarios. I’m having a look into some of the newer/deeper playback interpretation abilities of Dorico 5

I haven’t had any major trouble ‘getting sounds’ out of Dorico, ever.

I know for a long time Dorico didn’t even try to implement some of these portions of VST protocols. You’ve been gradually sneaking them in for various reasons, and I’m taking a closer look.

I do seem to remember that Dorico 3 did not send the transport, time signature, and tempo information to VST plugins at all! I could always get an ASIO sample count before though.

With Dorico 4, you provided a fix to get the Word Builder working for the East West Choir libraries. So somewhere around the first Dorico 4 release, Dorico informs VST3 plugins if the transport is playing. It seems like that might have always been working properly for VST2 plugins but I’ve forgotten now.

Now I notice that Dorico 5 is sending a lot more useful info to plugins!

In the case of bidule, it’s rock solid if I use a VST2 instance.

If I use a VST3 instance, it starts out working perfectly. Three or 4 bars in though, it acts like Dorico has simply ‘abandoned’ providing that information anymore. Even the ASIO sample count drops to ZERO.

See screen shots in my previous post. VST2 instance on left, VST3 instance on the right.
Sync Extractor Pins from left to right are (+ For things Dorico seems to be attempting to provide at this time):
+Playing
BPM (First tempo in score registers, but not subsequent changes)
Numerator (Time Signature)
Denominator (Time Signature)
Samples per ppq
ppQ position
Last Bar Started (works if constant 4/4 time signature?)
Trigger on bar start
Looping
Cycle Start Position
Cycle End Position
+ASIO Sample Pos

Bidule in a VST3 format is really new stuff, so I figured I should try it in some other hosts to see how that goes. Cubase 12…is keeping the VST3 version of Bidule perfectly informed all the way through a project. No loss of the ASIO Sample count…nor anything else. I think Cubase is providing info for pretty much ALL of those pins in proper fashion.

Ulf · May 27, 2023, 4:18pm

Hi Brian, you have mentioned several important points that are also relevant for the other issue in that other thread.
I almost think that - even though not the same - they are somehow related. Well, we will work on it and see…
Thank you for your long explanation.

Brian_Roland · May 27, 2023, 4:27pm

Thanks Ulf!

I’d merge this thread with the other but I’m not sure how. Feel free to have it moved if it’s better for you.

Brian_Roland · May 27, 2023, 4:47pm

Just a hunch…

The more of these information parameters you can get working, the less trouble you’ll have with various plugins rendering and exporting audio flows and such.

From time to time I run across plugins that do fine playing in real time, but bork out if I try an instant ‘audio export’ directly from Dorico.

A growing number of plugins use that info.

Now that you’re offering Groove Agent, a few users are likely to fiddle with some of those patterns and groove building macro engines. BPM, Time Signature, song position, etc. More host info is better, and quite a few things that seem to work fine when ‘playing’ the score could start going wonky really quick when instant rendering or ‘exporting an audio file flow’.

Brian_Roland · May 31, 2023, 5:13pm

Hotfix 5.0.10.2029 applied via Download assisant.
Rebooted Windows 10

VST3 bidule still loses ASIO sample count and playing stat after a few bars.

A new experiment to demonstrate that this particular program isn’t losing connections/data/whatever in Cubase as it does in Dorico.

VST2 and VST3 versions in Dorcio
TXL Timecode in Dorico sending MTC
Cubase synced to MTC
VST3 version running in Cubase

ASIO sample count should be identical in all instances.

Dorico VST2 is correct.

Dorico VST3 is correct for a few bars but stops and displays 0.

Dorico VST3 over in Cubase remains identical to VST2 version in Dorico.

In the screenshot the bidule instances left to right are:
Dorico VST2, Dorico VST3, Cubase VST3

No idea if it’s the plugin or the host.
Just documenting it here in case it’s helpful.

Ulf · May 31, 2023, 7:31pm

The 5.0.10 release did not address any of the known MIDI issues, but we are working on the next hotfix, so that at least the crash bug is gone.
The other issues we deal with immediately after that. So please be patient, a solution is not too far away.

Brian_Roland · June 15, 2023, 6:14pm

Not sure if it’ll be helpful, but over in this thread, seb@plogue says:
“It’s pretty much using/calculating from the ProcessContext the host sends on the process call.
That is unless Dorico sends that on a 0 sample process call and then calls the whatever samples process call but does not give it a ProcessContext, in that case some of the calculated fields would be stale/not recalculated.”

Ulf · September 25, 2023, 12:50pm

Hi @Brian_Roland ,
sorry it took some longer until I could start looking into this issue.
First of all, looking at the VST3 specifications I realized that the ProcessContext has many fields but nearly all of them are optional, i.e. a host application (like Dorico or Cubase) does not need to use or update the fields. Only sampleRate and projectTimeSamples need to be set and valid all the time, others only if in the ProcessContext’s state field the corresponding Valid flags are set. Those flags are defined as

		kPlaying          = 1 << 1,		///< currently playing
		kCycleActive      = 1 << 2,		///< cycle is active
		kRecording        = 1 << 3,		///< currently recording

		kSystemTimeValid  = 1 << 8,		///< systemTime contains valid information
		kContTimeValid    = 1 << 17,	///< continousTimeSamples contains valid information

		kProjectTimeMusicValid = 1 << 9,///< projectTimeMusic contains valid information
		kBarPositionValid = 1 << 11,	///< barPositionMusic contains valid information
		kCycleValid       = 1 << 12,	///< cycleStartMusic and barPositionMusic contain valid information

		kTempoValid       = 1 << 10,	///< tempo contains valid information
		kTimeSigValid     = 1 << 13,	///< timeSigNumerator and timeSigDenominator contain valid information
		kChordValid       = 1 << 18,	///< chord contains valid information

		kSmpteValid       = 1 << 14,	///< smpteOffset and frameRate contain valid information
		kClockValid       = 1 << 15		///< samplesToNextClock valid

When I run the audio engine in the debugger, then the state field is 0x2FF00 or 0010 1111 11111 0000 0000, and so ContTime, Clock, Smpte, TimeSignature, Cycle, BarPosition, Tempo, ProjectTimeMusic, SystemTime shall be valid fields and receive updates.
Now comes the question, why is it all correct for VST2 and not VST3? I can’t yet say exactly, but I think it has to do with the fact Dorico’s audio engine is internally only VST3. When loading VST2 plug-ins this goes all through our VST2PluginManager component, which translates and mediates between the 2 worlds. So the VST2PluginManager looks after every aspect that needs to get mediated and sets correctly the flags and fields.
And though Dorico’s audio engine is derived from Cubase, there is some middle software that needed to be written resp. rewritten. I guess some implementations where forgotten or consciously put on hold until later. I will dive deeper into the code now and see what I can find out.

Ulf · September 29, 2023, 2:42pm

Hi @Brian_Roland ,
there is light at the end of the tunnel, this is what I just wrote to Sebastien from Plogue.com:

" In Dorico we are setting too many flags as valid where in fact they are not valid and are basically rubbish. Bidule somehow realizes that and stops updating after a few seconds. That’s really clever of you. If I set kProjektTimeMusicalValid and kBarPositionValid to zero, I can at least fool Bidule in believing the other values are correct and so it appears to be working (continousTimeSamples and projectTimeSamples not stopping after a few seconds). But still there are also other things not quite correct, yet, e.g. we don’t set a proper time signature (other than 4/4) and barPositionMusic."

So you see, we now understand what and where is wrong and what needs to be done. We don’t have a fix version, yet, but we will work on it. (AD-836)