Playing about with playback of @Stephen_Taylor’s Rite of Spring Dorico file. When I click the clarinet trill in Write mode, I hear the expected playback.
When I play it back, though, no trill.
As far as I can tell, all of the relevant settings are in order.
We’ve occasionally seen issues like that before. Could you please cut the project down as best you can to a minimal case that reproduces the problem (e.g. just one instrument, and a few bars) and then upload it here without removing the current playback configuration? If you’re unable to get the project down below 4MB having done so, please either post a link to it on a cloud drive somewhere, or email it to me directly.
I’m assuming this is referring specifically to your Spitfire SSO library as with the default NotePerformer the exact opposite happens in that trill plays back perfectly but if you click on it, the trill doesn’t sound. With the BBC SO, both work OK so it’s also not a general Spitfire issue. I’m assuming here you haven’t edited anything at all in the score? Do all other trills work OK? if not, which ones?
I have come across this before myself on occasion but unfortunately not often enough to establish a pattern. Either I might have started playback right on the note where latency can cause a patch change to kick in late (can you try it from a few bars earlier in the score?). It may be that Daniel’s memory might be jogged but ideally we need someone else who owns the same library to try and replicate.
Here’s the optimized file:
clarinet_trill_fail.dorico (3.9 MB)
I have some insight into the problem:
This is a player with two instruments assigned to him. Because both instruments (an A clarinet and a B♭ clarinet) use exactly the same samples in my VST, and because they would obviously never play simultaneously, I have assigned both of them to the same VST and MIDI channel.
The trill is written for the B♭ clarinet. In addition to removal of the A clarinet from the score, I can get the trill to play properly via either of these methods:
It looks like ordering of instruments is affecting playback, when it shouldn’t. I would think that an instrument that isn’t playing would have no bearing on playback.
the score has no less than 11 clarinets in some form or other and it’s best to give every single one of them a separate MIDI channel if you want to ensure the playback is correct. This is what Stephen has already provided so the BBC SO picks it up correctly using the Pro template (my Core version doesn’t actually have all the instruments but the library performs automatic substitution if necessary).
Is it only the trill which is affected or is that just the first thing you noticed?
Are you suggesting that it’s reasonable for an instrument that isn’t playing to affect keyswitching on its assigned channel?
That’s fine if he wants to do that, but it’s a waste of resources, in my opinion. I don’t have D and A clarinet samples to go with my E♭ and B♭ samples (it would be quite an extravagance if I did), and of those eleven clarinets, fewer than half of them will ever play simultaneously, anyway.
Affected by what, the sharing of channels by clarinet parts? Just the trill, yeah; I don’t recall hearing any other anomalies among those instruments (though I haven’t played them in isolation over the entire score).
looking at your extract as opposed to the full score, I can easily reproduce the problem. You are basically asking Dorico to use one channel for two instruments. When it reads this line, which is the lower one as you can see in Galley View, it doesn’t know how to play it back correctly. Dorico will default to the first instrument held by the player which is the A clarinet in this case. If you move the music to the A Clarinet, it will play back correctly. You need another channel to get the playback working properly. As I see it, you’re trying to simplify things beyond what Dorico is capable of. Unless Daniel or someone knows something which has completely escaped me!
Did you read my second post in this thread? You’re repeating what I’ve already written, including that moving the music to the A clarinet eliminates the problem. (As I wrote, reordering the clarinets in the Setup tab fixes the playback, too.)
Is Dorico incapable of correctly sending MIDI messages from multiple instruments to a single channel? I could see this being a big problem for instruments playing concurrently, but the situation of two instruments on the same VST/channel combination playing in mutual exclusivity should be commonplace, theoretically. A clarinets and B♭ clarinets are very similar, and a natural expectation is that they’d use the same sound samples in any given library. Since they’d use the exact same samples, and since either one or the other would ever play at once (assigned as they are to a single performer), I don’t see why they’d need to be assigned to different VSTs or different channels.
Yeah, I’d like to have a designer or programmer chime in, at this point. I need to know if there’s actually some limitation of the software in play, here, because it totally looks like a bug, to me.
Yes I read the post about moving the music up to the A clarinet and was explaining why I think this is the case. Unfortunately, I somehow omitted the phrase “as you have already said” or words to that effect when discussing the effects of moving the clarinet line. Incidentally, when I test this with VSL, a single note plays for around one bar and stops. No articulations of any kind are recognized. Same with SSO?
As for the wider point about Dorico sending MIDI messages, someone else can comment on that. I’d also be interested in knowing if a bug stops it working in a single channel or whether it is by design. My only aim in posting was to explain what to do to get it to work.
Thanks for taking the time to put together a minimal case. I’ve spent a bit of time looking into it, and it does indeed appear that the problem is related to the way Dorico merges the playing techniques required for multiple instruments when it has to squeeze them down onto a single endpoint. The good news (such as it is) is that I cooked up a simple example from scratch that reproduces the problem in Dorico 3.5, and that same file plays back correctly without any intervention in our current development build, so there is some reason to be hopeful that this will behave better in the next major version of Dorico, when it arrives later in the year.
Sounds good, Mr. Spreadbury! Thanks so much for having a look at this.
