Hey guys,
So I spent quite a bit of time developing a giant expression maps library with my VEP Template. I’ve discovered to my horror that in 3.5 program changes are not being sent. Can anyone replicate this?
Please help.
Same problem here. Help x 2!!!
Ran some tests here and they are still working for me.
Example:
Loaded a string quintet score.
Changed Sonic 3 SE to the General MIDI mode.
Imported the GM I maps from this archive that use PC to swap between arco/tremolo/pizzicato
Dorico General MIDI Expression Maps.zip (17 KB)
Set the endpoints to use the corresponding String instrument expression maps.
Hit play…
It works as expected. The PCs to bounce from arco to pizz are working, Sonic is changing out the sounds.
I’ll test it more with some other plugins ASAP.
Could it be VSL related? Jacob is using VEP and nearly all my vst are Vsl…
Ouch, it turns out I can’t test much more.
No whitelist for like 80% of my setup.
I copied my old whitelist from version 3, but nothing is showing up.
Ah, Now I see they have a new section for whitelisting…
Trying it now.
Yay, Got Bidule up and running. I can pull up a MIDI monitor and confirm the PC changes are right where they should be.
It’s a VST2 plugin from Dorico’s perspective.
Expression maps I’d made in the past and imported are working. PC events are passing as they should.
It’s also working with my Fantom XR set up as a MIDI output in Dorico.
I’ve not tried with a ‘brand new’ map made directly Dorico 3.5 yet. Will try that when I get a chance.
The Vst3 version of VEP ignore Pc. Whitelist the Vst2 version in 3.5 and it should work…
After some investigating I have discovered that the problem arises in the relationship between VEP vst 3 and Dorico 3.5. Program changes are not being sent.
HOWEVER
The same is not the case with Dorico 3 and VEP vst3. In Dorico 3 Program Changes are sent just fine. This is in fact a bug.
I confirm again…
Unless I’m doing something wrong, whitelisting Vsl’s Vst2 doesn’t make control changes work
Not only do you need to whitelist the VST2.x version, but then you actually need to make sure that’s the version you’re using in your project.
Whitelisting the vst2 is not a good solution as the vst3 version of vep supports up to 48 Midi ports, which is an important vst3 feature being used in vep.
I think you have to pick your poison. As I understand it, it’s not a limitation on Dorico’s side that the VST3.x version of VE Pro doesn’t respect program changes, but rather on the VE Pro side.
That’s all fine and dandy, however VEP vst3 DOES work (send Program Changes) on Dorico 3. This leads me to believe it is a Dorico 3.5 issue.
Alright. I encourage you to try the VEP vst3 Plug-in with Dorico Version 3.0. You will find that program changes do in fact work. The community post you’ve sent is very old.
Right. My mistake. Forgot to change the one I was actually checking…
I can’t be the only one who can send program changes in VEP vst3 in Dorico 3.0 but not in Dorico 3.5
It’s difficult to test this or i would. Someone needs to test the same version of vepro using once with dorico 3 and once with dorico 3.5. Vepro gets updated often so you can’t preclude the possibility that a vepro update has broken it unless you run the test with the same version of vepro both times. I don’t have dorico 3 installed any more so I can’t do it.
Vst3 has some interesting things they did related to program change and basically this is an area where steinberg does not see eye to eye with many other people about the role and responsibility of program change messages in the vst enviornment. The vst3 spec does not want to pass program change Change messages directly through to plugins to use for alternative reasons. Many people found ways to work around that but it depends on what the host is doing too, but it really depends on the plugin as well. So how vepro is handling the vst3 abstraction of pc messages into vst3 is the question. Obviously it was working before for you and now it’s not. So this could be dorico being more compliant with vst3 specs which means Vsl still needs to find a different workaround now.