Expression Maps

I can’t provide any specific timetable. All I can say for sure is that they will not be implemented in the update we are currently working on.

I can’t provide any specific timetable. All I can say for sure is that they will not be implemented in the update we are currently working on.

:cry: :cry: :cry:

Would it be possible to get a precise statement about what does and doesn’t currently work re: expression maps? These statements to the effect that ‘not everything works yet’, e.g. ‘etc’ above leaves it to every user to waste time discovering the current status when I presume you developers know exactly. I understand it’s not finished but you put in UI that doesn’t work so please help us out by being precise. Thanks!

Steinberg with Dorico is doing the same as Apple with Logic, doing a great job but not listening to users needs.
Notes Head editor was less important than Expression Maps
Daniel, why dont you provide a list of futur features so we can vote ?

Dear Cyril,
Do you think that ALL users read this forum on a daily basis? Do you REALLY believe that your needs are the same than other people’s need? If I may, I find your last post quite inappropriate, for Dorico’s team has proven enough that they DO listen to our needs.
I’m no developer myself (but with an engineer level, I think I’m not mistaken), but I’m quite confident that implementing the notehead editor and fulfilling your dreams about expression maps are two very different tasks. No pun intended. But please keep a respectful tone in this forum :wink:

Oh come on.

Not only do they listen, they take the time and trouble to comment on almost every thread here. When have you ever known the Apple development Team to do that?

Marc’s post nails it but I’d like to add one thing, While Daniel and the team are very open in this forum, it’s all too easy to forget that there’s a competitive market out there for notation software. Showing your competitors your hand by publishing a list of future features isn’t the smartest move and, worse still, it will build up expectations among users to the point where dealing with those expectations becomes an issue and takes valuable time away from development.

Have faith. What they’ve done so far is excellent and there’s a lot more to come.

This has been discussed to death elsewhere on this forum. READ THE FEATURE LIST BEFORE YOU BUY. If you can point to a feature that was claimed to be present in a certain build but wasn’t actually there, then you have cause to complain. If the current feature list doesn’t match your needs, you’ll need to explore other options for your projects.

Proof that no matter how superior a product is to other options, someone will complain that it doesn’t have what they want.

I do respect developers ; I have been one !

I did say “Daniel, why dont you provide a list of futur features so we can vote ?”

What is un-respectful ?

I found

Steinberg with Dorico is doing the same as Apple with Logic, doing a great job but not listening to users needs.

quite inadequate, but you’re right, it was not un-respectful :wink:


I’m excited about the workflow that Dorico’s playback engine will bring once it’s developed a little more. I too am anxious to have more control over score interpretation as a user, to be able to fashion my own techniques, have fall-back sounds, fully control libraries that use players other than HSSE, etc.

The Dorico Team does listen to users. We asked for a status lane to help test and trouble shoot our expressionmaps, and they gave it to us. We asked for controller lanes as an option we can use NOW for more easily and intuitively entering expressive data (it was pragmatic and simple…until we get a more advanced technique maker, and fully implemented expressionmaps), and they gave it to us. The people who are actually putting scores in front of publishers and world renowned orchestras/bands/vocalists DID ask for custom note-heads…and they NEED them more than they need a simulated audio mock-up.

There are long lists of things users are still ‘asking for’…and most of it will certainly come in due course. It’s on the giant white board of ‘stuff to do’.

The thing is, I also use Finale, Sibelius, MuseScore, and CuBase Pro (Score Module) pretty regularly. I make fairly deep playback expression templates for them where possible, it’s NOT EASY (putting information in is, but getting it sound good in a score is a different story), nor are any of them ‘complete’. They’ve been around for decades, and they all have some issues with setting up and implementing interpretive play back as well. There are simple things (some even constitute true bug fixes) we’ve been asking for in Sibelius Soundworld, and Finale Human PlayBack for more than 10 years that simply go ignored.

Third parties have stepped in to help those who don’t care to make their own interpretive maps by offering pretty expensive supplemental libraries and plugin kits, but those did not happen over-night. Dorico will eventually get some third party love at a price as well.

I’d rather Steinberg take their time to a reasonable degree, and do it RIGHT this time. I’m glad they have the place-holders for exclusion groups, velocity and transposition modifers, and range limits in the UI expression-maps (even if they all aren’t yet functional). It just makes sense to we CuBase users. If things are done right, it’ll be fairly easy to port maps between Dorico and CuBase. Over time…we’ll begin to see the full implementation of the expressionmap system. The ‘foundation’ for the playback engine seems to be in place, but it’s critical that the Dorico team really does their homework and deep testing on how to best take advantage of it before releasing stuff to the public.

The note-head editor can actually be considered a prerequisite to much of what the expressionmap system is capable of doing for us. A different shape showing up on a score typically means you’ll be using some alternate technique or style to play the instrument or sing. These may well be prime candidates for making deep and extensive use of an expressionmap.

There will be other types of editors and markings that’ll need to be tied somehow into the interpretive engine as well. So it makes sense if the team wants to get much of it in place on the visual score, well mapped out and understood, before they tie it all to the expressive playback engine.

They’ll need to map out and document some standards, or best practices for how to best build such expression maps (what takes precedence, and how to fall back to the next most reasonable sound if something is missing, etc.), and all that is rather difficult to do until you actually have the stuff showing up on a Dorico Score where you can reason things out and run the tests.

Sure, they probably have flow charts as big as my house explaining the ‘theory’ of how it should all tie together as a finished product…but implementing it all takes time, and has to come in stages. Sometimes the real-world forces adaptations to the theory and the ‘get it done’ schedule (where programmers are given specific projects).

