I’m endeavoring to write a comprehensive expression map for a library with a lot of articulations and a complex control scheme. And when I’m done I’d like to share it via ‘export/import library’ on the emap dialog.
I’m struggling with how best to encode the many articulations and patches that have no analogue in the existing playback technique set, as it appears that additions you make to that set do not get exported/imported with the expression map. This kind of makes sense as the playback technique set is global and there is no enforced namespacing on additions.
Nevertheless, this is a real need. Am I missing a trick or something? I’ve seen on the videos the co-opting of existing unrelated techniques but while that is something one might do for oneself (and now seems unnecessary since you can add to your own playback technique set), it seems fragile and confusing to do in a published expression map. All the more so since the user still must then create playing techniques (also not exported/imported) mapped to those playback techniques. I’m imaging a README that documents:
Expression maps don’t include custom techniques when they are exported, but they are included as part of an endpoint configuration, and can be exported as part of a playback template. So one option is to use them in a n endpoint configuration. It is possible to take the doricolib file that’s written as part of the config and use that directly.
We’re aware that there’s more to be done when it comes to import and export, but this is a larger topic
I’m sorry, I’m not following how one should use this info to share emaps with others.
I don’t know what the ‘doricolib file that’s written as part of the config’ is, nor where it is.
Saving a MIDI endpoint (I talk to Vienna Ensemble Pro over IAC) (individually or at the bottom of ‘MIDI Instruments’) consistently generates “An error occurred”, yet the name is subsequently available as an entry for a Playback template. Incorporating it in a template, and applying that template does not restore the endpoint.
I am now seeing my custom playback techniques and playing techniques across projects, the latter an indicator of this being at the wrong granularity for sharing emaps between users. No one wants my experimental playing techniques added to their global config.
I’ve now made a bunch of these custom endpoint configs trying to get this to work, only to find in the manual:
“You cannot delete custom endpoint configurations within Dorico Pro.”
Is there another way to clean them up?
[edit] I found them in ~/Library/Application Support/Steinberg/Dorico 3.5/EndpointConfigs
Unfortunately we don’t have a good solution for this yet - as I mentioned above, the whole issue of library management and import/export is a larger topic that expression maps are part of. I mentioned the endpoint configs mechanism because that does give you a way of getting hold of that extra data, but that method isn’t really ready for prime time. I guess you’ve found the location of the doricolib files inside the EndpointConfigs application support directories. Apologies - I should have mentioned that this is currently a manual method.
When you combine endpoint configs into a playback template and then apply that into a project then that imports all the referenced custom playing techniques into the current project. The act of creating a playback template doesn’t make them globally available though - it’s the Apply step that pulls them in to the current project.
The error with saving MIDI endpoints sounds like a bug because it’s expecting to find a plugin state to save, and there isn’t one. I’m not sure whether it should be possible to create and apply a playback template to MIDI endpoints. I think it might not be possible because the assumptions for VST plugins and MIDI devices are very different. I’ll have to look into that.
I have been making custom playback techniques for expression maps too. One of the issues i have is organizing and differentiating them from the pre-existing playback techniques in the articulation menus. It would be immensely helpful if we could define custom categories and then import/export them as needed. So instead of just having generic strings, brass etc. we could have say a Vienna Dimension Strings or Spitfire Albion categories which would make it much easier to find the playback techniques that are unique to those libraries. Sub folders would be wonderful too
Thanks
If you are thinking of a management feature for libraries somewhere down the roadmap, I would mention that one of the features requested for many years in Finale has been the ability to see what libraries have been loaded into a document. In Finale the libraries are just dumped one on top of the former, so Finale has never been able to track such changes in a user’s document.
When (if) you develop a library-management system in Dorico, an ability to see what libraries have been loaded (in what order) might be a feature you would want to design into the system since it has been in demand elsewhere. Just a thought.
+1 on that, although I think you mean ‘playing techniques’, the ones that appear on the p.t. palette, with current Common/Wind/Brass etc categories? And the playback techniques list in the expression map editor will become unruly once it can be extended too.
I would pay a modest upgrade fee for ‘playing techniques’/‘playback playing techniques’ to be given names that significantly differ from one another It is pretty difficult to talk about this system.
Thanks, that matches my experience after further fiddling around. Am I right in that, once applied, the emaps, playing techniques and playback techniques persist even if you switch away from the template that loaded them?
It would be a shame to limit templates to plugins vs MIDI, given the info they contain. My experience has been that Dorico performs much better if you keep it out of the plugin/mixing game and just talk to Vienna Ensemble Pro via inter-application MIDI. People using VEP have VEP templates with all their instruments at ready and don’t much need Dorico’s ‘load plugin for instrument as you add players to score’ features, but do need ‘violins are on portX+channelY’ etc to be recalled.
That’s been my experience too. I’m IAC routing MIDI from Dorico to standalone Kontakt with happier results than running an instance of K inside Dorico.
We agree that the naming conventions can be a bit tricky, and so we’re now moving to talking about Playing Techniques vs Playback Techniques. Internally, we call the first one Playing Technique Appearances to disambiguate these further. I don’t know what we’ve decided for what to call these in the documentation, but you may find it helpful to think in terms of Playing Technique Appearances vs Playback Techniques.
Each Playing Technique Appearances triggers a Playback Technique, and there may be several appearances for the same playback technique, eg mute can be triggered by a symbol or text (‘con sord’, ‘avec sourd.’, ‘muted’). Expression maps reference the Playback Techniques.
Once you apply a Playback Template, all the Expression Maps in it that are referenced are imported into the project and from that point the project is self-contained. It should play the same way for someone else with the same plugins. However, the situation is less clear for MIDI connections because they are addressed in a different way. I’ll look at how they are used and if there’s anything we can improve for the future.
I imagine “Expressions” too closely approaches Finale terminology. Perhaps if you incorporated the term “trigger” into the visual symbol category would differentiate them from the playback scripting to affect VST responses.
Technique Expressions
Technique Triggers
something like that?
I’m sure your team will come up with the optimum solution.
To be clear I don’t expect a lot of possibility for the interoperability of the MIDI endpoints across users, just for myself internally. If I decide to use playback templates for sharing it will be solely for the emap/playing/playback technique transfer you outlined.
It is pretty difficult to talk about this system.