Essentially, people don’t want Dorico to become “Sibelius by Steinberg.” And some cracks sort of show with some issues requiring workarounds not dissimilar to the plugin system used by Sibelius.
Let’s not forget the people who made Sibelius the dog breakfast that it is is essentially the people doing Dorico now, so one hopes they look at that past and learn from it instead of making the same mistakes.
Note On with a 0 velocity is usually interpreted as Note Off.
The way I understand your request, OP, you’re asking the Dorico team to set aside feature development in favor of maintenance or improvements to basic UI/UX. A less charitable way of phrasing this could be “Feature request: no new features!” I’m sorry, but I can’t relate. The rapidly growing feature set of Dorico is frankly impressive—particularly the fact that the team always finds room for even more. I suppose that I’m biased because many of my own feature requests are still missing, and I’d feel short-changed if the feature development suddenly stopped. I’ve had to work around some of these issues, too, but that doesn’t mean that there’s a better program to switch to.
In fairness, maintenance is a big deal, but that’s what the minor releases are already for. A quick check of the Dorico version history shows that every Dorico 6.x release has included multiple bug fixes; version 6.0.22 was dedicated to them exclusively. My point here is that the Dorico team is already very responsive to maintenance requests—perhaps even more than to “true” feature requests. So, I don’t really see the necessity of asking the team to slow down; just ask about the bugs in the same way as you would for functionality.
Since I have the most recent version of Dorico, I decided to investigate the issues that you’re drawing attention to:
In summary, I’m seeing not so much a request to slow down, although it could be interpreted that way, as a request for two new features:
as well as a possible request for a bug fix, depending on what the file menu actually looks like in dark mode.
*Not exactly a new feature, but hardly a “bug fix”, either.
Only focusing on implementing feature after feature is a great way of rapidly increasing your technical debt.
And guess which notation software is a great example of that: Sibelius. Many people who used the software back then will probably remember of the infamous plugins which were originally intended to extend its functionality, but in practice were mostly workarounds for the decades of quirks and unfixed issues.
While true in it’s own, I think it’s unfair if you’d writing this, suggests this is how the Dorico team works.
As @Serioso tells: you’ve only have to look in the version history.
As an example the latest 6.2.30 mentions 5 improvements (aka new features) and 33 ‘issues resolved’ (aka bug fixes)
If you think this is something that you need to teach the dev team, then you haven’t been paying attention. From the Dorico blog:
it is important that we take the time to perform essential maintenance, address technical debt, and keep us on the right path for the future.
That was back at version 3.5!!
As mentioned by others, there’s not a single release that doesn’t improve existing UI or workflow, fix bugs, “tweak” existing implementations, as well as add headline features.
Many of the refinements and fixes come from posts on this forum, so please list them. (And indeed, the export folders thing is well rehearsed.)
Are there still things to improve? Of course. There is still much to be done.
But I think the armchair corporate management can probably be left at the door.
So, I’ve been unable to send a CC value of 0 via CC90 (a user defined CC) to Hauptwerk. Have you tried to send zero via one of the undefined CCs? And what utility do you use to show the info that you posted for CC data, please?
BTW, I’m on a MacStudio M2Max Tahoe 26.6.2 if that might make a difference…
Yes: as you can see, I sent 0 on CC54. (which I chose entirely at random.)
The app I used is called Midi Monitor – I sent Dorico’s instrument Routing to my MIDI keyboard, which the app can ‘intercept’ and log. It’s also possible to use the IAC (Inter-Application … something) Bus, which is MIDI connections between apps. You can turn it on in macOS’s Audio MIDI Setup.app.
MidiPipe is another application that might be useful.
It’s pretty common to send CCs with 0 value. Garritan has some switches that are stupidly set to 0 = off and 1 or higher is on. I suspect that something else must be going on for your example not to work.
As said, this should probably be split off as a new discussion.
In Yamaha/Steinberg world, if you enter PC 1, it really sends a 0 value.
Yamaha simply numbers programs from 1 to 128 instead of 0 to 127. So, if you’re looking at a list of programs that begin with 1 and go to 128, enter them as you see them. If they begin with 0 and go to 127, mentally add 1 and poke that number in. I think this is right, if not it might be the other way around, and be sending one less than ‘expected’…a little experimentation can sort it out. There might even be a toggle switch in there somewhere to ‘choose’ the convention you prefer (been some months since I dug that deeply into Dorico expression maps).
I too would like a controller lane for PC events, but until that day, it’s done through Expression maps and then you make Playing Instructions or Techniques (or borrow existing ones) and bind them through the expression map.
You can also ‘initialize’ a stave by setting up bank change and program changes in the init section of the expression map.
If you want the ultimate power in interpreting and transforming all things MIDI, consider a third party bridge like bidule. With a tool like this you can even build somewhat automated series of controllers, and more (you can manipulate the audio output as well).
As far as I know, continuous controllers send 0-127, so that rule only applies for ‘program changes’.
I think the difference is that I’m sending that to Hauptwerk’s VST/AU Link, not a physical MIDI device.
And, I have shared this in a separate topic with no resolution: Playback Automation CC value 0 is never sent for CC 90
Thanks, though. I’ll see what the monitor says is happening.
UPDATE: So, I’ve tried a couple of MIDI monitors available from the App Store. They do not, apparently, monitor data from Hauptwerk’s VST/AU Link (a mediary to trigger the HW software via a DAW or notation software) because it does not identify as a MIDI device (virtual or otherwise).
Dorico doesn’t care: it still sends the same data.
No, you can’t monitor to a VST – that’s why I routed the data to my keyboard instead. It’s still the same data, because the Expression Map is the crucial thing.
On Windows 11, I can confirm through bidule and HALion, running as a VST plugin in Dorico, that Dorico is sending the proper events or pumping the correct parameter(s) for a CC90 event to plugins.
I believe with VST2 it works more like old school MIDI. The HOST sends MIDI events, and then the plugin interprets them? With VST3, I think it might be more like the host pumping virtual dials (VST parameters) that’ve been registered by the plugin, and again, the plugin must interpret that stuff and do its own thing from there.
Apologies that I don’t have a Mac setup to test it there but here it goes with Windows 11.
Bidule VST3 Hosted in Dorico:
I set up a CC here and used the audition button at the bottom of the Base Switch list to send the base switch events. When that is clicked, Dorico will send your base switch events and play two notes.
Again with Bidule hosted as a VST2 plugin
And here with HALion 7 VST3 (via lua script that prints any events coming in from the host to the LUA console).
--[[
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
So that’s 3 tests, through two different plugin developers, and two different VST protocols.
I did run a variety of CC90 events through the plugins within a range between 0 and 127, and they match 1:1 with what I entered in the Expression Map.
I ran some through Dorico’s controller lanes too, and those worked as expected.
Note that many VST3 plugins these days require you to go in manually and link CC parameters you intend to use with VST3 parameters registered by an instrument or they get ignored.
I.E. I have some Arturia plugins of which an incoming CC does ‘nothing’ unless I manually link the CC parameter in question to some registered VST parameter hosted in the Arturia Analog Lab instrument host.
I.E. I had to manually dial in CC90 in the bottom right pane here and connect it to a specific VST parameter (In this case a Q setting for a Filter):
Of course it’s similar if I bypass Analog Lab, and run one of the Arturia instruments as a direct plugin. I still need to go in and link CCs to whatever parameter(s) I wish them to control. Here I’ve linked CC90 to a Drawbar Leaking parameter, as can be seen at the bottom of the right pane of this Arturia Organ VST3 plugin.
Thanks for your extraordinary effort looking at this. I am beginning to think that it may be related to the interface being VST2/AU and Hauptwerk refusing to update it.
Thanks, again, I really appreciate your help. With @benwiggy’s advice, I’m going to stop discussing this here but would love any additional input at Playback Automation CC value 0 is never sent for CC 90.
Here’s how keyswitches work: You need to assign the correct terms so that Dorico knows which playing style to use. With MIDI CCs, you shouldn’t just add the number—you should also include the function of the MIDI parameter to maintain a clear overview in the Piano Roll. If the sound library manufacturer offers numerous MIDI parameters in addition to the keyswitches, these are primarily used to control vibrato, panning, attack, delay, and similar effects.
The method of control you described for Cinematic Studio Strings is very unusual. This is because playing styles such as arco, pizzicato, and spiccato are actually controlled via keyswitches.
MIDI controllers are meant to add emotional depth to the right parts of the project. One of the most important MIDI parameters is undoubtedly Expression (CC11 in most libraries). I think I’ve explained sufficiently why a function label (and not just a number!!!) would be so important when setting up the MIDI controllers in the Expression Map.
On the contrary, it seems a lot of people on the forum very much want Dorico to be Sibelius.
Nah. If it’s going to go toward anything other than Dorico, Finale might be the better choice…
(…not really…)
Sadly, Finale has reached its own finale so I don’t know how it could do that.
My needs are basic, but the integration with Cantai is perfect for me. 5-part a cappella, Late-50s through mid-60s American pop. Very useful for generating MP3s for singers to practice their parts. I was using Vocaloid.
Thank you all for your participation in this effort to communicate to Dorico, that slowing down a bit, might be a good thing..
At an early point I felt my that the point of my message had gone lost, focusing to much on the export audio thing, but somehow it got back on track.
Thank you everyone. I will let the administrator decide when this thread is done.
