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

Dorico
41

Back after some brief tests with HALion 6.

With HALion 6.

I made a simple test score that just throws some program changes with the nat expression and put a whole note on the staff.

If I tick in Options to accept MIDI Program Changes, HALion will indeed select instruments from the program Table (among the first 128 listed) using Program Changes.

I Dropped a script like this in the HALion patch I was testing at the top level of the most parent layer of an instrument slot on channel 1:

-- print the fields of an Event object
function printEventMembers(event)
    print("Event Type:", event.type)
    print("ID:", event.id)
    print("Note #:", event.note)
    print("Velocity:", event.velocity)
    print("Controller #:", event.controller)
    print("Value:", event.value)
    print("Pitch Bend:", event.bend)
    print("Note Expression Type:", event.noteExpressionType)
    print("PPQ:", event.ppqPosition, "\n")
end
 
function onNote(event)
    printEventMembers(event)
    postEvent(event)
end
 
function onRelease(event)
    printEventMembers(event)
    postEvent(event)
end
  
function onController(event)
    printEventMembers(event)
    postEvent(event)
end
  
function onNoteExpression(event)
    printEventMembers(event)
    -- postEvent(event), not needed for note expression
end

Note: According to the HALion Reference, onContoller(event) should detect program changes and report them as event type 5.

The program change events were NOT passed to subsequent layers of the HALion instrument loaded in the slot.
In contrast, CC events most definitely WERE detected and sent down the pipe.

I unticked the accept MIDI Program Change box in HALion’s options.

The instrument no longer accepts Program Changes to swap instruments in the Program Table.
The events are NOT passed down to subsequent layers in the HALion instrument slot.
CC events ARE detected by the script and sent down the pipe.

42

I ran the same test as above in Dorico 3.1.10.1032

Same results as before.

HALion itself can be configured to accept PC events to change instruments in the program table.
It does NOT appear to be parsing the event. The script doesn’t detect it, at least not with this method.

I might be missing something…like there possibly being a way to force a script to check for events above the residing instrument slot level, but I’m not sure how yet. I think there are events for checking unhandled events, but I’ll have to look into that as well.

43

Just ran a check for onUnhandledEvent(event)

No program change events detected using that either (Dorico 3, nor 3.5).

So, it would seem that in both versions, Dorico is doing whatever it should be doing to get program change events to HALion,
BUT
HALion is responsible for doing something with it from there.

Case in point. If I flip the switch in HALion, it will accept the PC events and do work with them (change programs from the first 128 program tree options); however, HALion isn’t forwarding them deeper into the sound matrix where I can use them for other things in my program designs (I’d need to use CC for such things instead).

Digging a bit deeper into supported LUA events, I found:
5 - EventType.programChange - Only used for Standard MIDI files.

So far I haven’t found where HALion gives access to the parameter that stores current PC value(s) anywhere. Just a way to filter PC events on specific channels/slots.

44

The problem occurring in Dorico 3.5 is NOT related to expression maps. It is related to VST3 hosting. PC messages originating from a midi controller will not make it to the plugin either…in other words…its not anything related toe expression maps, but rather the VST3 plugin hosting.

45

here are some related internet posts about VST3 and program change.

shorturl.at/GLV16

etc…

you can find many more if you google.


VST3 uses a parameter based approach in the VST3 api, totally different then the VST2 api. They are called “program lists” I believe. This has been the case for a long time, and up until recently, VST3 plugins such as VePro and Patchworks were able to translate the program lists into actual PC messages to be passed on to sub hosted plugins. Apparently, with Dorico 3.5, they are not able to do it anymore. So something has change in Dorico 3.5 that is just enough different that this necessary hack has become broken.

I don’t own Halion and really don’t understand what you’re going on about with Lua, etc… If that helps you figure out what exactly changed in Dorico 3.5, then great!

46

I can also confirm that running the same tests with Cubase 10.5, works as intended. PC messages go all the way from Cubase, through VePro.VST3 to VePro server, to logging plugin and I see the PC message arrive.

So there is something different about the way Cubase is hosting VST3 plugins, vs the way Dorico 3.5 is hosting vst3 plugins…

47

That is essentially what I was just checking.

