I really wish a new option for no tuplet brackets would be added. The show only when necessary option basically doesn’t work. As I use a lot of beamed tuplets, the beam is adequate with no brackets needed. When you have a score full of these it’s very annoying to have to remove the brackets by hand.
Accidentals. This mostly applies to the 0 key for naturals. When inputting I’ve had situations in which a flatted note may precede a natural of the same note and when I hit the 0 key the pitch changes but I don’t get a natural. Also, if I have a flat or sharp I can hit the - or + keys to make the accidentals show or hide, but the the naturals. It doesn’t matter what preset I use. Again, makes for a lot of extra work.
Richard, you need to provide a bit more context about your request for tuplet brackets. In what way does the current option not work? As far as I’m aware it works exactly as designed. Perhaps you’re expecting it to work also for secondary beamed groups, or something? But without more specifics I’m afraid I can’t help.
The accidental shortcuts are not designed to force an accidental to appear: they are merely designed to apply an accidental to the note, and the program then figures out whether or not that accidental should appear based on the musical context. Perhaps what you need is the ability to assign a shortcut to a command to force an accidental to appear. We could do that by adding something by hand to your key commands JSON file, though there’s no way to do this directly voa the Key Commands page of Preferences.
Daniel, I would love to be able to show/hide accidentals via a key command, if you’re offering.
You’d have to use two key commands, because you can’t toggle a property to different values using a single key, but the following incantation should work.
To hide an accidental:
{
"UI.InvokePropertyChangeValue?Type=kNoteAccidentalVisibility&Value=kHide": [ "Alt+H" ]
},
To show an accidental:
{
"UI.InvokePropertyChangeValue?Type=kNoteAccidentalVisibility&Value=kShow": [ "Ctrl+Alt+H" ]
},
I would recommend putting these in the kMusicEditable context within the JSON file.
If I may butt in: what I’d really love was for a way to call on scripts relatively fast. The Properties panel is contingent on the selection, and as such it is only “navigable” via macros. As of now, you have to go through an Open file dialog in order to call on saved macros. If these were exposed in a menu, for example, one could bind them to an AHK/Keyboard Maestro routine or even to a native shortcut, if the team finds that acceptable. This would make stringing complex actions or manipulating properties much faster.
Yes, we agree that being able to automatically load macros from a folder and add them to a menu would obviously be a million times better than what we currently do. It’s not something we’re going to be able to tackle in the forthcoming update, however.
Thanks Daniel, much appreciated.
Here’s an example. The tuplet setting in engrave mode is set for “show only when necessary”. Not one of these is necessary and will need to be removed manually. That does add up.
Actually the final bracket is necessary, IMO. If you beam each tuplet separately, the brackets will also not appear.
However, I agree with you that it would be nice to be able to control the bracket appearance in situations similar to yours.
I agree you don’t really need the brackets in your particular example, but Gould (page 200) gives examples where you can’t safely omit the brackets when beams span more notes than just the tuplet.
Trying to nail down exactly when you do and don’t need the brackets would be hard, and maybe impossible in general.
I disagree that the last bracket is unnecessary, because the beam continues beyond the three notes of the triplet. Sorry to be disagreeable, but I don’t think this is something that makes sense for us to devote time to working on.
In the example I attached I would not beam an eighth note triplet like that, the attached example is more to the point. Apparently if tuplets are beamed together, even if you split the secondary beam, you get a bracket. In the example given these brackets only serve to clutter the score and are completely unnecessary to understanding the rhythm. They are not needed. If this is ‘working as intended’ then the intent is in error. How hard would it be to adjust the current ‘shown only when necessary’ setting to auto remove these brackets. It would make things much easier.
I think you’re missing two points:
- Time signature has a bearing in how Dorico beams these things, and thus whether it shows brackets. Your examples don’t contain time signatures.
- Your choice of beaming vs tuplet durations strikes me as odd. If you’d input the second run of triplets as a 6:4 run, you’d get this. (note also the time signature).
The particular piece I’m working on is free meter so no meter sigs. In your example the last two quintuplet brackets are not needed, just extra clutter, and if the 5 is on the beam side there is no need for them. Bottom line is I think any program should strive for ease of use, and I don’t want software telling me what to do with my own music, and yes I can remove them manually but when you’ve pages full of them it adds a lot of time.
If you want to hide ALL of the brackets then just Selecr All, Edit > Filter > Tuplets, then apply the property.
Quicker than the amount of time it’s taken me to tap this response on an iPhone…
Dorico isn’t trying to prescribe what you do, Richard. If it were, then we wouldn’t add hundreds of options, including dozens related to tuplets alone, and spend so much time surveying the existing musical literature to try to accommodate all reasonable conventions. But we are a bit resistant to adding options that fly in the face of established conventions or which would, by consensus, make the music harder to read, which is why there’s no option to hide tuplet brackets when they enclose only the notes in a secondary beam but not a primary one. However, it is really pretty quick to hide tuplet brackets via properties if you need to, and it would even be possible to assign a keyboard shortcut to do this, using a similar technique to the one I explained earlier in this very thread.
Well in closing I post the following examples: the first 2 Rimsky Capriccio Espagnol piano reduction for piano, Belaieff ed. and the 3rd from Schnabel’s ed of Beethoven piano sonatas. All of tuplets beamed together with split secondary beams and no brackets. This seems to be the norm as I’ve noticed playing and reading through many piano pieces. If they had brackets it would look cluttered, but as is the intent is perfectly clear. I’ll shut up about now.
Don’t know why the Beethoven ex. appears 3 times.
Recent convert to Dorico (after using Finale for 20 years, since v3.7).
Huge fan of the work you’re doing.
I’d like to revive the request for this to be an option. These brackets in many cases are literally unnecessary, in the sense they are not needed by the intended readers of the music, regardless of the opinions of the Dorico team on whether they are necessary or not. A composer is more likely to know the expectations of the people who he is writing for, after all.
Having the only choices be either manually removing the offending brackets or a global “no brackets for you!” seems like an unnecessarily strict position to prevent what is clearly a viable standard (again as RichardC’s examples demonstrate, I think Schnabel’s Beethoven is plenty of evidence that there are differing valid opinions here). It’s fine that you make the brackets the default, but having one more option to allow unbracketed tuplets in a beamed group doesn’t seem like a huge ask.
In searching the forums, I did find at least one other person making the same request:
A comparison might be that you offer the option of reiterating all accidentals. This is clearly “wrong” in standard notation, but is obviously expected and useful for atonal music. There are many “right” ways to write something to suit the needs of different styles of music. Hebrew and Arabic vocal music is sometimes written right-to-left, is that wrong? My colleagues have already been asking if Dorico supports that, by the way.
Cheers,
Brian
OS10.14.2
Dorico 2.2.20
Welcome to the forum, and thanks for making the case again, Brian. I would certainly not rule out the possibility of adding an option to allow tuplet brackets that span a complete secondary beam group to be hidden by default, but it’s not currently a high priority for the team, I’m afraid.
Thanks, Daniel. Understandably not a high priority considering the more essential development the team is doing. The workarounds are not especially onerous in most cases, but it would be nice to have it available as a setting so that a workaround is not necessary.
