Dorico 3.5 no more Program Changes? (VEP vst3 issues in new update)

I just tested Dorico 3.0 and 3.5 with the same version of VEP 7.0.1048. It works in Dorico 3.0 but not 3.5. I am not a software engineer, however it does seem silly to me to have had it working in the previous version, but not this one. The change happened with Dorico, not VEP.

So dorico has changed. But it’s not necessarily a bug. The dorico team will have to respond about what changed. As I said the official VST3 spec dropped certain kinds of support for program change message handling. Some plugin makers found work arounds. There has been much discussion about this issue over ten years in the internet. Just search for vst3 and program change. It may be that dorico is now complying with vst3 in a more strict manner and causing vepro’s workaround to not work anymore. So the fix may still need to go to vsl. It really dorico and Vsl need to put their heads together and sort it out. My guess is Vsl needs a different work around. But hey only the dorico team can say what has changed in dorico that might cause this.

Vepro is an interesting case because program change messages need to be passed through to the plugins which are vst2, but the vst3 plugin for vepro doesn’t pass them through. It has to translate a bunch of vst3 abstractions back into pc messages before calling the vst2

huh, that is interesting. Well we’ll have to hear what the Steinberg developers have to say about the issue. I mean, you really can’t ignore the advantages for VEP with vs3. I “was” (Dorico 3.0) able to stick all of my Template into one instance of VEP which made setup, troubleshooting and configuration in Dorico a breeze! Add to that the limit of 64 (or something) VST plugins available in Dorico and it makes sense why we’d like to squeeze as much out of every port and channel as possible.

Its absolutely essential that VePro.vst3 be made to work with Dorico. This is the only way to have a large single VePro instance. I feel that most likely the solution will be a change to VePro, and I’m certain that the VSL developers will be keen to fix it if it can be identified exactly what has changed that they need to fix.

I am wondering whether PC message through VePro.vst3 has also been broken recently in Cubase. I will have to try that when I get a chance.

I’m at my computer now I can type a little better…I will just say a bit about Program Change and VST3.

In VST2, midi is sent from the host to the plugin as a simple generic midi buffer of events…all the events we know and love that match the midi protocol. Steinberg, in their infinite wisdom, decided that VST is not a midi protocol and it should not be using the midi protocol at all. To them it is an audio protocol and the only need for anything related to midi is to instruct VSTi instruments what to play. So they abstracted VST3 completely. Instead of having a simple buffer of mixed midi event types passed from the host to the VST plugin (like VST2), they only pass Note data to the plugin that way now. All other attributes have been abstracted into attributes that the host must know to use the VST3 api “properly” to set certain attributes. For example, Pitchbend is not passed to VST3 plugins as an event like it is too VST2. Instead the host sets a certain attribute by calling the VST3 api, whenever it detects pitch bend in its own track. Theoretically, nobody knows what each host is actually doing, but that is what they are supposed to do to be a proper VST3 citizen. Then inside the plugin, the plugin no longer will see a pitch bend midi event, it will simply look at the same VST3 attribute in order to know what to do related to pitch-adjustment.

The same kinds of abstractions have been made for all non-note midi data. Except that at least initially Steinberg was totally against having PC represented AT ALL. I don’t remember how it all settled out in the end. For a long time, VST3 plugins could also not output CC messages and everyone complained for about 5 years until Steinberg finally added a “legacy” feature to VST3 to support that, but it requires hosts and/or plugins to make use of the legacy feature, which to this day, not all of them have…so you get spotty results trying to output CC messages from VST3 plugins. Sometimes it works with some hosts and some plugins, sometimes it doesn’t.

Ok… so VePro is a different beast, because it is not actually needing to use those new attributes. VePro only hosts VST2 inside it. So VePro ultimately needs to provide each plugin with that old-school generic midi buffer with all the classic midi events in serial order as intended. So what VePro and other similar sub-hosting plugins have done is: they look at the VST3 attributes and convert to the generic midi buffer before sending over the wire to the VePro server…or calling the VST2 plugins hosted within. This is a hack. But they are all doing it. They have to, because Steinberg removed the old school way of handling the midi serial protocol, from the VST3 specification and API.

So anyway, in this case, VSL has some smart guys working on VePro, Marten in particular. They are very aware of these VST3 issues. But…something must have changed in the way Dorico is handling Program Change messages. Like I said, PC messages may not even be officially part of VST3, I can’t remember how it all came down in the end, Steinberg was against it, at least initially. So… why it worked in Dorico3 and not in Dorico3.5 is anyones guess, the Dorico team will have to respond about what they are doing with PC events in Dorico, and how they are interacting with VST3 plugins now, differently then they were in Dorico3. VePro has been using a hack, as has many other vendors, for years…to convert the relevant VST3 attributes back into a PC message to send on, but my guess…that representation from Dorico has changed…perhaps to be more in strict alignment with VST3 specs, but I really don’t know. But most likely VePro, and other subsists as well, will have to change their hack in order to work with Dorico.

Or perhaps its just a bloody Dorico bug. :wink:

