Is there a reason that Dorico playback automations will not send a value of zero (0) to a controller? I would like to consistently resent an Automation CC 90 to zero at both the beginning and end of a piece. That value is ignored. I can send any value from 1 to 127 to the controller but never a zero. Is that because it is an undefined continuous controller? Theoretically, we should be able to send any value to an undefined CC although I am limiting what I send to be 1-127.
I had played with custom CC (e.g. CC101) without problems. Would you mind to share a minimum project (you may remove all the notes) so that we could investigate together?
Well, I think I figured it out on my own. Even though zero (0) is a legitimate value to pass to CC automations, Dorico programmers have opted to use zero as the value where no info passes to CCs rather than a valid value to pass. I’ve addressed the issue differently.
Thanks, though, for your offer to help. It seems the issue is by design which is unfortunate when needing to use a CC value of zero that AU or VST is expecting for a particular function.
Yes, I tried that. My scenario is that I use Hauptwerk with a virtual pipe organ. CC90, an undefined MIDI change controller, is simply the one I chose to use to pass CC values to Hauptwerk. For changes in organ registration, I assign values to the pistons in Hauptwerk and then use CC 90 to activate or change them.
General cancel, turning off all stops at once, is generally assigned 0 in Hauptwerk and on compatible MIDI instruments. Sending that value at the end of flow allows the next flow to start “clean” meaning that not using general cancel causes whatever begins playing to sound on the previous registration during the first few milliseconds when the CC value is sent and the corresponding piston engaged.
When transitioning from a loud registration at the end of a flow into a new flow with a very quiet registration, the first few milliseconds of the new flow can have a “loud” staccato sound when it should be a quiet, contiguous sound, for example. I have not found a way to do what you show at the end of a flow to accomplish this and I have tried many times with different configurations.
Attempting to send this data after the music has stopped is impossible as best I can tell. Using the init or natural CC values at the beginning of the flow do not seem to do anything either. I tend to think that Dorico is coded so as not to allow a CC control value of 0 to be sent via MIDI.
So, now I am designating an unused piston where no stops are engaged and sending that value at the very end of the flow to clear the palette. It’s tedious because the key editor is not terribly good at promoting intricate, closely spaced value changes. Nevertheless, it works so that’s my workaround until our developer friends can allow a CC value of 0 to be sent immediately after playback stops or immediately before playback begins (in a pre-roll, maybe?).
Thank you for your kind assistance, @sunnych. It’s always nice to have others review an issue and offer suggestions - that’s frequently how I find solutions.
This is really above my pay grade but I know that software is not always standardized around MIDI CC values. Some use 0-127 while others use 1-128. Depending on the software (or hardware), I sometimes have to “ translate!” Could this “offset” be a part of the problem/confusion?
— Jim
I don’t think so. I can send CC90 a 1 and it activates what is assigned to “1” on the virtual instrument. I tend to think that it is a mistaken perception by coders that sending nothing is the same as sending zero (0).
Dorico has no trouble sending zero value for CCs. Multiple VSTs require 0 values, and when implemented in Expression Maps, all works well.
Does the virtual instrument assign 128 different things on CC90? (As 0 to 127.) Or does it implement a smaller number of things, each of which is triggered by a range of values?
What happens if you send CC90 = 127? Does the VST display “128”, or “127”…?
Have you asked Hauptwerk about this?
CC90 can trigger 128 different things in Hauptwerk via their outdated interface. The problem is that the discreet value of 0 never gets transmitted to Hauptwerk.
If I send cc90 = 127 it doesn’t display anything but if I have cc90 127 mapped to, for example, to fully open the swell box, that will occur. I send 127 and Hauptwerk receives 127.
I have asked Hauptwerk (Milan Audio) about this and they say it’s a Dorico issue. Interestingly, it worked fine with Finale. The only difference was Finale would easily interface with a VST2/AU interface but I have to either use Rosetta2 or Vienna Ensemble Pro 8 to connect it to Dorico. I’ve had the issue with both methods.
There have been others requesting that HW update their VST/AU interface but they just flat out refuse and state that the notation software should accept VST2/AU so it’s not their problem. Brett Milan is a bit of a jerk when it comes to being responsive to his customers. I have two paid licenses with them, one for Dorico and another for my Johannus organ.
Do they also provide a stand alone interface?
Perhaps you can set up a virtual MIDI port between Dorico and a stand alone instance of this instrument? You’d need to mix this instrument in his own world, and do audio renders in real time through some recording software of your choice, but it might work out ok.
Some plugins might exist in Mac world that would allow looping the audio output from a standalone instance of your organ back into Dorico (I.E. host something like reaStream or Black Hole on an FX fader in Dorico)? Even if that worked, and allowed Dorico to make audio renderings natively, it’d still probably need real time rendering, so it wouldn’t save you any time in that respect.
I mentioned bidule in another thread. With that one in its registered plug in variant you can transform MIDI in real time. I.E. subtract 1 from all CC90 events as it comes in. Convert one CC to a different one, and the list goes on. So if it turns out Mac Dorico is glitching on that particular CC, you could ‘correct’ it with something like bidule before forwarding the performance output to your organ.
On the Mac, I believe bidule would also allow you to host the AU version from within Dorico. I.E. load a VST3 instance of bidule in Dorico, then load instances of any AU/VST2/VST3/CLAP plugins you like in bidule. This would sort it if the problem is with a glitch in the organ’s VST2 implementation of CC90, but the AU version doesn’t suffer the same glitch. In theory, the advantage there is you should be able to get something going without Rosetta in the mix (at least as far as Dorico is concerned, bidule might need Rosetta to run VST2 plugins)?
The eval verson of bidule is free but it only works in stand alone (not as a plugin). Someone on the Plogue forums with a Mac might be able to help determine if the tool would sort your problem in advance of paying to register bidule.
With the free stand alone version of bidule, you could definitely host the organ in bidule and do some tests to sort out if the problem might be with your organ’s VST2 implementation, or something going on in the Mac version of Dorico.
Ben, you have full HALion and are on a Mac right?
I ran some tests with Windows, and Dorico is indeed sending what it should be here on Windows 11. Maybe you could load HALion and take a peek at things on a Mac? While it wouldn’t cover the behavior with VST2 plugins, it can rule out a Dorico side issue with VST3.
It probably wouldn’t be too hard to whip something SFZ up in a VST2 version of ARIA or Sforzando to check what Dorico is doing with CC90.
This LUA script will print all the events sent into HALion via the host to the LUA module console before posting it down the line to any child layers.
Copy of the LUA Script used above:
--[[
HALion Lua Script: Print Incoming MIDI Events to Console
Works in the HALion "Lua Script" MIDI Module.
This script logs note-on, note-off, and controller events.
--]]
-- Called when a note-on event is received
function onNote(event)
print(string.format(
"NOTE ON - Pitch: %d, Velocity: %d, ID: %d",
event.note, event.velocity, event.id
))
postEvent(event) -- Pass the event through to the instrument
end
-- Called when a note-off event is received
function onRelease(event)
print(string.format(
"NOTE OFF - Pitch: %d, ID: %d",
event.note, event.id
))
postEvent(event)
end
-- Called when a MIDI controller event is received
function onController(event)
print(string.format(
"CC - Number: %d, Value: %d",
event.controller, event.value
))
postEvent(event)
end
-- Optional: Catch other event types (pitch bend, aftertouch, etc.)
function onPitchBend(event)
print(string.format(
"PITCH BEND - Value: %d",
event.value
))
postEvent(event)
end
function onAfterTouch(event)
print(string.format(
"AFTERTOUCH - Note: %d, Value: %d",
event.note, event.value
))
postEvent(event)
end
PS…
Audio Gridder might somehow correct your issue as well. It’s kinda like a poor man’s version (free) of VE Pro.
It’d allow you to sandbox your AU, VST3, and VST2 instruments in their own world (on the same machine, or on a remote machine) and interface with them through a special VST3 bridge plugin in Dorico.
AudioGridder – DSP servers using general purpose computers and networks
Wow, that’s a lot of great stuff for me to digest as I’m not extremely savvy with all of the jargon much less the processes to make it all work. I will say that I have stopped using Rosetta and use Vienna Ensemble Pro 8 now to access Hauptwerk and that works fine except for sending that CC90=0 issue. VEP8 runs HW VST/AU link without using Rosetta as it is able to seamlessly communicate with VST2 and AU.
As to your PS post, I’ve not tried it since I began using VEP8 so I’ll give that a go and let you know what I find out. Thanks for all of your great help!
Well, I never really thought about testing this again after switching to VEPro8 as the host for Hauptwerk’s VST2/AU Link. Thank’s to the extraordinary responses from @Brian_Roland and @benwiggy, I decided to test this now that I am using VEPro8 rather than Rosetta2. Amazingly, Hauptwerk is now receiving CC90=0!
I had decided on VEPro8 more as a safety-net for when Apple stops supporting and providing Rosetta2 for general use. And, apparently Spirit (or sheer luck if you’re not religious) set me on that path for more than one reason. Besides being a safety-net from a Rosetta-free world, it also translates and transmits CC90 exactly as needed.
Much, much thanks to both of the previously mentioned users. Your expertise is amazing and I will hang onto the shared information for a long time as I start to learn how all of this interconnectedness really works!
It’s good that VEP sorted things for you.
Now I’m still curious if the issue is with Dorico and VST2 on Mac, or if it’s in the Hauptwerk VST plugin itself. NO doubt the Dorico Team would like to know if that CC is glitching because of something on their end.
It might be possible that Dorico isn’t sending the message when in Rosetta and/or when sending to a VST2, though I doubt it. We would have heard this before, surely.
I would suspect a bug in the Hauptwerk VST2 plug-in, or just some other particular combination of circumstances on your setup.
In any case, VST2 is past end-of-life, so it’s unlikely that bugs are going to be given much attention.
I would think that a glitch on Dorico’s side would render the ability to send/receive CC90 = 0 through VEP8 not possible. I’m just glad to have a fix (that I didn’t know that I had). 
Not if you’re running a VST3 VEP tunnel to the VEP server. In that case Dorico is using VST33 routines. VEP would then be translating things for whatever plugins it can host.
One would think, but how often is CC90 used in notation software? If it’s just a single CC glitching in this way, it’s only on Mac, and it hasn’t popped up until Apple Silicon came along, it may well have eluded us ‘all this time’.
True, but if it never gets confirmed and entered into jiri, it most certainly will not.
Well, I could use any undefined CC if I wanted to with Dorico. I just chose 90 randomly. I still have a copy of Dorico setup with Rosetta to use HW so I can test any other undefined CC if that would help to eliminate an issue within Dorico vs Hauptwerk’s interface.
I’m just curious. It might be nothing comes of it even if you pin point whatever the problem was. If you have time and narrow the problem down, documenting it someplace all the devs might find it never hurts, but your time is also valuable.