I hope the Dorico team has some better ideas for articulation management than just copying Cubase’s expression maps. The VSL Synchron strings emap posted above, and the Note Performer emap highlight several problems with using expression maps for articulations.
Failure to map directly to control schemes
While there may at ground truth be a particular sample for e.g. marcato+long+con sordino+non-vib, very few (no?) sample plugins have flat address spaces like that. Instead, they offer more than one control dimension and perform the intersection of controls internally. Some examples:
- In VSL Synchron Dimension strings - mute/string emphasis/articulation/vib and marcato are 5 independent dimensions.
- Orchestral Tools Berlin strings has articulation/mute/vib/accent on 4 independent dimensions.
- Note Performer emap is using 5 CC ‘dimensions’.
So in VSL Synchron and OT, a single CC moves through vibrato levels. A single CC can switch between mutes. Etc. Note Performer is controlling itself similarly. These schemes are semantic and orthogonal, in the same way music notation is about directives and playing techniques.
A system that was co-aligned with this would let you create a ‘group’ (like the exclusion groups, but independent from one another) and an associated set of control messages, sending those messages whenever you transitioned within a group. These should ‘chase’, like other control signals.
Without something like this you have to incorporate a message for every dimension for each emap entry, i.e. 5 dimensions = 5 messages per entry, 5 messages per note. Look at the Note Performer emap for example.
Related to this is the fact that, by creating a single, flat address space, emaps require a number of entries equal to the product of the sizes of the dimensions. So, taking Synchronized Dimension Strings as an example (where I’ve put Norm/Sord into a dimension) we have:
Mute (on/off - 2)
String (norm, open, sulX - 6)
Articulation (36 entries, in 2 synchron dimensions)
Attack (marcato/not - 2)
Vib (4 vib levels)
The product of these dimensions would require a whopping 3456 (2x6x36x2x4) emap entries, each specifying 6 CC/KS messages, for a total of 20736 messages to specify! While not every combo is valid, specifying even a fraction of these is far too many, especially with the tools provided. The XML format is not specified and the XML file is not just about emaps, unfortunately.
Contrast this with a system that allowed us to talk about each group separately - that yields the sum of the sizes of the dimensions, in this case 50 entries (2+6+36+2+4), each specifying only one or two KS/CC messages, for fewer than 100 messages to specify in total to exhaustively cover the options. The plugin already knows how to handle the product of these dimensions, emaps just force us to make every combination explicit and redundantly restate the dimension messages. Such enumeration of combinations should only be required when a plugin does not have more than one dimension of control.
Notion’s rules system allows one to handle directive/technique dimensions separately and is an order of magnitude less work than emaps for a given setup.
Too many messages per note
This is somewhat of an optimization, and memory/chasing could alleviate, but currently a message is sent for every dimension, plus the dynamics CC, before every note. (Notion does the same thing).
In short, Cubase’s emaps have well known scaling issues that particularly get triggered by orchestral sample library use cases. We need something better for notation programs.
Thanks for your consideration.