Endpoint configurations

I’m not understanding the design here.
“Endpoint configurations” (same term used for a single channel or a group of channels btw) cannot be loaded from the same dialog that they are saved with?

If I am saving a rack full of VSTis, I will want to use that same interface to reopen them.
Why is this not available?
Why are they only available to the Playback Template?

It was a design decision that endpoint configurations should only be recalled as part of a playback template. A few other users have requested that we make it possible to recall endpoint configurations without changing the playback template, and this is something we are considering for the future.

1 Like

Question then (let me know if I have some concept misunderstood here):

IF saving a playback template encapsulates the endpoint configurations in your project,
And saving endpoints at either the instrument, or instrument rack level cannot be recalled at those levels,
When is there actually a scenario for saving an endpoint configuration?
Wouldn’t you just skip the first two and go straight to saving a playback template?
I’m not understanding the design of a save point which you cannot also load from. That seems like a dead end.

As the playback template usually consists of various endpoint configurations, the original design decision makes some sense to me and is probably designed to reduce confusion. You can modify the PB template by changing the entries within it. You can also modify the endpoint entries. However, I agree that single channel and group of channels both being endpoints is somewhat confusing. I also still get errors on occasion saving endpoints and in some circumstances get extra VST instances added (particularly with VSL using Vienna Ensemble) even if I test by adding the entire configuration as a single endpoint which means in theory that the template should load back what you’ve just saved – not always the case. Others have reported similar behaviour.

I would conclude that it is indeed probably better to be able to recall the endpoints for error checking if nothing else. Also it’s useful when using 3rd party configurations to see what is actually the contents of the endpoint configurations.

The reason for having the split between Endpoint Configurations and Playback Templates is that it offers greater granularity. You can create an Endpoint Configuration for a subset of the current plugins active in a project, and apply instrument filters on it, which allows you to mix & match between plugins. Effectively the Endpoint Configs are building blocks for combining together into playback templates. A couple of specific use cases:

  • In the rack you have one HSSE instance for Iconica strings, one for Iconica wind, etc

  • You save separate endpoints for the string and wind plugins

  • You now work on a score that has divisi for the strings which requires an extra instance of the plugin. This will just load one more plugin, rather than loading redundant copies of the wind, brass, etc

  • You want to be able to use NotePerformer, but use the strings from another library (eg EW Hollywood Strings) and the piano from Pianoteq. You can define an endpoint config for EWHS Pianoteq, and then create a new Playback Template that combines those together.

We know that there’s very little you can currently do to view or edit the contents of an Endpoint Configuration, so this is something we may review in the future.

The reason I would like to be able to load an endpoint configuration for a VSTi, is that I use different sound libraries for the same type of instrument at the same time. I do it both for layering (a common practice of having different libraries combined to make a single sound), for using complementary libraries, and for extending the amount of techniques for a single instrument (for example, to add extended techniques to a basic set of articulations).

Some examples:

a) I want to use VSL Synchron Strings Pro and Spitfire Chamber Strings to create a complex, layered sound in two separate groups of staves (SSP Strings, SCS Strings). With the current system, the playback template will automatically assign the first endpoint configuration it finds in its list to both groups. Programming the second one must be done manually, instrument by instrument. Reassigning the playback template would scramble manual programming.

b) I want to use a set of Orchestral Strings for tutti, one of Chamber Strings for divisi. Again, the playback template will always recognize each occurrence of Violins as the first endpoint configuration (in this case, Orchestral Strings).

c) To create a complex instrument, made of Violins + Violins Extended I have to create two different instances of violins, each one referring to a different sound library. But the playback template will always assign the first one found in its list.

Being able to assign a separate endpoint configuration to each VSTi would allow mixing different plugins. Any complex routing would be allowed. Loading of techniques would be more granular, since each sound library could be associated to a set of techniques.


1 Like

I totally agree with Paolo. I had to give up on using endpoint configurations early on when I discovered it’s limitations for doing exactly what Paolo describes. I understand that it makes things easy to the extent that you will always get a violin if you create a violin staff, but I personally would like more flexibility in this area. I wonder if it can be configured both ways - Using endpoint configurations as building blocks for a template, but also allowing users to load endpoint configs. individually, without being part of a specific template. I think Paul alluded to this in his post above, but it looks like it’s a distant possibility right now which is a shame. Advanced users who are making serious mockups in Dorico because of it’s wonderful sequencer like abilities in conjunction with everything else the programs offers, would find such functionality very useful when switching and experimenting with different VST’s for the same staff/staves/instrument. Of course you can still do this manually, but it does become a little tedious at times.

We hadn’t thought of these use cases before, so that’s something we can consider for the future.

In DAW speak this would be a multi-timbral instrument? Not my cup of tea, but that should be easily accomplished by using Cubase or Logic as a VST ‘backend’ as I have, over MIDI endpoints. Then in there you just have a MIDI virtual channel coming in which you can route however you wish. For example in Cubase just have two tracks with the same input MIDI channel, done.

