Gregory here, I have a question about adding instruments to Dorico. Basically, what I want to do is to add multiple instruments through the adding ensemble button, but have each instrument automatically create a unique vst instance in the play tab. Currently, what I have my playback template set to is Noteperformer, and if I do this then each instrument will go into one instance until it reaches the 16 limit and then starts a new instance. But I want one instrument per instance. I do know of a workaround: I can add one instrument at a time, switch the vst to something besides noteperformer, then go back to the setup tab to add one more instrument, go back to the play tab, etc. But I’m trying to make an orchestral template, and that all just sounds tedious, so I’m wondering if there’s a better way.
What is the reason you want one instrument per instance? There might be a better way to meet your needs.
Okay, so long story short, I’m experimenting with channel switching instead of key switching for my articulations. I’m going to try this with Musio. The way I’m doing this is instead of having a single keyswitch patch, I’ll spread out any articulations I want across each instance, and direct them into their corresponding channels that way. Because of this though, I can’t have multiple instruments per instance because usually my articulations fill up all the 16 channels available. That’s why I need each individual instrument on their own instance. It’d look messy and convoluted, but it could work. But if you have a better idea on how to achieve the same thing, I’d be more than happy to hear it.
So use the Silence Playback Template. That won’t load anything as you add new instruments to the score. Manually route each instrument and save as an endpoint, which you can later combine into your own custom playback template.
What Janus suggests above will stop NotePerformer from auto-loading any instruments, but again out of curiosity, what advantage do you see for channel switching vs key switching in your scenario?
Basically, Musio doesn’t allow custom keyswitches, and there are certain patches that I like over the ones that are included in the keyswitch patch. A big example is the difference between the String core keyswitch patch and the String Pro keyswitch Patch. I love the legato a lot more on the pro version, but the pro keyswitch patch doesn’t have basic articulations like pizzicato, spiccato, maybe not even tremolo, unlike the core version, which does. However if I go the route of channel switching, then I can load the individual articulations into one instance of Musio, each loaded into their own channel. This way, I can make custom keyswitches out of any instrument, since there are so many other examples I could give where I’d love to have a keyswitch for some of the more niche articulations for musio, but they simply only have individual patches for a lot of them. Now I can have both basic and more niche articulations in one template in one instrument, which is obviously very appealing to me. The whole idea was given to me by this guy’s series:
It’s been super helpful, especially since I’m in his position where I prefer looking at an actual score instead of complicated midi notes, but I’ve always been super frustrated with the limitations of the articulations, and the complexity of my orchestral templates in the past. Channel switching though really does get rid of a lot of my frustrations.
I did try that, but I was a bit confused on how to manually route them. It’s not much of an issue now, since I’m almost already done setting up my instruments anyhow, but it’d still be good to know for the future.
I ask because I don’t particularly like the channel switching route as a general thing, at least for my own purposes. Yours may be different. I’ve seen Music Chef’s videos and understand his approach and why he does it, but there are a few reasons why I disagree with it.
Generally his basis for the channel switching is for easy transfer to Cubase because the expression maps were completely different, so having the MIDI on different channels allowed that to be retained. But now expression maps are much more similar between the two programs since Cubase 15 brought them much closer together. If at some point reasonably soon we were to have full transfer of playback details between programs (in a way that preserves expression map entries instead of converting them to raw MIDI notes), there’s next to no benefit of the channel switching in this scenario, because the expression maps would handle everything in both.
The other reason he does channel switching is becuase then he can have one map for an entire library series. I also somewhat doubt the utility of this. You’re always going to have some mismatches especially in some vendors where they are not completely consistent in the articulations they record - if I recall correctly, EastWest has harmonics only in violins 2 or something like that and not in violins 1. So if you try too hard to build a shared map, you end up having to leave out techniques like this for practical reasons. I don’t see a way around that - so you either have to leave the harmonics out completely so you can’t use them even in the violins 2, or the violins 1 patch might malfunction when you try to use the harmonics.
I feel that maps are most useful when you can send someone a map and they can immediately make use of it. Then you start getting broad use of maps and everybody benefits. When you use channel switching, it demands that everybody load the library in a certain specific way, which to me limits the utility of it. I prefer working with the official factory patches/presets if at all possible rather than making my own custom patches/presets or changing them, becuase ideally I want people to be able to use my maps just by loading up the instrument manually and have everything work out of the box without having to do anything extra. Doing anything weird like channel switching, or changing the core keyswitches from the defaults, is going to limit the utility. Sometimes I begrudgingly have to add things outside of the vendor defaults because the vendor defaults are kinda stupid, but I try to keep things as close as possible. I also think “what if someone else comes out with a great expression map, really powerful, much better than what I already have for a library, but I can’t use their great expression map because I’ve set up my library in a non-standard way and theirs is designed for the out of the box experience?”. If the official one doesn’t have something I need, I write the vendor to ask them to support it. In some cases they can’t do that right way, but I see my feature appearing a year or two later if they agree.
As an example of this type of situation you can get into with custom setups, Marc Larcher in the forums made a great Spitfire Joby Burgess percussion template. Unfortunately he did lots of custom things in it by doing manual keyswitch remappings. Now Joby Burgess percussion no longer exists and can’t be bought because it is part of the Spitfire SSO 2025 but with new programming. Because his template was built for the original version but had customized key mappings, it is useless with the new version unless you manually recreate the custom keymappings to match Marc’s custom ones for Joby Burgess (it isn’t possible to automate this), but if you don’t have the Joby Burgess to begin with (and I didn’t) that’s a problem because there’s no documented list of the changes needed. If the maps were built for the factory keyswitches to begin with instead of changing them, those haven’t changed in SSO 2025 so the expression maps and percussion maps he built should still work out of the box just by loading the new instruments instead of the old ones.
And the final thing is that keyswitches are going to be able to go away with MIDI 2.0 due to Orchestral Articulation Profiles, where the articulation information is provided in a standardized way with the note-on message. Theoretically this can enable a much more plug and play system since it defines standardized identifiers for common techniques like staccato, tremolo, etc. so that all vendors will follow those, negating the need for custom maps in many cases. Although we’ve been waiting for MIDI 2.0 for a while and it felt like it hasn’t been moving, that’s largely because Windows hasn’t supported it, but now that Windows has support I predict we’ll see movement there soon.
These strategies that Chef uses I’m sure work very well for him with the Orchestral Tools libraries that he primarily uses but I don’t use those libraries and even though I know a lot about his setup I personally have no desire to switch to it. I know with the libraries I use I would run into issues trying to adopt that setup and for me it would be a ton of work for next to no benefit. Especially the VSL libraries I use can have hundreds of articulations per instrument, much more than most other vendors, so trying to make custom presets to organize hundreds of techniques for channel switching would take me months. And then I would be using a non standard system and wouldn’t benefit from official maps or Art Conductor maps. And after doing all that I would still have to make separate maps for some instruments due to occasional articulation differences to retain access to everything. So it doesn’t make much sense to me given the libraries I use, it would be a ton of work for next to no benefit.
However I understand in your case where you might want to do this because as you have explained, the vendor doesn’t provide keyswitch options for all techniques that you might want to use. I would hope this is only a temporary situation and that this might change in the future. But I can see why you might want to do channel switching in your scenario.
However, it might help to point out a potential alternative that you might consider. In these scenarios, the way I personally deal with them is a bit different. I typically prefer to use the vendor keyswitch patch for as long as it will take me, as long as there are no downsides to that, and add other articulations separately. I might do this with channel switching, but alternatively I might put another VST host with patching/remapping capability in between Dorico and the final plugin. I normally use Pluginguru Unify for this but Kushview Element also can work and it is free as long as you don’t need the latest version (only the latest version costs $$$).
I prefer the Unify/Element approach over channel switching because of the way I do my mixing. I host all my instruments in one giant Vienna Ensemble Pro instance, and use that as a plug-in mixer for Dorico, as it hsa feature parity with DAW mixers and much more powerful than the Dorico mixer. This means in Dorico I only have one VST instrument plugin loaded (VE Pro) and it has 48 ports and 16 channels each port so 768 MIDI channels. But I have a lot of libraries so actually to keep things organized, that’s not much (I like to put different libraries on different ports if possible instead of cramming everything together). If I did channel switching I would waste a lot of channels that way in my one instance. The reason I keep everything in one big instance and do all my mixing and mastering in there is then I can just pass through the audio to the Dorico output without any plugins and so it is really almost like I am bypassing the Dorico mixer. Then when I bring the MIDI into Cubase and plug it into the same VE Pro project I will start off from having everything sound 100% identical in Cubase to how it did in Dorico, becuase I do the same thing there and use the VE Pro mixer instead of the Cubase mixer. If I did channel switching it would waste those valuable channels. So I bring another host into play (in my case Unify) to let me make custom keyswitch patches with instruments that don’t support it. This way I can put all my articulations on one channel in VE Pro without wasting channels. Also, assuming the original plugin improves in the future to allow keyswitching of any articulations, at some point I might not need Unify anymore and my template will need fewer changes if I don’t have channel switches to remove. This is made more likely by the upcoming MIDI 2.0 orchestral articulation profiles.
Sorry for the length, but I wanted to explain why my own setup differs, and why I continue to do things in a different way than Chef. Not that his way isn’t valid for him, but for me I’ve carefully considered the way I do things and feel like what I am doing is the best approach for me. In your case, you will want to weigh things out and decide.
I do see a lot of your points, I might try experimenting a little bit and see how things would compare.
Like you said, I do plan for this to be a temporary solution. I want the VSL orchestral libraries to be used between Dorico and Cubase, since from what I’ve seen they do a great job of integrating their libraries for both softwares. However, I’m a college student right now and am saving on money, so I’m afraid buying libraries and buying the full version of cubase isn’t in my budget right now, so I’m trying to find workarounds with the libraries that I do have.
Thanks for the tips, though!
Hi! It’s always a good surprise to see my name appear in threads like that ^^
Just to explain why I built the percussion maps on a totally remapped version of Joby Burgess percussion: I did start at first with the default mapping, then I realized it was absolutely not optimized for notation, it was clearly aimed to be used in a DAW (swells, crescendo and decrescendo stuff, etc) and a lot of what could be mapped and be really useful with Dorico was not mapped. So I started again, this time taking advantage of what the library could offer, and how could Dorico use it.
Of course, this is suboptimal because users need to load my Kontakt version of the instruments remapped (and this means I’ve had to update them with K6, K7 and now K8…) and now I learn that the instrument is no longer available for purchase 
it’s better when the vendors create profucts that suit our needs, and I admit I am no longer investing any money with Spitfire, as some other vendors do take some time and energy to provide maps with their products, and do not rely on our good will!
Hi Marc,
I was not accusing you of doing anything wrong or making a wrong decision in this case given the information available at the time. These types of things can be done with the best of intentions but there is always a downside to consider. So my point was that I would argue against people needlessly doing remappings from the defaults and really think carefully about whether it is the best way or not. In some cases it may be, in some cases it may not be.
At least in SSO 2025 when the individual percussion instruments are loaded (the individual patches), all techniques are mapped to keyswitches by default, there are no missing techniques not loaded. It is only when loading up the combined patches that combine a few different instruments into one that some techniques do not get mapped by default to keyswitches. I’m not sure if this was also the case with the original Joby Burgess version because I don’t have that - if it was, you might have missed it or decided you wanted to use the combined patches instead for some reason. But, at least in SSO 2025, all percussion techniques are available in the keyswitched patches for the individual instruments that don’t combine multiple instruments into one. Although for some people that might present memory usage challenges since loading instruments individually will consume more RAM, so that can be an argument to use the combined ones especially in the past when systems had less RAM (and then you do need to customize some keyswitches to gain access to all available techniques).
My point was not to say don’t do custom patches/presets - it was meaning “think really carefully before you do this, because this is what can potentially happen”. I also didn’t mean to call you out specifically, but yours was the best real-world example I could think of for where remapping has caused problems later down the line.
Or just share the missing articulations between the two. Symphonic Orchestra was pretty ridiculous, Diamond strings cleaned things up immensely with regard to common articulations.
Of course, that’s something where I feel they just should have sampled it for both. But there are also examples of techniques that might work great on the violin but poorly on the double bass, or aren’t possible on that instrument. I’m thinking especially about rapid arpeggios and other such fireworks which make less sense with the double bass. So once you start going beyond the standard-fare articulations it becomes more common that things will be incomplete when you compare side by side (since what the instruments are capable of differs), and then restricting yourself to using a shared expression map can hinder your ability to access these techniques.
Of course, and just because they are defined in a common expression map for all strings, doesn’t mean you would actually use all of them for every instrument.
Yes, Eastwest cuts some strange corners that I’ll never figure out.