Bug?: Clarinets in the Endpoints in Dorico 4

Issue: Dorico may be overwriting and incorrectly saving some/most clarinets as B flat in MIDI-out endpoint configurations and playback templates - even when other types are explicitly chosen.

This happens in two scenarios. Option 1:

  • In Build Ensemble screen, pick some clarinets that are not B flat and add them (here I picked one in E flat, another in A, plus a bass clarinet)

  • Result - on my system, Dorico overwrites them to B flat clarinets:
    image

  • This might be happening because Ensemble picker is possibly limited to the default “parent” instruments only? However, I don’t see this mentioned in the manual unless I missed it (FYI @Lillie_Harris)

Option 2:

Avoiding the ensemble picker altogether and adding E flat and A clarinets individually, then routing them for MIDI out and saving both the endpoint and playback template results in a similar problem on my system - as soon as I “apply and close” the template or recall this setup in a new project, Dorico re-routes all clarinets to B flat and my assignments are ignored. Somehow the routing is not saved correctly.

endpointconfig.xml

Looking at endpointconfig xml that I saved with correct assignments, I can see that Dorico recorded clarinets as if they were all B flat, completely ignoring my choices and routing.

In this example, I picked and saved 5 instruments in this order: Clarinet in E flat, Clarinet in B flat 1, Clarinet in B flat 2, Clarinet in A, Bass Clarinet. But they ended up being written as the same instrument into the endpointconfig as shown below.

Playback

If I use this incorrect endpointconfig in a newly created project or if I open an existing one and “reapply” this endpointconfig then these clarinets, if used, would be re-routed. Dorico changes the assignments and directs several of these clarinets to the same MIDI channel. This breaks the playback even though buttons are active and playhead is visible.

Manually editing the endpointconfig file to indicate the correct instruments restores the intended MIDI channel assignments and also completely restores playback. (@Ulf - it turns out this was the problem that we had been discussing here and it’s easily fixed with a simple file edit).

However, editing the file obviously doesn’t work when using Ensembles in a fresh project - the instruments are overwritten in setup as shown at the top of the post. As mentioned, this might be a limitation of the Ensemble picker.

Additionally, the problem persists if the endpointconfig is re-saved later for any other reason - these clarinets are overwritten again.

I don’t know what’s causing this, but it’s interesting to mention that as of Dorico 4 there is a generic Sketch woodwind and its parent is the Clarinet in B flat. If I include both Sketch woodwind and my poor clarinets, the Sketch instrument would get routed twice for MIDI out - as a Sketch proper and secondly by bumping the first clarinet in my list and taking its place.

To expand a little bit on this issue with routing instrument for MIDI out, I suspect that routing problems are connected to parentEntityID.

Looking at instruments XML file, I notice that most if not all clarinets appear to have it defined and it is the same in every entry that I looked at: a clarinet in B flat.

Interestingly, the trumpets also have a defined parentEntityID, and the parent is the standard B flat trumpet. I think the clarinets should have the parent ID different by family, but that’s perhaps a separate topic.

Anyway, it looks as though the parentID is somehow messing up MIDI routing:

  • an instrument I never used in my custom endpoint, would still be routed - but as a parent instrument. So, it would take a slot that’s meant for something else in my endpoint and either bump other instruments or route some to the same channel.

  • compare this with an alto trombone, which has no parent ID defined. No matter how many alto trombones I load, they all get assigned to the same MIDI channel, which is wrong but at least it matches my endpoint.

Maybe the parent ID routing is fine for default endpoints, if that’s indeed the cause of the problem. At least it tries to have everything make sound.

But I think it’s likely broken for custom-made endpoints. An instrument that’s not defined in it should not be routed. A repeat of an instruments that’s not in the custom endpoint should not be routed either.

I will need some time to look into this, and don’t have the required time right now – but this issue sounds familiar to me. I’ll come back to you once I’ve had a chance to look into it further.

It’s taken a while but I have now been able to look into this, and I can tell you that the current behaviour is deliberate: when we set up playback data for instruments when you add them to the project, we use the so-called “base” instrument definition ID, rather than the instrument’s own ID. This is to take care of situations like when you create a project by importing MusicXML and Dorico has to modify one of its built-in instrument definitions to accommodate some change specified in the MusicXML file: as such, the instrument ID it ends up with is then never going to be found in the preset playback templates that define the sound to load for each built-in instrument ID, and thus those instruments would not be able to be played back. However, this does mean that built-in instruments like variants of clarinets also end up using the “base” instrument ID, which for clarinets is indeed the regular B flat clarinet.

It’s not simple to change this, in particular for existing projects (as this data is created at the point at which the instrument is created, and only recreated under very limited circumstances), and we don’t want to risk causing unexpected changes in playback for existing projects by rewriting this data automatically.

However, we can perhaps make a change in future such that we will use the instrument’s actual ID for playback if we are sure that the ID in question is one of the built-in ones, and only use the “base” ID in the event that the instrument’s own ID is not built-in. This would only affect newly-created projects, and you would need to recreate your playback templates after recreating instruments to take advantage of this change.

Regarding the ensemble picker, by the way, it is expected that you cannot currently create instruments with different transpositions for now – this is definitely something we would like to be able to accommodate in future.

1 Like

Daniel, thank you very much for looking into this and for the clarification.

If I’m understanding correctly what you’re saying here, a potential path forward would be for Dorico to first check if this or that particular clarinet had been specified and saved in the endpoint configuration; and then loading the “base” instrument only if it hadn’t. This sounds great, if I got it right.

If possible, I would be grateful for your perspective on this from another angle.

In my particular use case, I would like to sacrifice the import of MusicXML because I rarely use it and instead focus on ensuring the correct routing. Would I be able to do that if I deleted the parentID for clarinets and therefore force Dorico to use instrumentID only?

I spent a long time making a very large endpoint configuration in order to set up the exact routing I need. But right now whenever I create a new project, I still have to go back and manually correct the routing for the clarinets and a couple other instruments; that process is surprisingly time-consuming because Dorico is slow at this and I cannot do assignments in bulk and save them all in one go. If there’s a temporary workaround, I’d really appreciate it. Many thanks!

I really wouldn’t advise mucking around with the instrument definitions. We can potentially make the change I described in my previous reply in our next update.

1 Like

That would be incredible. Thank you thank you thank you :pray: