After completing my template for VSL’s SE library (the light one), and while building a template for the big one (VI, plus other libraries), I can see how templates work in Dorico with the tools I’m using. Here are my considerations.
Loading the full VI template in VEPRO (Vienna Ensemble Pro) takes a long time. With no instruments added, creating 50+ VEPRO instances takes time. When I’ll add instruments, it will take forever. People using a fixed template, maybe on a dedicated machine, will not find it problematic. I work with variable ensembles, and on a single machine, so this is relevant for me.
When creating a new player in Dorico, the full instance is recalled in VEPRO. If I want a flute, the whole Woodwinds VEPRO instance is reloaded. I will only use a fute, but have to live with all the other instruments of the section.
I like to work with sort of a ‘snowflake’ method: make the piece grow from a cell. Develop the idea. Add instruments as needed. Calling all the players on the scene before the play begins is not in my ‘minimal’ style. I prefer to work with a small ensemble, rather than with all the actors booked.
Cubase has a Track Preset feature, and Logic a Track Settings one. These are presets of all the settings needed for a track/stave to play. In Logic, you get the names, the sounds, the effects. The equivalent of expression maps are not saved, but this has been requested.
For how I work, I would prefer something like a Track Preset than a Playback Template. It would be more modular, and be open to unconventional instrument setups. Each Track Preset could include a different sound for the same type of instrument (for example, one could have a ‘Violin Halion’ and a ‘Violin VSL’, as well as a ‘Chamber Violins’ and an ‘Orchestra Violins’).
Each instrument will carry the needed playing techniques and playback techniques with it (so, for example, the peculiar shaking of an angklung will have its techniques associated, without overlapping other types of shaking). Loading a project and the associated files would be much faster.
Are there already alternatives to do something like what I’m trying to achieve, by using the current features?
I would imagine that the only way to achieve something closer to what you are looking for using Dorico’s current feature set is to create individual endpoint configurations for Vienna Instruments rather than whole instances of Vienna Ensemble, so that the smallest unit Dorico is able to load is an individual instrument.
I did try, but I fear this will not work. Here is what I did.
Create a new Dorico project with a Violin player. Create an instance with a single channel, with a Violin instrument, assigned to MIDI channel 1, in VEPRO. Name the VEPRO instance “Strings”.
Route the Violin stave to VEPRO “Strings”, channel 1.
Save a “Violin” endpoint configuration.
Create a “VSL” playback template, and assign it the “Violin” endpoint configuration. Apply it to the project.
Save and close the project. Close the VEPRO instance.
Then,
Create a new Dorico project with a Viola player. Create an instance with a single channel, with a Violin instrument, assigned to MIDI channel 3, in VEPRO. Name the VEPRO instance “Strings”.
Route the Viola stave to VEPRO “Strings”, channel 3.
Save a “Viola” endpoint configuration.
Add the “Viola” endpoint configuration to the “VSL” playback template. Apply it to the project.
Save and close the project. Close the VEPRO instance.
Finally, test it.
Create a new Dorico project.
Add a Violin. A Violin is also recalled in VEPRO, in a “Strings” instance, MIDI channel 1.
Maybe another guess, to avoid having to deal with huge templates, is to live with the idea of manually programming everything the first time, and then reuse the routing made for an orchestral score as a template for subsequent scores. One would have to do some additional programming, in accordance with the general schema, but the core template would be there.
So, I could prepare a first score, then save a copy as the template. All music will be removed, but expression maps, playing techniques and playback techniques will be there as the general model.
This model could also be used for smaller ensembles, by deleting the unnecessary players in Setup mode.
Even this “core” template is too big, when using the full orchestra and all the needed variations – for example: having to include all the types of strings I could need (VSL Solo, Chamber, Orchestra, Appassionata, Dimension separate channels, Dimension single channel; Spitfire LCO and Orchestral Tools Expansions for extended techniques; conTimbre for extended technique solos).
I wonder how others do, when building their orchestral templates for use with Dorico.
You aren’t alone for sure. I work similarly starting with a sketch of some kind, and the instruments I start with are variable. I finally got around to improving this laptop, so the major quality of life improvement for loading times was a second drive, an M.2 SSD just for samples. IMO There is no comparison with an external SSD or spinning disk.
What I tend to do could probably be better automated. EWQL allows me to create custom presets that have multiple samples or instruments. I don’t have one big template - it seems too unwieldy and inflexible as you say. If I’m building a “snowflake” I use those custom presets as mini templates I guess. I add an instance of play, choose a preset that represents most closely what I want, choose an endpoint configuration that matches the preset.
I manually assign staves to instruments. I think Dorico has a better way to do that last automatically? But I haven’t gotten there.
You do with EWQL’s custom presets more or less what I’m doing with VEPRO instances. I can load them as needed, to minimize the total load. In any case, it is one section per instance, so, for example, in my case woodwinds alone are two instances to be loaded, maybe for using just a couple instruments.
Linking staves to sounds, in this picture, remains a manual operation. Create a new player, create a VST Instrument, link it to a VEPRO instance, assign the instance and MIDI channel to the newly added instrument. Then go to the Edit Endpoint dialog and select an expression map.
Another problem that I wouldn’t know how to solve with the playback template is that of multiple instruments of the same type. Unless I’m doing something wrong, I think to see that when creating a second Flute player, the same VSTi for Flute 1 is recalled. So, this would in any case remain a manual procedure.
Still thinking about this issue. My guess is that, with the current tools, the only practical solution is to create several different templates, and do some manual adjustment after selecting the corresponding playback template.
At first, I would create a master template in Dorico and VEPRO, including as many instances as instruments I may ever use. The Dorico project would include the same number of VSTis as there are VEPRO instances. They will be linked via MIDI and assigned expression maps.
Smaller, more agile templates will be derived from the master template, by removing VEPRO instances and VSTis, and/or instruments from each instance. The endpoint configuration, playing techniques and playback techniques will still be edited in the master template. They should be automatically mirrored to the derived, smaller templates.
Unfortunately, I fear MIDI channel linking will not remain the same, after applying a different playback template, so they will have to be manually relinked. Draft with an agile template, then finish the work with a bigger template: you should have to reassign each instrument to the corresponding instrument in VEPRO.
Maybe I’m overthinking, and there is a smarter solution.
I should have said that I typically have a single instance per instrument: IE: one instance for first violin, one instance for 2nd violins until I get to things like crash cymbals and bass drums.
That’s mostly because I end using a number of channels for something like a string instrument, as in EWQL they are better sounding than the key switched ones which often are only approximating the sound with envelop and velocity tweaks, etc. As far as I can tell, there’s no performance penalty for many instances versus a single instance with lots of disparate instruments. That is, as long as I don’t fall into the trap of having separate reverb instances for each one - that I don’t use the one inbuilt into the instances.
What feels most wastefull to me are loading samples for techniques that I might never use in a piece - but I KNOW I’ll definitely never use them if they aren’t in the template. I’ve been wishing for lazy loading, or loading only when a sample is used but I think that’s a request mostly for the library vendors.
With the tools I’m using, memory usage shouldn’t be an issue. VSL instruments can load articulations only when they are needed. Even my huge presets are light, if I only use a handful of articulations.
As for third party instrument used under Kontakt or other players, when not needed I can switch their VEPRO instance, and they shouldn’t load. My VEPRO project would take long to load, due to the many instances and channels, but it should remain relatively light in memory.
It would be more a matter of mental clarity, having to deal with just the instrument I need, instead of the whole catalogue. Easier to handle, easier to mix.
Reverbs: I use VSL MIR. I fear I will have to also call all the instruments into play, when building my template. Will this take CPU from MIR, even with non-used instruments? For sure, instruments I will not use in a session, but that are in the same VEPRO instance of other instruments that I will use, will be activated in MIR.
Trying and testing, I’m more and more thinking that a full template would be killer. It would even be anti-ecological, with all the energy wasted for things that are not playing.
Maybe I should be better create a light playback template, to be used as a repository for the expression and percussion maps, playing and playback techniques. No wiring, no patching. Just a repository and a place where to edit techniques and maps, and to call all of them with a single action.
Expression and percussion maps will be assigned to at least one dummy channel each, to be sure they are saved in the endpoint configuration after any editing. Techniques will be collected for any future new scores. Shame I will not be able to automatically transfer them to scores I’m already working on.
When I have maps and techniques in place, I will configure everything manually. Create a Dorico project, apply the playback template, create all the needed players on the go, create the corresponding instances and channels in VEPRO according to the general schema, link them to Dorico’s instruments.
Not immediate, but one could maybe later reuse this Dorico project (and the linked VEPRO project) as a template. With further manual editing, but not starting from scratch. And staying lighter than with an all-encompassing template.
That’s probably the one thing about Sib that I do miss - the ability to swap playback templates back and and forth underneath a piece “fairly” easily.
Or the idea of it at least. It could totally have been an operator problem, but importing sheets and ids and such was fiddly and obtuse enough that it just about always involved a fair bit manual work to switch. Still - I worked with a lighter template until later in the process, and I could switch back if I had significant edits or just plain didn’t want sound while I worked on “pretty”.
That’s probably the best solution, with the current status of Dorico. So, what I could do is still rely on a big template, but with a reduced version called into play while sketching.
Prepare a master VEPRO template containing everything. Any version of the strings. The full orchestra. A sketching orchestra. Keyboards. Everything. Having instruments load into ‘purged’ mode should make loading this template not incredibly slow.
Create a much smaller master VEPRO template containing only sketching instruments (for my current preferences, they could be VSL Big Bang Orchestra + Epic Orchestra 2). When composing, only this smaller project could be loaded.
Dorico’s playback template for sketching will not rely on instrument definitions and automatic VSTis creation. It will only be a repository for all the expression/percussion maps and techniques needed for sketching. Staves will have to be configured manually, and manually linked to VEPRO. Only the staves needed for sketching will be added as the work progresses.
When it is time to move from sketch to full orchestration, the full orchestra playback template will be recalled in a copy of the sketching project. The full template will be loaded in VEPRO. VEPRO will be in decoupled mode, so Dorico will not automatically create new instances/instruments in it. All staves will have to be manually routed/configured/linked to the existing instances/instruments in VEPRO.
→ A variation to the above to be considered, if/when possible: instead of duplicating the sketch project, maybe use a Dorico full orchestra template, with all the staves already routed/configured/linked. Major issue: Dorico can’t copy/paste CC data, so anything you did in the Play lanes in the sketch project will not be copied to the full orchestra project/template. You can copy/paste the notes, but not the controls.
With VEPRO decouples, I will still have both the sketching staves and the full orchestra staves linked to the instruments in VEPRO. I will be able to go on orchestrating, while having both the sketching and the full orchestra on line.
Not what I would have preferred, but something like the method used by most composers for a couple decades. The advantage, compared to the single track settings found in some DAWs, is that I would have the template pre-mixed and balanced.
All considered, I have several kilograms of audio cables in my studio, and the rack shelf with the 19" expanders is still a staple of my studio’s furniture. I’m just moving to the software version.
Your Rack reference has me thinking - With the exception of Rewire being missing to record in sync - maybe we ARE better off outputting MIDI to a DAW, and that way the DAW template projects can be swapped fairly independently of the score?
(Thinking about it) You still have to swap expression maps - or - maybe the secret is that you keep the same maps, and you only do “combination instances” if that is what you decide to use by mapping inside the DAW.
If you use something like loopMIDI that appears to allow you to create an unlimited or at least not overly limited number of MIDI ports and NAME THEM, then maybe you don’t have to do an overly large amount of repetive port changing - the 1sts violins always used a port named 1vln or something. MAC’
s can do that already
Hi,
Well, that’s the idea behind Vienna Ensemble Pro, isn’t it? A “host” with all your VSTs. At least, this is the way I’m using it. I have just a single instance of VE Pro in Dorico. In VE Pro I have the template I need for the project holding all the instruments I need. (I do arrangements for theatre music, so most of the time I know beforehand what instruments I have to write for)
I would prefer a different approach but in my experience this is the only way to run all the different instruments without Dorico constantly crashing (This, of course, depends on the VSTs you use, maybe Dorico is stable with your setup of instruments…)
Something that can help in dealing with a huge Dorico template: In Layout Options, one could hide all the staves, except for the basic ones for a sketch score.
When you start needing additional instruments, you can unhide them, and make the score grow up to the final form.
VEPRO is very flexible, so you can use it in the way you better prefer. It can host all your instruments, but also just one of them, for the increase efficiency in CPU/memory management and routing. If not decoupled, it simply follows the configuration set by the host program, and no longer work as a rack of fixed instruments.
But I understand that in professional situations like the one you are describing, having a fixed configuration is preferable. At least, you always know that you have exactly what you need.
I use those custom presets as mini templates I guess. I add an instance of play, choose a preset that represents most closely what I want, choose an endpoint configuration that matches the preset.