Playback dynamics issue


I’m playing around in Dorico 2.2 with something I just imported over via XML from Sibelius.

If I have 2 bars of tied whole notes followed by ff, e.g.

p < > ff

then the dim is actually played as a crescendo. It should be clear (implicit) that since you can’t decresc from mp to ff, it should be played as subito ff, not turn the dim into a cresc. I’ve rarely seen subito marked on orchestral scores for this case, as the intention is quite clear.

It’s not obeying in all cases the ff subito either (in brass it does, in winds it doesn’t). Odd.

Is your <> written using a messa di voce, rather than as a < followed by a >? If so, that’ll be what’s up: Dorico doesn’t fully play these back yet.

Hi Daniel. Short answer is I don’t know. I used the popover and entered p<> - I’d expect that to create a < and a separate >. the < does seem to be played.

Also I’m having fun trying to assign dynamics to multiple staves. Often I select a heap of staves, pull up the dynamics popover, and it only assigns to a subset of the staves.

Also, if your zoom level doesn’t show all the staves you’re trying to assign to, then the popup sometimes doesn’t even show (e.g. it seems to be based on screen pos of upper-most selected item, which may be out of scroll window). It should probably just show the popup above the uppermost one which would still result in the popover being visible.

hmmm, looks like it’s putting in mesa di voce. This is indistinguishable on the score from separate < and > unless you click it and happen to notice. Bit of a trap for novices.

Problem is setting a dim on a second tie of a note is really painful… in fact I don’t even know if you can do it with the popover or at all (or can you put a space between the < and > to force it to create separate items?)

ok, spaces seem to help - makes it create cresc and dim.

However playback isn’t honouring the dim to ff subito, it’s doing a cresc instead. Any ideas how to get this playing correctly save editing the automation in play mode?

I’ll need to talk to Paul about this. I suspect that the code that realises dynamics is allowing the immediate dynamic at the end of the hairpin to determine the direction of the gradual change, because of course it uses the immediate dynamic at the end of the hairpin to determine the final dynamic.

Actually I think in general any time you have a cresc or dim it should only take into account an immediately following dynamic if the dynamic is:

a) not marked subito
b) in the correct direction (e.g. bigger dynamic for cresc, and smaller for dim). Not equal.

The direction of < or > should be inviolable.

As for the amount of dim or cresc, it should be 1 dynamic step, or greater if the next dynamic meets the requirements to be considered.

If the following dynamic is in the wrong direction, the dynamic change should be in the correct direction but only for 1 dynamic step, and the following dynamic is implicitly subito.


  1. p < f is a p cresc to an f
  2. p < mp is a p cresc to mp
  3. p < p is a p cresc to mp then subito p
  4. p > pp is a p decresc to pp
  5. p < pp is a p cresc to mp then subito pp
  6. p > f is a p decresc to pp then subito f
  7. mf > ff is a mf decresc to mp then subito ff
  8. p <> ff is a p cresc to mp decresc back to p, then subito ff
  9. p < ff subito is p cresc to mp then subito ff (not p cresc to ff)

etc. etc.

These are how they are played in practice (at least during my time in orchestras).

for mesa voce, then this becomes start dynamic cresc to start dynamic + 1 (or labelled) then decresc to following dynamic as per above rules.

Yes, I would agree with your interpretation of those kinds of marks, but as of today Dorico itself does not!

ah well, should be relatively easy to fix :slight_smile: Cheers

I’ve been working in this field for 20 years, and even after all these years I wouldn’t presume to speculate on what is going to be easy to do and what is going to be hard to do!

heh, me too (C++ software development since 1994). Trust me, this one should be easy if the code is already taking into account starting dynamic, dynamic change type and next dynamic. But you never know… hence the :slight_smile:

Having spent nearly 20 years writing the playback engines for Sibelius and Dorico, even I would not presume this is a easy fix. Daniel is quite correct. It is only possible to have an idea of how simple something is if you are familiar with its design and implementation and the constraints under which it operates.

call me an optimist then, I have faith in your software designers that the current design allows for a simple fix for this.

But I’ve had my own development team for my own product for well over 20 years, so I do know in practise there can be many unanticipated sources of complexity. Anyway this is a side issue.

I also noticed some odd behaviour with adding dynamics (tried adding one to a bunch of staves, it only added to a subset, when I added to the missing ones, it showed double, then triple etc). Some dynamics were there I guess but not showing for some reason, and not clearing.

Thank you.

I am still waiting for the answer of the developer team.

Apologies if I came across a little abrasive - it is a pet peeve of mine when I hear “Oh, I’ve done some programming, this should be easy”, which does happen quite a lot. I do appreciate your belief in us.

no worries! I’m sure such comments from users can grate after a while :slight_smile:

Hi all. I just tried the score again on 2.2.10, as this dynamic issue is listed as fixed.

It’s a lot better but I’m still detecting a slight cresc when all parts are marked decresc.

Is is maybe something hanging over from the score since it was originally imported into 2.2 as XML?

Dear Adrien,
Just wondering here… Have you checked you do not have a compressor on, in the master fader of the mixer (you have to click inserts to check that). This could somewhat modify the perception of dynamics.

As a C++ developer since 1994, you know that the best way for us to investigate a problem is to supply a reproducible case, right…? :wink:

Please attach a minimal example that demonstrates the problem, so we can take a look.

definitely :smiley:

Please attach a minimal example that demonstrates the problem, so we can take a look.

I can’t guarantee it will repro on any other score, can I just send in the actual score and give you the bar numbers (only a few bars involved).

But I was just wondering if there’s a known issue with remembered (precomputed and stored) velocities or something, e.g. would it be fixed by re-adding the dynamics etc.