Hello! Did Dorico accept the metrical faults in bars 328 and 332?John Ruggero wrote: 18 Sep 2026, 19:08 [...]
However, it has many capabilities beyond Finale, and I put up with the "help" for the sake of the increased capabilities. For example, the following slurring would have been impossible in Finale:
Scarbo.png
Dorico…to be or not.
- Magnus Johansson
- Posts: 272
- Joined: 07 Oct 2025, 10:51
- Location: Sweden
- Contact:
Re: Dorico…to be or not.
Igor Engraver 1.7 via CrossOver on Debian GNU/Linux or Q4OS.
-
Mr_Incognito
- Posts: 54
- Joined: 11 Apr 2026, 15:08
Re: Dorico…to be or not.
Any particular reason?
[/quote]
Plethora.
To start with - who is in the most stable position in the long run? Not I who went for Finale. Those who mastered open source stuff (Lilypond, MusiXTeX, Frescobaldi etc.). Nothing has changed for them, and won't change, unless they decide so. No unwanted "transition", conversion, re-editing. Everything always where left, with output potentially second to none.
Not to mention that they are the most flexible ones when it comes to selection of OS, and hardware.
-
John Ruggero
- Posts: 3059
- Joined: 05 Oct 2015, 14:25
- Location: Raleigh, NC USA
Re: Dorico…to be or not.
Hi Magnus. I had to do a lot of finagling to make it adhere to the original notation that's for sure. But that would have been necessary in Finale as well. An augmentation dot for the upper note of the bass octave got partially covered by the natural sign in m . 332. I will need to fix that. Thanks for pointing it out if that's what you were referring to.
M1 Mac mini (OS 12.4), Dorico 6, Finale 25.5, GPO 4, Affinity Publisher 2, SmartScore 64 Pro, JW Plug-ins, TG Tools, Keyboard maestro
Re: Dorico…to be or not.
I've gone from Dorico 3 to the very latest version, and never had to make any changes to my scores.Mr_Incognito wrote: 23 Sep 2026, 21:46 To start with - who is in the most stable position in the long run? Not I who went for Finale. Those who mastered open source stuff (Lilypond, MusiXTeX, Frescobaldi etc.). Nothing has changed for them, and won't change, unless they decide so. No unwanted "transition", conversion, re-editing. Everything always where left, with output potentially second to none.
So I have NO idea why you're bringing up "transition", "converting", and "re-editing".
Everything is always exactly where I left it.
This seems to demonstrate that you are rather unfamiliar with Dorico.
- Magnus Johansson
- Posts: 272
- Joined: 07 Oct 2025, 10:51
- Location: Sweden
- Contact:
Re: Dorico…to be or not.
OK. Yes, you're welcome; that and the too many 64th notes in bar 328.John Ruggero wrote: 23 Sep 2026, 22:31 Hi Magnus. I had to do a lot of finagling to make it adhere to the original notation that's for sure. But that would have been necessary in Finale as well. An augmentation dot for the upper note of the bass octave got partially covered by the natural sign in m . 332. I will need to fix that. Thanks for pointing it out if that's what you were referring to.
Igor Engraver 1.7 via CrossOver on Debian GNU/Linux or Q4OS.
-
John Ruggero
- Posts: 3059
- Joined: 05 Oct 2015, 14:25
- Location: Raleigh, NC USA
Re: Dorico…to be or not.
The final group was easily handled as a tuplet in Dorico, Magnus. I didn't add an editorial tuplet indication because it is not in the first edition, which was presumably intentional. Whether the 32nd rest is a mistake for a 64th rest is an open question. An argument might be made either way. Here is the original:
M1 Mac mini (OS 12.4), Dorico 6, Finale 25.5, GPO 4, Affinity Publisher 2, SmartScore 64 Pro, JW Plug-ins, TG Tools, Keyboard maestro
- Magnus Johansson
- Posts: 272
- Joined: 07 Oct 2025, 10:51
- Location: Sweden
- Contact:
Re: Dorico…to be or not.
OK, did you input the 64th notes as triplets and then removed the 3's and hooks? A 64th rest doesn't solve the problem so it is likely Ravel meant triplets, don't you think so?John Ruggero wrote: 24 Sep 2026, 13:18 The final group was easily handled as a tuplet in Dorico, Magnus. I didn't add an editorial tuplet indication because it is not in the first edition, which was presumably intentional. Whether the 32nd rest is a mistake for a 64th rest is an open question. An argument might be made either way. Here is the original:
Scarbo 1s edition.png
Igor Engraver 1.7 via CrossOver on Debian GNU/Linux or Q4OS.