Consider that they need to first:

  1. Build input and engraving features, for both the score writing and play tab modes.
  2. Make sure those features are solid, predictable, and consistent (usable).
  3. Optimize them to be efficient/fast across multiple platforms and hardware setups.

It makes sense that the playback features will come in cycles that are a few stages behind the score making stuff. Since the scoring side of this product is a brand new app from the ground up, and it is massive in scale of what all it is trying to do in such a short amount of time, I believe this dev team needs, and deserves a little wiggle room on the expressionmaps.

Again, I’d rather them take a little longer making the hooks into the playback engine and DO IT RIGHT, than just rush something out here that goes on for decades full of bugs, and a lot of dead-ends for library developers.

If they get this right…it will be very flexible and powerful. Users and library developers will have plenty of options to come up with just about anything imaginable. If they get it right…98% of the things we’d typically ask for in ‘feature requests’, we users will be able to build and share with each other ourselves! It will also be the leading Scoring Engine setting the standard for things VST3 and beyond.

I am sympathetic to the request for clarity on what works and what doesn’t in the Expression Maps dialog.

The options in the group that contains the ‘Transpose’ option are all as yet non-functional, except for ‘Transpose’, which is functional. The ‘Has exclusion group’ controls are non-functional. Otherwise, all of the controls in the dialog are functional: however, this is not in itself massively helpful information, as the real complexity comes in the way that the various playing techniques are actually generated and played back in the score. You cannot, for example, create expression maps for dynamics as you can in Cubase. The options for whether an expression should apply only to the current note or ongoing until a countermanding expression aren’t yet implemented. Dorico can’t currently make the connection between a playing technique you enter in the score, like a harmonic, and the durations of the notes underneath it in order to create the appropriate playback region. And so on.

I know this is very frustrating, because it’s hard to tell what works and what doesn’t. We are just as frustrated as you are about it: we are giving work on the playback side of the program a very high priority, but there is still a limit to what we can achieve. We have added so much useful functionality on the playback side of the application recently (NotePerformer support, video, MIDI automation, swing, etc. etc. etc.) and there is more to come, but at the moment, for example, I can tell you that working on real-time input from a MIDI keyboard has a higher priority than working on the expression maps side of the program. It’s easy for me to ask for patience, and I understand that you are paying customers who want and need functionality that doesn’t yet exist, but I hope you can see that we are at least not sitting around twiddling our thumbs, and even if you may not agree with every one of our prioritisation decisions, we are working hard to add features as quickly as we can while still doing a good job.

Regarding a list of features to vote on, here is a simple and short answer: no.

I know I’m a little late to this party, but as a user mentioned earlier in the thread, I am also an owner of large amount of spitfire’s libraries and would be over-the-moon happy to be able to write in Dorico with my spitfire libraries.
I know what expression maps are, but I have absolutely zero idea about the workings under-the-hood.

What often seems to happen in discussions like these is that the conversation jumps to an advanced level very quickly, and leaves us unlearned folks out.
I would be very willing to make expression maps for Dorico, and share them on the forum, of many Spitfire products, but I would need a nice, concise primer on the subject.

If anyone can point me to a good resource, or spend the time to write one, I’ll get down to spitfire libraries.


This is really good place to start.

That’s useful information, thanks Daniel!

At no point did I complain that Dorico did not have what I want. Did you read what I said before ADMONISHING me with your ALL CAPS? I asked for clarification as to what does and does not work because, in spite of reading all the threads on expression maps here, it’s still unclear.

As to what’s promised - this is from the Dorico_21_Deatiled_Feature_List.pdf (which I read)

§ Playing techniques result in changes of VST Expression Map
§ Built-in editor for creating and editing VST Expression Maps, including import of existing
Cubase Expression Maps

And in the documentation, (which I also read), there are many imprecise caveats:

Although the format of expression maps in Dorico is similar to Cubase, Dorico cannot handle expression maps in exactly the same ways as Cubase. For example, Dorico allows you to use more playing techniques, but Cubase can reproduce more combinations of multiple playing techniques.

During playback, Dorico does not currently support all fields in the Expression Maps dialog. This is planned for future versions.

Although settings are imported into the Technique Controls and Exclusion groups from Cubase, Dorico does not currently implement all the information. This is planned for future versions


Asking for clarification is not complaining. It’s trying to develop a shared understanding, in an effort to reduce frustration and manage expectations.

Finally, Daniel has acknowledged the lack of clarity and the resulting frustration, on both sides.

What does your post add? Nothing.

Rich: you’re right, I failed to read your post carefully, and in doing so, misrepresented your position. Apologies.

That’s gracious of you - accepted!

Hi there

has anybody adapted a Cubase expression map for VSL Apassionata Strings?

I have had a quick look at the cubase expression map import from VSL and see there is a lot to do so thought it would be best to ask here first



I’ve found that I’ve needed to use “nat.” to reset keyswitches in other Notation softwares that allow custom “expression maps” (like Notion 6). The ultimate tool for me was moving from Keyswitches to Midi channel and CC patch changes. The issue is that Dorico does not yet allow for CC and Midi Channel changes for individual expressions. Once Midi channel switching and Midi CC triggers are implemented then I can see some of these issues being solved on their own.

As has been mentioned the ability to change midi note length (for slurs, etc.) is also important for triggering different sample patches.
This could be set to

set flag: legato/port. etc.
unset flag: …
send midi channel: 2
Midi CC #3, 127
change note length: +50%

Convoluted, but that’s what gets these things functioning properly

Any news on when these abilities might be implemented in expression maps?

I posted a version in this thread in July of last year.

It contains more than just the strings maps. Also, the strings expression maps will work with any of the VSL string libraries except for Dimension Strings.