Secondary dynamic values not updating correctly in expression maps dialog

There is something very weird going on my expression maps dialog: it seems that the secondary dynamic values are not graphically updated correctly.

Here is a video that shows the problem:

I get different secondary dynamic values going up and going down! Could it be that my expression map is somehow corrupted and the problem would be fixed by doing it all over again? Now I’m left wondering that what those values actually are, which makes things a bit complicated…

Perhaps you could attach a project file containing your expression map, or at least export a .doricolib file containing your expression map (which you’ll need to zip up before you can attach), and then we could take a look. It may be that when you move from one switch to another that switches between the Note velocity and Control change options, the values for the Min. and Max. fields aren’t correctly updated?

I’ve never seen anything like this – it goes so quickly it’s rather hard to follow anyway – but it’s certainly true that in certain situations, not least of which is the secondary dynamic, that values put in there are not always reliably updated. This seems more commonly the case when working on several maps at once, then trying to save all the changes. It can also occur that you may make mistakes with individual entries as the field which seems to be selected is not always the one you click on - there are still one or two little bugs to be sorted in this area. Bulk selection of fields is useful but the only way it works reliably is to click the first entry, then hold shift and click again as if to confirm it and then, continuing to hold shift, click the last entry.

If you are finding any behaviour like what I’ve described then it might be a contributory factor but I wouldn’t entirely rule out corruption either – happened to me at least once though the most recent releases of Dorico seem generally more stable than earlier in the v3 series.

1 Like

This is excatly what happens! Here is the corrupted expression map:

CSS - VEPro Expression
(3.8 KB)

It still works fine, I just need to be careful when editing it. So no need to fix it for me!

But maybe it could be useful for preventing this from happening in the future. I’ve edited, duplicated, imported and exported this expression map many times - so I guess there have been many changes for it to go corrupt.

@SampoKasurinen I’m having the exact same problem. Are you saying that the expression map still works properly in playback, but just that the incorrect values are displayed? I’m on the verge of scrapping all my expression maps that I just spent the entire weekend working on and starting fresh. If you found a solution, I would be very interested to know!

On a related note, I’ve been using the secondary dynamics extensively because of the bug that playback option overrides can only be saved as whole integers. My solution has been to make a separate switch for accents with a raised minimum value for CC11, which seems to do the trick, except that they don’t update correctly. So basically, one bug has led me to another bug.


It’s a long time ago I was struggling with this, so I don’t remember exactly how it behaved…

My solution was to make the expression maps as simple as possible and rely more on manual editing, as it turned out to be more efficient that way. I hope in future more tools for that kind of workflow are added, since it feels sometimes a bit overkill to go trough the whole process of adding a playing technique, a playback technique and a new entry to the expression map just to put in for example a single keyswitch.

It’s while since this bothered me, I think partly because I found a way to get round the buggy selection of patches reasonably reliably, after which I didn’t often see the issue. Perhaps the (I assume) final release of v3.5.12 behaved more reliably in terms of correctly saving multiple changes as well. Perhaps at this stage, as with other slightly murky little irritations of this nature, it’s best to simply wait and see if v.4 changes anything.

I’m also interested in whether the new mixer and other playback tools in the iPad version which have been promised for v4 will reduce the need to go into such detail in the EM. To be honest, for me it’s not a major hassle adding a new EM entry and new p.t entry for something which will be used a lot.

Yes, that is true! I’ve just noticed that there are some things I’ll do just once for a project - in these cases efficient manual workflow would be very nice.

I agree, after spending ages working on an EM I’m still doing tons of manual editing anyway. Oh well!