Obviously the PC is making it from Dorico to HALion in some form or another.

I send a program change through Dorcio, in ANY FORM…be it from my MIDI controller, or Expression map, and HALion gets the event to change instruments, and provided I have the option set for it to accept them, it does so. Otherwise it seems to ignore them.

I ran the script to see if HALion echos the event (in whatever format…vst, note expression, MIDI cc) for further potential use elsewhere in the HALion engine. I could not confirm that it does that. I could not find if/where HALion grants user access to the PC parameter. If one could find this, then it would be easy to use the parameter for a variety of custom purposes other than GM style instrument changes.

Point being, HALion somehow knows when PC changes are being sent, but it appears to only be useful for one set purpose. Changing instruments from a predefined list of patches.

If it’s useful information for anyone following the thread, great, if not, sorry for the bother.

48

Part of the complexity here is that steinberg does not view VST as a midi api. In Arne’s well expressed view on the sdk forum, Vst was never intended to write mid plugins, the fact that people have done so was not Steinberg’s Intention and they have no desire to support that with VST3. Instead with VST3 they wish for things like keyswitches and what not to be handled using so called Note Expressions. That is the steinberg vst3 way it should be handled. So in their view everyone must adopt VST3 and do it the VST3 way. Unfortunately at this point in 2020 almost nobody is using note expressions except for steinberg plugins and cubase. So it’s really a moot point from a practical perspective, but anyway the Vst3 api is not designed to pass midi events through. It’s an audio api. According to Arne, midi events are only in the host daw, not inside the plugins. Plugins are supposed to be accessing these vst3 abstractions to create performances, rather then directly processing a stream of midi events the old vst2 way.

In the case of subhosters like vepro, the midi stream needs to be passed from the host daw into the vst3 hosting plugin, and from there passed into yet other vst2 plugins that are expecting a midi event stream. Because of the way vst3 has gotten rid of midi events entirely, that means vepro and other subhosters have to do some translation Mumbo jumbo to convert vst3 abstractions back into midi events. They can mostly do that ok except for some timing problems that come up, particularly when using articulation management solutions such as expression maps where keyswitches occur in the same timestamp as the notes they are articulating. But generally still it mostly works. As I said earlier people should avoid cc and pc switches when using vst3 instruments because of those unresolvable timing problems. Or use vst2 if you must use cc or pc switches.

But anyway something about that conversion tap dance between vst3 abstractions and vst2 midi stream is broken with dorico 3.5. Dorico is obviously posting pc events in some fashion that is correct for vst3 since halion sees the parameters. Dorico 3.5 also is sending through to vst2 plugins perfectly fine. But whatever they changed in the way they are doing it now, is different enough that it has broken the conversion that vepro does to convert it back to a real midi stream again.

Vepro still works fine with cubase regarding all this. So it’s some bugger little minor detail I’m sure but the dorico team will have to figure it out

49

Every bit of that makes sense.

I envision it like a million knobs on a giant control board. The host sets the values, the plugins figure out what to do with those settings from there. Things like Bidule allow us to drop in bidules to convert those knob values into MIDI events and back again.

I realize I’m not helping much in solving your issue, apologies, I just find the topic interesting.

Someone did bring up that everything is working in Cubase. Cubase fully implements the NoteExpression protocols, and has all kinds of options for converting things MIDI to VST/NE on the fly and back again.

The CC lanes in Dorico do seem to behave more like the VST lanes in Cubase (as opposed to the method of specifically using CC lanes in a MIDI or Instrument track using one of the MIDI editors). I.E. In a MIDI track in Cuebase, one can jump instantly from a CC value of 0, to 127. In the VST lane, it has to ramp or curve up, as if twisting the knob (or one has to go to a lot of extra trouble to put end points on the lane, and snip out the lines/curves).

The Cubase implementation gives us what seems like half a dozen choices on how we want to represent, edit, and stream the data. It has an interface for hooking MIDI events to NE, or directly to VST controls (Remote Maps), as well as ways to instant bind incoming CCs to NE, and more.

Dorico picks a method for us, and it’s pretty much invisible to the user. Perhaps something got changed in the style of routing or translating the meaning of all those ‘virtual knobs’.