Another interesting test would be to use a different plugin for testing rather then VePro. BlueCatAudio Patchwork, for example, has a VST3 version I believe. So put a logger inside Patchworks.vst3 and see if their PC hack is still working or not.

By the way, there are other problems with VST3 midi also that nobody can hack around. For example, The ordering of midi events within a a single timestamp are lost due to the hacks I explained above. The old VST2 way, you could have the host send an exact sequence of midi events to a VST2 plugin and that ordering would be respected by the plugin too. For example, if you wanted to make sure to have CC1-note1-CC2-note2, in that order, processed by the plugin, in that order. That could be done with VST2. It cannot be done with VST3. If you have that sequence on the same midi timestamp in VST3, then what the plugin can see is only CC2-note1-note2.

The same problem exists for PC, pitchbend and all the other non-note events…their ordering is lost…and only the last one wins for each so called “process block” of time, which is actually more then just a single timestamp, but I digress… point is…many of the tricks we rely on for articulation keyswitching can become problematic if you use non-note midi events for keyswitches in VST3 and that is not going to change due to the way the VST3 api was designed. It is just broken that way and not useable. VST3 wants people to use note expressions to represent articulations rather then manually inserting keyswitches…but at least so far, 99.99% of the plugin community is not stepping in line with that, so for now anyway, VST3 is never going to be totally ideal for keyswitch handling, unless you stick with notes-only for the switches. No CC and no PC>

But VST3 is the only way to use more than 16 midi channels in a VePro instance… so there is that.

I would recommend you find a way to avoid using PC for now honestly. Use a different CC for it, or if you can use a keyswitch.

By the way another useful addition to Dorico would be the ability to send keyswitches by velocity (unless its already there?). That makes it possible to use a single pitch to represent 128 discrete values via velocity…and so you won’t run out of keyboard trying to send different keyswitches instead of PC for what you’re trying to do.

In general, I try to avoid using both CC and PC for keyswitching because of the VST3 problems and because I want to use VePro.vst3 for large instance.

I’ve asked Paul to weigh in on this. I’m afraid I don’t know enough about this to be able to provide any specific insight at the moment. We will come back to you.

Just to weigh in some more info… I ran as quick test…

I put a midi monitor plugin into a simple endpoint. In this case I’m actually using BlueCatAudio’s Plug N Script plugin, with an actual midi logging script I wrote for it. Plug N Script comes in both VST2 and VST3 flavors so I can try them both in Dorico 3.5 to see what happens.

Result…

With the VST2 plugin, I can play program changes on my keyboard…and they are passed through the track to the endpoint, to the plugin and the logger displays the program change message.

With the VST3 plugin used, same logging script…the PC message doesn’t make it through…

This is without any expression map stuff or anything, just attempting to play PC on the keyboard and see what happens. As I suspected, its getting eaten by the VST3 api.

This is without VePro involved, BlueCatAudio also uses some of the similar hacks I mentioned in my last post to deal with non-note data coming into it with their VST3 plugins…

But anyway, something definitely did change with Dorico 3.5 in the VST3 handling, or perhaps program change handling. It works with VST2 plugins, but not VST3, so I suspect its the VST3 handling of PC.

CC and PitchBend messages, on the other hand are making it through the VST3 api layer successfully.

In the meantime, I recommend you use Note velocity instead of PC or CC for what you are doing. Just pick some pitch that never gets used by anything, like G8 or something. Then use the actual velocity for the value sent. This is instead of PC. That means that whatever was receiving the PC message will have to be revised in some way to receive the keyswitch by velocity, which may or may not be possible, I get it…but anyway, I advise generally to be careful about using both CC and PC messages for keyswitching roles when using VST3 plugins. See the above diatribe for why.

Thanks Daniel, look forward to it

I suppose that is fair. Though that will be a lot of work for my entire template to fix something I never suspected would be busted by a new update…

For those who are using Kontakt and need a simple multiscript to transform Note velocity data on G8(127) into Program Changes (I’m using Banks for different articulations in Kontakt which change only with Program Changes), and you need some workaround while you wait for the Dorico and VEP to sort this out, then here is a simple multiscript for you:

on midi_in

	if ($MIDI_COMMAND = $MIDI_COMMAND_NOTE_ON and $MIDI_BYTE_1 = 127)
		ignore_midi
		set_midi($MIDI_CHANNEL,$MIDI_COMMAND_PROGRAM_CHANGE,$MIDI_BYTE_2,0)
	end if

end on

Interesting.

Not to dispute, but HALion is the original VST3 model.

PC gets through for me in Sonic 3 SE, Sonic 3, and HALion 6.

I don’t dispute that your stuff might have worked with Dorico 3, and stopped with 3.5.

It does suggest that something has been mixed up in the interpretation of how VST3 is supposed to work?

It does happen. Case in point, I remember long time ago HALion 5 as a VST2 plugin working great in Bidule. VST2 version still worked properly, but VST3 had strange stuff going on. That team had to confer with Steinberg to figure out what was going wrong…as they thought they’d followed their VST3 hosting guidelines to the letter, but apparently wires got crossed somehow. Bidule team changed some things, and it’s been working nicely in the host ever since.

