One big Dorico 5 feature request re: controlling tempi!

Was just mentioning this in the Scoring Notes comments so thought I’d mention this here. I’d love to be able to select any shift-T type tempo indications I may have added to Dorico Pro (such as “rit.”), select what I’ve added, choose “Suppress Playback”, and have it actually NOT affect the score. The reason I say this is because I’m constantly working from DAW to notation by bouncing the finished DAW audio file; exporting the MIDI from the same DAW session and then importing the MIDI into Dorico Pro to start the notation phase; attaching that bounced audio file to a static movie image, then attaching that video file to the same Dorico session. It’s still a strangely unnecessarily complicated workaround (PLEASE add the ability to just directly attach an audio file!) but it results in rock-solid locking of the audio from my DAW with the MIDI I’m further editing in Dorico.

The problem, though, is that any "rit."s I add via shift-Tempo (even if I select them and choose “Suppress Playback”, STILL affect playback, which ruins the tempo map lock! As a result, I recently had to spend much extra time with an orchestral score manually inserting system text “rit’s” and dotted lines, etc. instead onto each individual part (so they wouldn’t affect the tempi).

Please fix this if you can, and thanks as always for Dorico Pro (which is even more amazingly powerful with Note Performer 4 and - in my case - BBC Orchestra Pro).

D.D. Jackson

1 Like

Just a thought : if you select a rit., check the properties and modify the percentage from 75 to 100%, wouldn’t that solve your problem? Then alt-click that rit. wherever you need and you’re done…

If you are not interested in changing tempo, then don’t use a tempo mark!
You could for example define a line as *rit…*with the appropriate continuation and system attach it.

I’m referring to having it stay fixed to a MIDI tempo map I’ve imported from my DAW (which is why I was suggesting being able to set the tempo elements to “Suppress playback”). Best -
D.D.

Let me check! I’m just surprised because the program allows you to select the “rit.'s” and choose “Suppress Playback” for them but it doesn’t actually work - the tempo is still affected relative to the tempo map/synced video (feels like a bug?) But your suggeestion might be a workaround (fingers crossed) so thanks.

[UPDATE]: the issue with this is that I can’t reliably enter a “final tempo” value (so: “rit.” then a dotted line, then “(q=50)” at the exact point I want the final tempo value to be indicated - I still would have to enter the final tempo part by hand since otherwise it would affect playback, and because it’s a tempo map it’s synced to it would be hard to enter the exact amount that wouldn’t cause the tempo to fall out of alignment. I may also be using a non-linear rit. in the audio file that also wouldn’t line up (so basically any change messes up the audio file sync).

It feels like the simplest solution user-interface-wise would be to allow me to hit shift-T, enter “ritardo” and be able to enter the final tempo (and have it display “rit”. a dotted line and (q=50 at the end-point), then select it all and choose “Suppress Playback” and have it prevent the playback from changing (so a feature request!)

This seems to work for me: Select a Tempo Mark, click on “Supress Playback”, and the tempo mark is ignored.

You can even Suppress on Repeat Passes. The suppressed tempo is greyed out on the screen (but prints out).

Whenever I do that and I have a video attached with audio my Dorico tempo map is synced to, they still fall out of alignment.

I get the same results as Ben - if a ritardando has “Suppress playback” set then it doesn’t affect the tempo for me. There’s a known problem with relative tempo changes (“Lento” etc) but I don’t think that that’s what you’re asking about, unless I’m mistaken?

Try it with a synced video file. It throws it off so the two go out of sync even it’s doing “some” suppressing. When I get a moment I’ll try and demo.
Best -

  • D.D.

Strange - I just did a test and tried to re-produce the problem but haven’t been able to. I’ll let you know if it crops up again (!)…