Dorico's additive Playback Articulations

Dorico
,
#1

I have been baffled for some time trying to determine why I cannot get certain articulations to sound let alone the right ones even when correctly defined. The answer was found when in Play and clicking on the the Playing Techniques and hovering the mouse over each of these techniques to read the popup before it disappears (wish it would to stay up longer!) This is massively helpful in determining which articulation(s) are to be played. Now suppose a the score is written with several successively different articulations at different points in the Violin 1 in BBCSO Pro, such as:
Nat
Sul Pont
Col Legno
Snap Pizz
Sul Tasto
ā€¦that by looking at that popup for Snap Pizz, Dorico shows the articulations to be played simultaneously are Snap PIzz, Col legno, & Sul Pont. and no articulation at all for where Sul Tasto should be. Clearly Dorico is trying to apply all these articulations together until it is becomes impossible, as in this case when Sul Tasto is encountered.

So what to do about this. The only solution Iā€™ve come up with is to insert Nat. before each change in articulation as this seems to be a ā€œresetā€. Or is there some way to turn off this additive articulation behavior?

#2

You should make sure that these playback techniques are all in the same mutual exclusion group in your expression map. That tells Dorico that they are not cumulative, but rather that only one of them is valid at any given time.

1 Like
#3

I had the same snag with choir articulations, but what you suggest fixed it Daniel.

#4

Thanks Daniel, this is indeed the solution. So now I will go back do this all my expression maps. It will be tedious with 100ā€™s of expression maps, but 99% of the time I would have no use for this cumulative feature. It would be nice if there was an option to turn this OFF.

#5

Actually, I have some sympathy for this point of view. it is generally nonsensical to combine these sort of p.tā€™s (what are called ā€œdirectionā€ techniques as they continue until told to stop as opposed to ā€œattributesā€ which only apply to the note they are attached to) and of course there will very rarely be a special technique to support them anyway ā€“ certainly isnā€™t in the articulation light BBC orchestra.

However there are perfectly valid reasons for having two (or conceivably more) more techniques operating simultaneously. Suppose you have for instance all techniques that can also be played ā€œcon sordinoā€. While very often in this sort of situation, you can set the constant as an add-on entry there will be in some instances exceptions. A blanket ban on combined techniques could easily have undesirable consequences. I personally tend to make liberal use of the mutual exclusions and it really doesnā€™t take long to set something like that up in a map.

#6

Dorico 3.5 will automatically create these mutual exclusion groups for you, so you donā€™t need to think about it, unless youā€™ve deliberately interfered with the settings in the expression map. If youā€™re finding that you have to create these mutual exclusion groups manually, it suggests a deeper problem either with the specific expression maps youā€™re working with, or potentially with your workflow and the steps youā€™re taking in the Expression Maps dialog.

#7

of course what Daniel says is correct but I donā€™t find the auto lists are necessarily comprehensive enough, particularly with more complex libraries. But yes, remove the AUTO flag so you can see the entries and decide for yourself if what you require needs further additions and modifications.

#8

The auto mutual exclusion groups are just generated for some of the common techniques that Dorico knows about, where we also know that only one technique in a group can be active at any time, eg pizz or arco, harmonic mute or plunger mute, open or closed, etc. Beyond that, Dorico has no way of knowing for any particular library whether techniques can be played at the same time, hence you have to tell it by defining your own mutual exclusion groups.

#9

exactly my point! And of course many of us create our own custom p.tā€™s and thereā€™s no way Dorico can be expected to know about these.

#10

Just some thoughts about mutual exclusion: Shouldnā€™t it have been implemented the other way round?
I mean every technique would be mutual exclusive and you add those that arenā€™t.
Like sul pont + stac, con sordino + legato, ā€¦
They make more sense to me.
Working with custom techniques, I get the feeling this would be less work.
Or am I missing somethingā€¦

#11

The add-on entry would indeed be a nice solution, but the add-on seems to be sent as last one of the events. Doing channel switching with the add-on made this impossible in my case, because this should happen before the other events.

#12

In a world without slurs, perhaps your way would be quicker. In a world with slurs, though, I imagine it would be a real pain to have to set up a bunch of mutual inclusions for x + legato.

#13

Youā€™re probably refering to the phrasing slur, for the playing technique slur I donā€™t see too many options. Maybe we should have 2 types of slurs.
The reason for my frustation about the mutual exclusions is that at some point you always get stuck and you have to workaround the problem.
What I mean is that by adding a (new) mutual exclusion for some new articulation, you could end up breaking other articulations.
If everything was mutual excluded than you need to add a new articulation combination whenever you needed a custom playback, the advantage is that it keeps the other articulations 100% working.
I think of it like security: You keep everything locked and open up specific points when needed, so it secure all the time. You donā€™t work the other way round.

#14

Iā€™ve a practical case that I donā€™t know well how to solve. First of all, can we have two add-on techniques at the same time? This would change the way I plan a solution.

I have a few cases of switches added to a basic one. For example:

a) A general switch to choose regular, sul pont., sul tasto groups of articulations.

b) A local switch adding a deeper choice, for example with recorded crescendo as the basic technique, and the length in seconds as the additional choice.

Iā€™m currently using add-on techniques for the first type of choice (a). I wonder if a direction-type basic technique would be a better idea.

And Iā€™m thinking to an add-on technique for the second type of choices (b), where the add-on would be the length.

Being able to have two add-ons at the same time would maybe make the regular, sul pont. etc. selection viable with an add-on technique. If it is not possible, this first selection should probably become a direction-type basic technique.

But then, will it interfere with other basic techniques? Maybe being sure these choices are only in their dedicated exclusion group can make their action safe.

Paolo

#15

surely the way add-on techniques will work is very much library dependent? Which library are you currently using? Providing that an add-one does not conflict with another one, I see no reason why you cannot have more than one running at once. The example of sul pont and sul tasto will depend on whether there is a particular switch level in the library tree which changes all articulations to this ā€“ in which case use add-ons, or whether there are just a independent few variations which are part of the main branch in which case a general switch would be fine. Many libraries are one dimensional but I guess youā€™re not talking about this here.

#16

Yes, thatā€™s true. And I was probably writing with VSL Synchronized Dimension Strings in mind. As one of the richest (maybe the richest) sample library, itā€™s probably a good practice for any other library.

The ā€˜Positionā€™ (regular, sul G, sul pont, sul tastoā€¦) add-ons shouldnā€™t conflict with the ā€˜Durationā€™ (1st duration, 2nd durationā€¦) add-on. So, maybe they can be add-ons, and not direction-type basic techniques.

Iā€™ve worked a lot on the SYzd Dimension Strings map, because of the complexity of this duty. Itā€™s growing, a piece at a time, and now I will try to solve this further issue.

Paolo

#17

yes, the Dimension strings are a good candidate for add-ons and in fact I wondered if you possibly had that in mind. Iā€™ve done maps for my own SE version of the Dimension strings but donā€™t have the full versions

#18

Eh! The full version, in my preset, is something like this:

image
image1380Ɨ516 128 KB

The map is not less impressive, either.

Paolo

#19

just five columns for the Special Edition.

Dimension strings SE
Dimension strings SE998Ɨ472 252 KB

Itā€™s probably obvious here that both the player column and the sordino are independent of the standard VSL articulation and type columns and should be add-ons. Thatā€™s how Iā€™ve programmed them.

1 Like
#20

Dimension strings
My template:
Players, technique and string, all are add-ons which reduces combinations of the playing techniques considerably
Div a2 and a3 used on different voices when dividing strings.