Same problem with my VSL expression maps.
A new version of expression maps should a least be backwards compatible with existing maps.

As i said earlier, VST3 does not officially supporting sending CC, PC and other non-note midi messages directly through to the plugin. Those parameters are handled a different way. When we are s specifically talking about sub-hosting plugins such as VePro, PlogueBidule, BlueCatAudio Patchworks, Metaplugin, and others… They have to translate VST3 api stuff back into tradition midi events in order to subhost VST2 plugins and pass through the data. VST3 spec does not directly support this. The Steinberg plugins you mentioned do not subhost other plugins. They respond to VST3 parameters. Can you name a Steinberg VST3 plugin that specifically responds to ProgramChange messages by the way?


It does happen. Case in point, I remember long time ago HALion 5 as a VST2 plugin working great in Bidule. VST2 version still worked properly, but VST3 had strange stuff going on. That team had to confer with Steinberg to figure out what was going wrong…as they thought they’d followed their VST3 hosting guidelines to the letter, but apparently wires got crossed somehow. Bidule team changed some things, and it’s been working nicely in the host ever since.

Excactly. But to be clear, PlogueBidule does not come in a VST3 form. You are talking bout what Plogue Bidule may have been doing in order to host other VST3 plugins inside it. But in this case we are talking about Dorico hosting VST3 plugins, which PlogueBidule does not even have a VST3 version to try…so the problem does not exist exactly in Plogue Bidule, though I am curious…and I will try later…if I put a VST3 plugin inside PlogueBidule…inside Dorico…will the Program Change message be sent through since it would be plogueBidule handling the VST3 hosting, instead of Dorico in that case. Might be a work around for the op. . Or BlueCatAudio…I will try them both.

Not sure how or why it works, but yes.

I can put Sonic, Sonic SE, in GM mode, or set HALion, to accept program change events (PC) for the program table, or even use program changes to swap layers, or modulate things like LFO/times/attack/etc. (I think HSO UI even has the option to use PC or CC events instead of key switches to toggle articulations), and they all work.

I do understand that hosting a plugin, and being hosted as a plugin are two different things. Still, the point is something about the VST3 protocol was misinterpreted along the way. HALion didn’t get changed to work inside Bidule. Bidule had to change to accommodate HALion.

I’ve seen these sorts of things happen before is my point.
In my experience, it usually gets fixed pretty quickly. In the case I witnessed, Plogue had to make the change. Something about the vst3 protocol implementation was misinterpreted?

just tried it.

As i suspected, if you put the VST2 version of either Plogue Bidule or BlueCatAudio Patchworks into the instrument slot of Dorico… and then inside of those use the VST3 version of midi monitor plugin… The program change messages get through.

So what this mean is that something in Dorico3.5 has changed related to how VST3 program change messages are handled, in such a way that it has broken VST3 subhosting plugins such as BlueCatAudio Patchworks and VePro. It every well may be that Dorico is not following VST3 api in a more strict manner that is finally broken PC capabilities with third party VST3 plugins…or it could be bug in Dorico 3.5…

No idea why Halion still works. VePro and BlueCatAudio…both broken now…

P.S.

I need to make clear…

In Dorico 3.5, I can load host the HALion plugins directly in Dorico (no Bidule involved).
PC Changes are working for me.

I am 100% confident this is a VST3 api issue. The VST2 versions of those plugins work fine. As I said earlier…VST3 does not pass PC messages into the plugin, the api uses “parameters”, its up to the plugins to translate those parameters as they see fit. So Halion can look at the parameters set by Dorico…(which you perceive as ProgramChange only because that is how Dorico let’s you control it). But the VST3 layer does not ever pass PC events into plugins… its relies on certain parameters being set by the host (the host being Dorico in this case). Something has changed about what parameters Dorico is setting in response to PC events in Dorico. Halion apparently still knows how to make sense of that. Both BlueCatAudio and VePro are now missing it because they have no idea what to look for, it has apparently changed compared to before. They need to know what Dorico is doing, then they can look for it, translate it back into a PC message and pass that on to whatever plugins are being subhosted within them.

As a work around, the OP should avoid using VST3 VePro…and/or avoid using Program change key switches.

I feel the pain.

Whatever the problem is (Dorico, or the plugins). I hope it gets sorted for you quickly.

I’m having to rework some things here with the exclusion group changes. I need to add some new entries that weren’t necessary before to keep things from breaking. Luckily it doesn’t seem to be anything major for me so far, and automating the process is simple enough with a good xml editor, but it is annoying.

Oh well, Dorico is worth it to me so far. There are some bigger projects that I’ll be holding back for a while until the fundamentals of the base interpretation engine are better worked out. I realize it’ll take some time, as it’s not a trivial task at all. It’s taking significant strides with each version though.

I’ll make a lua script to test this theory…but I’ve been led to understand that expression maps don’t do NE/VST directly.

I’ve built some instruments in HALion that intercept CC events sent by both expression maps, as well as CC lanes.

I’ve got LUA scripts that intercept them and modulate in real time. HALion is picking up CC events somehow.

Again, I have not tried this specifically with program change events, but I can…will get back when it’s done.