While I know Daniel seems to disagree, I still think that having Endpoint Configurations as presets that can be selected in a VSTi instance would be a great time saver.
A typical case I’m facing is this one:
I have several different strings libraries. Standard orchestral, bigger, chamber, Dimension Strings.
When creating a Violin instance, Dorico recalls the first one it finds in the playback template. Very often it is not the desired one (I might not want, for example, a second instance of Orchestral Violins, but one of Dimension Violins for divisi writing).
With an EC preset, I would just recall it to assign a Dimension Violins endpoint configuration to the relevant VSTi. Not having it, I have to rebuild the endpoint configuration for each of the “non-standard” strings players.
It happens often that VSTi instances proliferate in my projects. In particular, I have percussion instruments not wanting to go to the assigned channel in an existing VSTi, but want to create their own new VSTi. I can clean things up, but then I remain with empty VSTi instances. Having EC presets, I could easily rebuild my VSTi configuration in the topmost VSTi instances, without leaving all those empty VSTi in the middle.
The other solution to avoid confusion when choosing libraries would be using different names for the different types of strings. I do this, in part, by manually altering the instrument names in the Dorico .plists. When becoming too extensive, this however goes easily out of control. And then, I might later want to replace “Dimension Strings” with “Cinematic Strings”, and would end having to reassign all the instruments to the players.
Importing flows with their players doesn’t seem to work as an alternative. Dorico continues to look for the entries in the playback template when importing.
The Endpoint Configuration does more than preserving the state of the virtual instruments, since it also contains the associated playback techniques, expression and percussion maps, and routing.
I’m already working with Vienna Ensemble Pro, that allows for saving the full set of orchestral instruments, but I still have to manually rebuild the endpoint configuration and reload and reassign the relevant maps each time I need a variation of the ‘default’ sounds.
An example I’m dealing with now: I’m building a template for the VSL Synchron orchestra. In addition to the Synchron Marimba, I need the additional techniques contained in the older VI Marimba.
I have therefore two different Marimbas: one player for the main (the Synchron one), another for a secondary/hidden staff (the VI one) containing the additional techniques.
When the secondary Marimba is loaded, Dorico routes it to the Synchron Marimba instance in VEP. To rebuild the VI Marimba, I have to create again an endpoint configuration I’ve already programmed and saved, but that there is no way to recover.
Being able to select what I have saved would result in immediate configuration of the secondary Marimba.
I could be wrong, but I think that the “Manual” option for adding Endpoints to a Playback Template may be a solution to having a bunch of VSTi to clean that you didn’t want?
To be transparent, I need to go brush up first on how overrides and such work. I think I would prefer doing it as an override in the template instead say of changing the routing in the inspector. I’d like it if the override would allow me to take into account something that I control like the instrument name in the score (VLN 1 or VLN 1 / Chamber ) and not just the canonical instrument name (Violin)
What Paolo describes has been the limitation with Playback Templates from the start, and indeed several of us have posted about this (including Paolo) going back to the end of 2019. If you only have one patch for each instrument in your template then of course the present system works well, and makes sense for users who do not have multiple sample libraries which they want to switch in and out.
Paul has stated before that they did not forsee the situation of users having multiple Violin 1 patches for example, that they might want to switch in and out of their template, and in hindsight might have thought about this differently. What would be ideal is to create endpoint configurations which refer to specific sample libraries for specific instruments and then be able to load them on an individual basis to create a template, thereby mixing and matching different libraries that contain similar instruments.
Hopefully this will come to pass at some point, particularly to help users that create finished DAW like mockups in Dorico alone, which after all is the reason why we have all these DAW like editing features.
I have multiple large libraries, each with a zillion patches so I get that part. What I think I’m missing stems from this feature:
You can today save endpoint configs separately (not in a template) and then quickly create multiple custom playback templates by picking and choosing from those saved endpoint configs.
I feel like that is getting in the ball park of what you’re asking (picking and choosing from a list of endpoint configs) and (bonus!) doing it in a way that you can save and re-use in the future.
I think I get the perceived gap too though. My suggestion is that they might go just a bit further with the Playback template override rules, so that perhaps in keeping with the Dorico philosophy the selection of the desired config becomes completely automatic in a broader range of situations. IE: rather than always choosing from a list, in some form or fashion there are parameters in the project or instrument that we can use to teach Dorico which override we want in a specific case.
Paolo, what I actually do, is to load the Marimba synchron and VI (or xsample or else) on the same midi channel. When I need a patch in the synchron marimba for example, my xmap calls at the same time the synchron patch and an empty slot in the VI marimba (or empty cc for xsamples). This way everything is kept tight in a single player within a single xmap.
I’m not sure if it would resolve the case for the endpoint configuration thought. I just don’t use them because of all the reasons already mention.
I think the solution would be even simpler if we could create our own instrument or at least duplicate them to have, let’s say, multiple violins that would still be well numbered in the score…
Either custom, user-created instruments that can be uniquely tied to a particular end point in a one-to-one relationship, or a many-to-one relationship between Dorico-defined instruments and EC’s from which the user can select. One of the two would do the job. My preference would be user-created instruments that have a unique identifier to be used as a “handle” for attachment to a particular EC.
You can already do this, is what I was trying to say.
As for the Marimba example: I love my Spitfire libs, but this is where I lean on Opus’ vast range and ability to combine patches from different EW libraries in the same instance - Its trivial to handle there.
Hey, if I’m really going to dream, how about the industry comes up with a “Universal Sample Player” (and no, Kontact isn’t it LOL) where all the libs work the same and you can mix and match.
The problem is not combining patches in a sample player but the ability to use 1, 2 or 10 different marimba players in dorico where you could specify different libraries for each of them and automatize the process through endpoint configuration. Unless I got it all wrong, it’s now impossible to set up an endpoint config where 1st oboe is set (with the xmap) to VSL VI oboe 2, 2nd oboe to VI oboe 1 and 3rd oboe to xsample oboe for example. Maybe through hacking the files, but not natively.
Agreed - sorry if I said it poorly, but that is what I meant in suggesting that Dorico extend the current functionality of overrides in the Playback template. IE: to create your own rules so that Dorico automatically chooses the correct endpoint for an instrument based on name.
I haven’t tried, but I would assume your first option would be possible now with a little hackery. I’ve created custom instruments before, so I don’t see why I couldn’t create a “Marimba (Synchron)” instrument and a “Marimba (VI)” instrument with separate instrumentDefinitionIDs.
True, but when encountering an instrument with the same name, Dorico links it to the first endpoint configuration found in the playback template. You can replace it, but not make them coexist.
This would imply creating dedicated xmaps for each particular combination of sounds. Feasible, with some headache, but not flexible. I’m actually trying some combined Frankenstein instruments, but this is a bit different than being able to mix and match different colors depending on the context. For example, having Synchron Strings Pro as the bread & butter ensemble strings, and then match them with something like Westwood Untamed Strings, or Spitfire LCO Strings.
I subscribe to this. Libraries of instruments will be matched to particular endpoint configurations, and allow for simple replacement and mixing of instruments. By looking inside the new Library Manager, I suspect this will come, sooner or later.
This is what we do while waiting for the solution invoked here above by Queb. Unfortunately it is not easy with a growing number of instruments, and is subject to errors and glitches (for example, I’m getting a lot of blank instrument names, probably for some mistakes I did in the custom instrument definitions).
Then, you have to migrate the instrument definition each time Dorico is upgraded. Feasible, but not exactly the safest and easiest solution.
Please allow me an analogy: being able to select an endpoint configuration as a preset would be like applying a character style to some text already formatted by a paragraph style. Or, in Dorico’s terms, applying a local property where there is already a global property at play.
I don’t think your analogy fits very well, but it is just my opinion.
What I’m suggesting FWIW is a more like taking some of the rule based behavior which is possible in an expression map, and using that same kind of idea to automatically assign different library / presets - including more than one library for the same instrument type at the same time - to parts. Yes, it would be an enhancement to existing functionality.
Pretty sure the Dorico team could be a lot more creative than me.
True. I use a simple xmap for all my bread and butter strings (Frankenstein from VSL solo and dimension, Xsample strings and Contemporary and Ircam) but I would need extra maps if I wanted to use another library or the Xsample as the main instrument.