That would be handy, yes... Dorico already knows on which note a slurs ends, as it knows where to put the next articulation change
Maybe Off Events for legato is where we shall look next...?
Sibelius likes to tag these with a 'portato' node. While I disagree with calling the node 'portato' (it would make more sense for legato+tenuto), it's nice that it gets a dedicated node.
In the interest of more quickly getting some easy to use, yet advanced expression map sets out there for people who are more interested in 'composing' than fiddling with plugins and expression maps...
Until such time as we get the ability to add our own custom nodes that are 'easily importable' as a default startup slate for users, I'd much appreciate adding the following nodes to go with 'staccato'. These need to be 'sticky' nodes, that act in a similar way as arco/pizz, or con/senza sordino.Run
(This node would be helpful to lock and load a less vibrato laden arco sound that is suitable for really fast legato/scale type runs. We don't want the 'attack' up/down stroke sound of the bow biting into the string for these types of passages! The bow is already in motion at full speed, strings are already vibrating as finger simply slides to a new note, and even with a string change, the bow is already at full speed, so there's not as much of as sharp 'attack phase' to the transition. It really needs to be different from a typical legato attack as well...it should be at fuller amplitude from the very beginning...not 'crossfading and swelling' up to volume over time as most bog standard computer generated arco string sounds do these days...it's not hard to do better at this with almost any string library on the market...we just need the node.)NoRun
(Drops the Run node)Stacc [Ex Group 1] (Sets a Stacc Node)
NoStacc (Simply drops the Stacc node)LStacc [Ex Group 2]
NoLStaccSpicc [Ex Group 1]
NoSpicc LSpicc [Ex Group 2]
NoLSpiccSaut [Ex Group 1]
NoSautLSaut [Ex Group 2]
NoLSautMart [Ex Group 1]
NoMartLMart [Ex Group 2]
NoLMartDeta [Ex Group 1]
NoDetaLDeta [Ex Group 2]
NoLDetaPort [Ex Group 1]
Here is why these nodes (or something similar) would be very helpful to have in the near future.
With such tags, we could set a myriad of default interpretations at the beginning of a stave, where they'll 'stick' until we want to change them to something else. Our expression map would look something like this:Staccato
(default generic staccato...typically the regular arco sound but with half duration)Staccato+Legato
(default sound for staccato notes living under slurs, typically some flavor of martele or sautille)Staccato+Stacc
(If the Stacc node is set, this sound gets played for lone staccato notes)Staccato+Legato+LStacc
(If the LStacc node is set, this sound gets played for staccato notes living under slurs)Spiccato
(Default Spiccato sound, if there is no Spicc node)Staccato+Spicc
(If the Spicc node is set, this spiccato sound gets played for lone staccato notes)Staccato+Legato+Spicc
(If the Spicc node is set, this sound gets played for staccato+legato notes)Martele
(Default Stand alone Martele...)Staccato+MartStaccato+Legato+LMartSautilleStaccato+Legato+SautStaccato+Legato+LSautDetacheStaccato+DetaStaccato+Legato+LDetaPortatoTenuto+PortTenuto+Lportrun
Why go to all this trouble in an expression map?
It makes it so one doesn't have to tag every single note in a piece for alternate bowing. It reduces how often we must send a "nat." technique to 'clean the slate' and rebuild the node-set on our in-score staves. At first, this doesn't seem like all that big of a deal, but when we start adding things like mutes, portamento settings, etc...then it becomes rather helpful to be able to simply drop individual nodes rather than doing nat. and starting from scratch rebuilding everything else.
At the beginning of your stave you simply drop on the following techniques and either give them 'custom text' to show on the score, or simply hide them from view (Presently we'd just set the alpha channel to zero to hide it):
Now all staccato notes in quaver are going to be played Sautille, while all the staccato notes that are NOT in quaver are going to be played Martele.
Next imagine that several bars into our piece, we decide we want staccato in quaver to change to Martele, and stand alone staccato to become Staccato until instructed otherwise. All we'd need to do is drop the following techniques into the score at the first note of this passage and hide them from view:
Now we're good to go until we want another change many bars later.
From this point (unless we ALSO get some sort of exclusionary group that'll keep the percussive node lists seperate from the arco ones), to deal with things like percussive articulations, we've got a couple options.
1. Put a 'nat.' technique on the stave to clear all the nodes, and then put our pizz. col legno, or whatever.
2. Get Exclusionary Groups
for individual nodes of a combi-technique implemented, where only one node of a given group can be active at a time. Such nodes 'replace one another' instead of being tacked onto the node-list.
3. Keep adding redundancies (use same, or even variations of pizzicato sounds) to our list of technique combos in our expression map like so:
Ideally, it'd be nice if we we could eventually make it so certain individual nodes can supersede others (exclusionary group). I.E. Entering Mart would automatically clear Stacc, Spicc, Mart, or Saut, etc. (anything in the same exclusionary group) and simply replace it. That would prevent users needing to manually clear out conflicting nodes, or needing all the redundant expression map entries (They could just enter a single technique and not have to manually clear anything); however, even if we don't get the exclusionary groups anytime soon, just having access to the extra nodes sooner, rather than later, would be a big help in making a giant stride towards making the HSO Library that comes with Dorico very musical indeed (with some new presets that better tap the Library's true potential). Until we do get the exclusionary groups in working order...we can just have tons of redundancies in our expression maps, and they'll keep on working far into the future even after we get the new features (and can contemplate offering better/updated versions of expression maps).
Already, as things are TODAY, I can already partially implement this sort of plan. I just have to borrow alternate techniques like 'snares on, snare off'. I'm not yet aware if there are enough of these sorts of toggled techniques on the board to really do it justice (plus it would require all sorts of awkward and less than intuitive documentation to teach folks how to use it), but there's enough working to show proof of concept (I'll email a working score to John for analysis once it's ready).