I’m using windows 10.
I have disabled a number of “MIDI Input Devices” in Dorico’s Options.
The good news is Dorico now ignores data coming in over those ports as it should.
The bad news is that Dorico seems to have locked the ports down so nothing else on the system can use them either.
If I start my other apps that need the MIDI ports first, and start Dorico last, things work as expected.
Did I miss some option that will instruct Dorico not to lock ports he won’t be using?
I don’t know about “locking” MIDI ports, but I believe all the options in Dorico’s Preferences actually do is prevent Dorico itself from receiving any events through those ports; I have a feeling that the audio engine is still listening to them.
Daniel,
That seems to be the case, and it seems to be preventing other apps from using them as well. Dorico is the only host or MIDI related app I’ve come across in a very long time that locks down the ports like this (And I use several, including Cubase Pro, Sibelius, Finale, etc.). Not only does it do some kind of port blocking so other apps can’t use them, it grabs every single MIDI device on the system.
When I say ‘locking’ the ports, I mean that Dorico is taking exclusive control of them, and other apps throw up errors that they cannot access the ports.
I realize it might not be real high on the priority list, and it’s not a ‘critical’ thing with no work-arounds for me at this time, but I’d like to go ahead and suggest having this behavior changed in the not too distant future. If the engine is going to lock ports (take exclusive control, or whatever it’s doing), it should be one of those, “If you are having issues try this” options in the device settings, and not the default behavior.
A simple example problem scenario:
The Roland Fantom XR came with editor software that still works quite well for Windows (I think Apple broke it for Mac when they dropped PPC support). The Fantom X Editor is nothing short of amazing, in that it allows the user to control and tweak every single aspect of the XR from the PC, and more…
If I remember to launch this app before starting Dorcio. I’m good to go. Things work as expected.
If I launch it after Dorico has started, it can’t connect to the Fantom’s MIDI ports.
A little less simple, but fairly common and pragmatic scenario:
Sometimes I want to route controllers through Bome or Bidule before forwarding it through a virtual MIDI port into Dorico. Why? It can make a really dumb MIDI Controller much ‘smarter’. I can flip pedals, split zones, remap stuff, build custom velocity curves, or compensate for temporary hardware issues with a controller until I get a chance to have it serviced, etc. They also allow binding MIDI events to key combos, and vice verse. It can also be an OSC networking bridge in case I want to send events over the lan/wan (integrating wireless android/apple tablets into the controller equation).
Again, if I be sure to launch any such apps BEFORE starting Dorico, and be sure to do any MIDI device routing in advance, it all works. If I forget, then it’s necessary to save, shut down Dorico, start up other apps that need MIDI ports, go ahead and set up any routing involving any MIDI ports, then relaunch Dorico.
More complex scenarios:
While it’s more rare, there might be times when a user wants to work with multiple Host apps on the same system at once. Such apps need to be able to connect to MIDI ports.
There may also be scenarios where quite a few things MIDI needs to be routed through a central PC. These might be routing matrix that are never intended to go anywhere near a Dorico session launched on the same machine…connected to device/ports that Dorico should totally IGNORE (not just take exclusive control over and mute)…period…always.
I’ll talk to Paul and Ulf about this issue. I’m afraid I don’t know all the ins and outs (no pun intended).
Ulf has been looking into this issue and it appears that the behaviour is dependent on the drivers for the MIDI devices in question: if they use the old Windows 95-era MME APIs, then only one application can access them at once, and you will get a weird error like “out of memory” or similar when a second application tries to access the port; if, by contrast, they use the more modern DirectMusic APIs, then multiple applications can access them happily.
Thanks very much for looking into this.
I’ll run some tests when I get a chance and report back here, as the Roland X USB driver in particular is indeed rather [old] (requires some hacking to get it installed on Windows 8 or 10 due to ancient installers that Roland refuses to update, and possibly doesn’t exist at all anymore for Mac users), but I don’t recall ever having this problem on the same system with Cubase (etc).
The odd thing is that if I run other apps FIRST that connect to the XR, it’s not a problem, and Dorico can also connect to it. In contrast, anything I try to run after Dorico has started cannot access the XR ports anymore.
If there are MIDI device drivers out there that are a potential problem, then [to me], it makes it even more important to have some way to fully ‘blacklist’ select devices from Dorico touching them.
I think maybe I have narrowed things down to AKAI devices.
Interestingly, only the inputs get blocked, while the outputs are free.
Test one…
I have Dorico configured to ignore input from all MIDI ports except for a virtualMIDI port that I’ve named Bome1. The intention is to route the Akai MPK261 input through Bidule before it goes into Dorico.
…
I ran Bidule and made a connection from my AKAI MPK2 and EWIUSB controllers to the Fantom XR USB MIDI device. I tap some keys, and it plays. I blow in the EWI and it plays.
I next loaded the Fantom X Editor, and it connects to the XR without issue.
I launched Dorico, loaded a score, created a MIDI device in the play tab, and connected a stave to it. No problem, Dorico sends events to the XR. Since the MPK2 also has a direct connection, I can play away on the keyboard or wind jammer without activating a staff or instrument in Dorico. BOTH connections are working.
Next I did some tweaking with the Fantom X Editor, it’s doing all of the sysex reads and writes over the MIDI connection just fine.
Test two…
I killed Bidule and the Fantom X Editor.
I started Dorico.
I started Bidule.
Right off the bat, when I try to set up Bidule to accept input from an AKAI MPK261 MIDI keyboard, while it shows up in the list of devices, trying to connect to it just fails silently.
Next I tried an AKAI EWI USB Wind Jammer. It shows in the device list In Bidule, but does not connect.
Next I tried setting up Bidule output for the two AKAI controllers. This half works fine.
The other devices that I currently have connected seem to be OK. The Fantom XR is working in both apps. The M-Audio Delta 1010 works in both apps. All of my Virtual and rtpMIDI ports seem to be working fine in both apps.
Test 3…
I killed everything and launched Cubase 10.
As with the Dorico Setup, I’d instructed Cubase to ignore all MIDI inputs but Bome1.
I made sure that I have a project loaded that has tracks with the MPK and EWI assigned as the input.
I confirmed the the controllers are sending events to Cubase.
I launched Bidule and tried getting input from the MPK2 and EWI.
It behaves the same as with Dorico. They can NOT connect.
Note, I had not noticed this with Cubase before. I recently upgraded to version 10.5. Note that I didn’t use Cubase 10 all that often, in lieu of mostly needing my scoring apps in that phase between version’s 10 and 10.5. I’ll have to try it with older versions 9.5 and earlier at a later time.
I’ll also give it a try with Sibelius and Finale in a future post.
I also need to go back and try some other things having launched Bidule ‘first’. Etc…
So, to be continued…
I tested with a Yamaha KX keyboard: Launched Dorico, then Cubase, then Nuendo, then MIDI-OX and they all happily received MIDI input from the KX.
Same test with a CME XKEY, Korg Mini, Nektar LX61, and only Dorico - as it was launched first - received MIDI input.
So it really comes down to the MIDI driver. Yamaha has an own dedicated MIDI driver, whereas the others rely on the generic USB-MIDI driver from the OS.
This does not change that the engine is not black-listing and ignoring the MIDI devices that I un-ticked in Dorico’s preferences/play tab. It is still taking control of the device and locking it so nothing else can use it, even if we ask the Steinberg Host to ignore it.
Since Cubase 10, it is now doing the same thing. It takes over control of available ports that I have disabled in the studio settings. I don’t recall this behavior in earlier versions. (Might be due to some generic remote device maps deeper down that I forgot to check, I usually have those set to a virtual port, but it’s possible I have one somewhere that is set to the MPK2…will try again later).
If we could truly black-list a specific device so the DAW totally ignores it at start up, rather than initializing a connection to it…period, then we the user can sort it out in ways to get multiple host support from such a driver using our own routing apps and virtual ports.
That’s part of the point in using such a set-up. One can mingle and merge multiple controllers into one MIDI port or even bounce things around over multiple ports in real time…
Being able to blacklist MIDI devices is critical for live setups, and quite important for church music, where we often drive ranks of virtual organs (and these days even acoustic pipe organs are sometimes driven by MIDI based consoles) and stuff at the same time using 3 to 5 keyboards, plus pedal controllers, etc. A performer might want to run some kind of DAW or Scoring app to play accompaniment/collaborate/etc.), and maintain a lot of universal settings across many apps (even if some of the devices use exclusive mode only drivers). In such scenarios, if the sysop sets up Dorico to IGNORE a list of devices plugged into the system, it should truly ignore them.
In short…I’m glad Steinberg is sticking to the driver rules, as that will increase stability…especially as newer devices attempt to support plug and play at any time.
With that in mind, there should still be a way to truly black-list devices so Dorico/Cubase/Etc. doesn’t ‘connect and take control’ of them if asked to ignore them. I can’t imagine a rule that REQUIRES a given host to take control of every MIDI device on the system, even if it’s not used in a given project. Even if you have told the host to IGNORE it in the settings.
In Dorico’s case, it should not connect to the port at all, or if it must run a test at initialization, then it should disconnect and free the port if the device is un-ticked in Dorico’s play settings.
In Cubase’s case (as a side note), it should not connect to the MIDI port if it is disabled in studio settings either…unless…one sets a track to use the port for input. So, know the port is there and possible to connect and use, but if it’s unticked in studio settings…please leave it free unless a track, or something else in the DAW settings specifically calls for it.
Point. There are scenarios where we want to black-list and ISOLATE a given device for the DAW even touching it without explicit instructions to do so. Sometimes it is all about routing things in a live or studio setup. Sometimes it’s because a device is known to cause problems with a given application, but works fine with others. The list of possibilities goes on.
Next test…
I just ran the same test with Finale…
First started Finale, with it configured to ignore all MIDI inputs but the bome1 virtual port.
Next started Bidule. It can access the MPK2 and EWI controllers.
Next started Dorico while Finale and Bidule are running…my routing of MPK2/EWI > Bidule > Bome1(Virtual Port) is still intact.
The point here is to show that if Finale is set to IGNORE a MIDI device/port, it does so.
Bidule doesn’t take control of anything unless I actually connect something to a corresponding device bidule.
Dorico…IF the port is available at the time it launches, TAKES CONTROL of the device/port. Despite having unticked that device in preferences.
Next Test…
I set Dorico so it no longer ignores the MPK2.
I killed all the Apps that call for the MPK2, including Dorico.
I launched Finale first. It is set to IGNORE the MPK2 device.
I launched Dorico. It is receiving input from the MPK2 as expected.
Point here: Finale was asked to ONLY accept MIDI input from my virtual MIDI ports. As requested, it is NOT taking control of my MPK2 or EWI ports when it launches. They are still free for other apps to grab and use.
Sibelius Tests
Will run tests later, but before the recent updates I’m pretty sure that it would truly ignore MIDI devices if asked to do so.
Hi Brian, many thanks for your extensive tests. We take your input and raise the issue in our bug tracking system, but can’t make a promise as to if and when we will be able to address it. Especially, if we come up with a solution, then we need to come up with one for Cubase/Nuendo and Dorico at the same time. Because the MIDI port handling is done by Dorico’s audio engine and that one is derived from Cubase. So one solution needs to fit both.
I understand.
I’d hoped it would be something relatively simple. I.E. If the engine has a way to ‘disconnect’ from a MIDI device at will, then Dorico could do that instead of simply muting/filtering it.
If there is no such command/switch anywhere in the engine…oh well, maybe someday. I think it’d pay off in the long run to provide a way to truly black-list devices. Someday Dorico might be shipping with Organ Consoles, Church/School/Laboratory pianos, and all sorts of fancy things where devices and sysop implementation can get weird.
Over on the Cubase side I do need to recheck some things. I’d forgotten that I have half a dozen generic remote maps. One of those might have been set to open the MPK2.
We had a look again, and maybe it is not so difficult to hide MIDI ports from Dorico. Let’s see. But it’s not a promise that we will implement it soon; at least it’s on the list of want to dos now.
Thank you very much.
No problem. I’m not here to demand or expect promises.
I’m impressed with the progress of Dorico. I knew what I was getting into when I decided to invest in Version 1 of Dorico not all that long ago.
I’m not here to ‘complain’ as much as pointing out little things that I think you’ll hear again (fairly soon) if they aren’t addressed sooner rather than later, as the user base grows and Dorico gets merged into more working/learning/playing environments.
I know there are priorities and just like every other feature request or bug report, it gets evaluated for a priority level, and goes on a list for some manager to decide when/if/and how it gets assigned to someone to do.
I try to keep my wish list simple, doable, and if I make it ‘now’ it’s simply because I feel it’s one of those things that may well prevent bigger ‘problems’ later on in the development process. I do have a secret wish list, but its for stuff several years down the road, that are probably ALREADY on your drawing board anyway.
The two issues I’m on about now are nit picking things that can wait, but in my mind at least, they are ‘foundational’ elements that will effect the way 3rd parties might try to support Dorico long term. So better to address sooner rather than later, as those third parties don’t like it much if they have to make ‘major changes’ to old things. Also changes made later in the game force you to build in layers of ‘legacy support’ that won’t be as critical, or difficult to implement, if settled and nipped in the bud early on.
I only press that issue ‘now’ rather than ‘later’ because people interested into doing Sound Libraries compatible with Dorico are already on the scene, wondering what path to take for the long term.
Halion 6 owners with the time and the will can brush up on lua and tweak things to work well in HSSE with simple program/presets, which can ultimately be shared with anyone using a bog standard Dorico installation (provided we stick with samples and layers included in the HALion libraries we KNOW will be on the target system).
Maybe kontakt users can make special scripted instruments to deal with the slur/legato thing too (technical and finicky)?
People who own Bidule can kludge in fixes that’ll work with any plugin/library, but that’s a ‘technically finicky’ third party option that’s well over $100 US.
The rest are left wondering why they can’t get a bow stroke on the first note of a slurred passage, and smooth legato throughout the rest of the passage. It’s almost impossible to do right now without either making special instruments just for Dorico, or tagging the first note of every legato passage with a double-technique and hiding one (which can throw auto stave spacing, and articulation alignments and stuff off in engraving mode).
Having the issues voiced, and added to the list…that’s all I wanted for now 
The next one might or might not be fairly simple to implement. If it is, I’d love to see it SOON. If not…it can wait.
I already do this some with Bidule in the mix, but I must route the Dorico click track in there and roughly ‘calculate’ the tempo based on that. It’s always a beat late if things are changing a lot…oh well. A fun experiment…and things will be ready to go if we ever do get a constant tempo status posted to our plugins.
Finally, here’s a couple I don’t expect to see anytime real soon unless it’s already in progress and we users just don’t know about it yet. Just wishful thinking…
I have a lot of requests for the default instrument choices and expression maps that Dorico uses by default. These are more difficult to communicate short of simply building them myself and eventually sharing them with someone on the Dorcio team. My point here is the bowed HSO strings shipping with Dorcio Pro as the defaults are TERRIBLE. There is nothing wrong with the library and samples themselves…they just need to be implemented a little better. On this end…I’ll just keep tweaking my personal stuff until it seems to work well with a wide variety of scores, then I’ll share it with your team to study and consider. Fixing them at this time requires some special lua scripting (due to how slur marks are currently triggering legato)…
Another one that can simmer for a while, as it’s pretty darn complex to implement and test, and channel based CCs get the job done; however, I’m excited about possibly having the ability to send note expression (NE) events via expression maps, and in the play tab (double click a note in play tab, and draw in stuff there as NE rather than on CC lanes…and also have a way to toggle the CC lanes back and forth between channel CC and NE). It’d be pretty cool to be able to attach things like sfz effects to the notes themselves rather than synced up on independent channel lanes. Cutting and pasting phrases with all their humanistic playback dynamics intact would then be a breeze. It also has the potential of cutting way back on the need for lots of ‘voices’ on a stave…with independent playback ‘end points’ assigned.
Regarding a couple of points:
Legato is something that we hope to look at in the future (as usual, we can’t make any promises as to versions or timelines), as we’re quite aware that the current treatment isn’t ideal. We don’t know what form that will take, but most likely that it we’ll make it partially independent of other techniques, so that if you have a particular CC common to all articulations that toggles legato on/off then it’ll be easier to wire up.
Plugin timing: this too is on our list. Currently the audio engine doesn’t know about the tempo or time signatures either, so it can’t pass that information to the plugins.
HSO samples: we do have some ideas for improving how these react to dynamics, but if you have any expression map improvements then we’d be interested to see them.
Note expression: currently there’s no way of adding any note expression data, but that’s something we may consider in the future.
Thanks Paul, Ulf, Daniel, and to the rest of your team.
Dorico is Amazing to be so young, and in many ways it equals or surpasses much more mature products and workflows.
The positive engagement and interaction with your user base here in the forum is second to none.
Looking forward to many great releases to come
I ran into this problem as well today… Dorico is locking ports created by Divisimate, even when not selected as input devices. Huge problem as it means I can’t have Dorico open at the same time I need access to Divisimate ports. Since I was sending Dorico output to Divisimate the whole workflow is impossible.
I am able to send to LoopMIDI ports just fine, so maybe this is a Dorico + Divisimate problem, but really unfortunate as I was hoping to take advantage of Divisimate’s functions from a Dorico context (particularly humanization and chord splitting/voicing). I can send to Divisimate via a LoopMIDI port but I can’t open Divisimate ports in my DAW even though no other software is actively using them.
Do you find as Brian did in the original post in this thread that provided you launch Dorico after the software that you want to use the ports that are disabled in Dorico, they can be used by that software?
Do you find as Brian did in the original post in this thread that provided you launch Dorico after the software that you want to use the ports that are disabled in Dorico, they can be used by that software?
Yes, that does appear to be a viable work around!
Dorico 4.3.11 is STILL locking MIDI ports that I specifically told it not to use. If I don’t start the other MIDI apps first, the MIDI ports cannot be opened by them.
I am going to start suggesting it is high time that Dorico started behaving in this aspect. There’s no use even having that configuration if it’s gonna grab all the MIDI in ports.
I host all virtual instruments in Reaper. Dorico sends MIDI to Reaper via virtual MIDI cables. For sure there are other people out there who want to keep their Dorico score files small and host their orchestral template elsewhere…
Dorico is CONTINUALLY trying to grab MIDI ports. In the middle of the day, if by any reason a MIDI port becomes available, Dorico will grab it. It’s not something that happens just at the start! The result is, if I close the other MIDI app, I need to close Dorico, too.
Every. Time.
This issue makes moot the choice of MIDI input ports in settings. When can we expect a fix?