50

:slight_smile:

I envision it like a million knobs on a giant control board. The host sets the values, the plugins figure out what to do with those settings from there. Things like Bidule allow us to drop in bidules to convert those knob values into MIDI events and back again.

Well, to be accurate… Bidule is currently not available as a VST3 plugin. its only available as VST2. That means hosts such as Dorico and Cubase actually do pass a direct midi buffer full of midi events into Bidule…it doesn’t have to convert anything. That is how VST2 fundamentally works.

Its really only VST3 instruments where this translation happens…and really its only much applicable to VST3 plugins that actually need to subhost other VST2 plugins or process traditional midi events in some way. For example, BlueCatAudio Plug N Script… That is a scripter plugin, and it comes in a VST3 format. It is designed to function in the VST2 paradigm, even though its a VST3 plugin. So PlugNScript converts all the VST3 parameters, as best as it can, back into a traditional midi buffer stream, so that the “script” can look at midi events the old school way without knowing or caring anything about VST3 abstractions. And that is a good thing, it keeps scripting simple and consistent with the rest of the world. And believe me the rest of the world is still using the old midi buffer VST2 approach.

That particular Scripter plugin, by the way, also can’t see the Program Change messages coming from Dorico, but can from Cubase, when using the VST3 version of the scripter.

Someone did bring up that everything is working in Cubase. Cubase fully implements the NoteExpression protocols, and has all kinds of options for converting things MIDI to VST/NE on the fly and back again.

Well also, that is not really why its working in cubase. NoteExpressions have two different levels of thinking about them. NoteExpressions are a feature they built into cubase, with a GUI where you can define midi events to happen as an expression attached to notes. all of that is in the DAW host domain…it has not passed the VST3 barrier yet. The VST3 api easily facilities NoteExpression data structures, etc…

But anyway, at some point, with or without that GUI facility, the VST3 api is used to host plugins and pass data to them for processing. With the VST2 way of doing it, Cubase has to pass an old school midi buffer. I would assume, but have not tested, that in the case of cubase, if you are using the NoteExpression GUI in some way, Cubase itself would have to translate that note expression back to just a simple midi event buffer before calling into the VST2 plugin with the simple midi buffer, as expressed by that NoteExpression in cubase.

But with VST3 plugins…Cubase doesn’t do that translation, it just passes that NoteExpression abstraction directly into the VST3 plugin. For the couple of plugins in the world that know about NoteExpressions, that’s great. For everything else, it would be useless. that’s why for the most part nobody is using NoteExpressions in their plugins, because Cubase would be the only host actually using them. Well anyway, that whole tension about VST2 vs VST3 is another thing…but bottom line…that is not why in this case PC messages are making it into VST3 plugins in Cubase. That might be why Dorico 3.5 isn’t working though! If Dorico assumed it could pass PC as note expressions to VST3 plugins, then it would fundamentally break pretty much all non-steinberg VST3 plugins that haven’t been paying attention to NoteExpressions. Cubase on the other hand may be wise enough to specially NOT try to use NoteExpression internal objects for calling into VST3 plugins.

See what I mean?

Just speculating now. The Dorico team knows what they changed.

The CC lanes in Dorico do seem to behave more like the VST lanes in Cubase (as opposed to the method of specifically using CC lanes in a MIDI or Instrument track using one of the MIDI editors). I.E. In a MIDI track in Cuebase, one can jump instantly from a CC value of 0, to 127. In the VST lane, it has to ramp or curve up, as if twisting the knob (or one has to go to a lot of extra trouble to put end points on the lane, and snip out the lines/curves).

In my view that is probably just a GUI design decision in Dorico.

51

I have found the issue, this is only for VST 3 plugins using the single component (one compoment for Controller and Processor) which is not recommended… in this case the program changes were not correctly send to the plugin from the host. This will be fixed in the next update.

52

sweet!

53

THANK YOUUUUU!!!

This is why I love the Dorico Developer team. They listen and they fix stuff (at least the stuff I’ve complained about :smiley: )

54

Did Paul found time to have a look?

55

No, but another of our engineers did and fixed the issue. See Steinberg Forums

56

Oups I had not seen the last page.