Should Dorico support this? Maybe … it’s already a complex beastie, and I like the ‘purity’ of its dedication to an instrument being a person holding an instrument. If you want to create a one man band

then perhaps the better approach is for Dorico to support this via creating custom instruments, which I don’t think is presently supported. It would entail giving us access to the pipeline from instrument to playback, expression and percussion maps and such. And this would be useful, it’s common in film and game music to use unconventional instruments (e.g. penny whistle), and with this I could make my own sample and actually notate and drive it.

Since we are discussing this matter, please let me describe an actual case I’m facing while creating a new piece.

  • The piece will be a hybrid one, made of orchestral sounds and synthesis. Sounds will be kept from different libraries.

  • I don’t know, when starting, which instruments will be used up to the end. It will not be a traditional orchestral setup, but an ensemble that will grow while composing.

  • I can decide to start from the VSL BBO playback template, being the sounds I will use the most. But I know I will use something from the Synchron Strings Pro and from Heavyocity’s Intimate Textures, so maybe I can add those endpoint configurations to a new playback template. Other libraries may be added later, and I’ve no idea about them now that I’m starting.

  • I will have conflicting instrument definitions. BBO Andromeda, an ensemble library, has its own fake definition (using something like Serpent or Duduk). But Lyra and Musca, ensemble strings libraries, are defined after the traditional strings quartet. They will conflict with the other string libraries – either ensemble or individual sections.

  • Fake instrument definition are a viable workaround. But not perfect: I will see note color showing non-existent note range limits, and idiomatic notation (say, for strings notated as a Duduk) will be lost.

  • When drawing my playback template, I will privilege the instruments with the richest set of techniques. The easiest ones will be configured manually. Not a major issue with MIDI routing (but avoid selecting the playback template again, or everything will be reset!). A major issue, on the contrary, with techniques, that will have to be recreated for the piece.

  • I’m purchasing a new, major library. I want to integrate it in the piece. Obviously, its map/techniques are not in the playback template. It is a big, complex library. There is no way to import its instrument definitions and techniques, without resetting everything. I will have to program everything manually. I fear there will be no way to reuse that programming in my general template (unless, maybe, I save a custom endpoint configuration to be incorporated in another playback template).


I do hope we’re talking the near future ? :slight_smile: (I’ve complained about this elsewhere earlier so won’t repeat myself here…)

Thinking about granularity: something I was asking was the ability of having not only playback templates (for the full score), endpoint configurations (for individual groups of sounds), but also “instrument configurations” (for the single instrument). Going on with my report:

  • I’m adding a single instrument from Orchestral Tools Modus. If I apply a playback template including the Modus endpoint configuration, everything I programmed manually will be scrambled. If I accept it, a full Modus instance in VEP will be loaded. This will include all the sounds of the library. But I only need a single sound. An instrument configuration would allow for recalling a single sound, either in a new or an existing/matching VEP instance.


Paolo : I’m following with great interest your work on VSL BBO templates for Dorico Pro 3.5. How are things going on that front? You can PM me if you prefer. (Just registered under a new ID and cannot PM yet.)

The xmaps are growing each time. I think I have most of them done, apart for the percussions (I’ve not yet completely clear how percussion maps work in Dorico). I hope to complete all the maps soon.



Thanks for discussing all this. I’ve pretty much given up on trying to use the Endpoint Conig/PB Template system. And, along with Fratveno, I hope improvements are implemented in a near future.

And, as always, thank you Dorico team!


Somebody found a way to create an endpoint configuration that would open an instrument in an instance of VEPro and not generate a full new instance?
I know from another thread that Paolo’s setup is similar to mine and if there’s a solution to my question, I might have a (not perfect) workaround that could ease things up.

Unfortunately, not me :frowning:


After some projects made with Dorico 3.5, I would say that I basically have these three issues with how virtual instrument management is handled. I don’t know if this is all by design, or there are also some bugs.

a) I can’t create custom instruments. Very important for the various nuances of the same instrument (various different violin libraries), libraries of basic and extended techniques, instruments not included in Dorico, ensemble/sketching instruments.

b) There is no way to recall the configuration of individual instruments. This means that, when using a host/mixing program like Vienna Ensemble, you are always forced to open a whole group of instruments even if you only need one.

c) Exchanging playing and playback techniques between projects can’t be done by simply copying and pasting, or by loading a ‘style sheet’ that can be exchanged between sound libraries.

d) Applying a playback technique not always also recalls all the latest expression maps and playing techniques. What I want is to be free to edit everything in a project, but if I apply a playback template I want it to overwrite everything matching in the target project. This is probably by design, but it seems to be so intricate that I’m not able to understand how it actually work and how to deal with it when editing the source endpoint configuration.