I have a series of 3 and 4 note chords in 1/4 note triplet figures.
I have copied them to individual instruments and then want to filter on the 1st, 2nd, 3rd chord notes to distribute the chord tones to individual instruments. I select the passage, select Filter in Chord, and select a voice to delete. It deletes fine but the problem is it leaves the triplet figures highlighted as well so it removed the triplets. After selecting a given note in the chord in the passage, I have to go in and deselect the triplet symbol so that I can then delete the notes without affecting the rhythm. Am I doing something wrong? It would seem inappropriate for the work flow to affect the rhythm in this scenario but maybe there are other workflow considerations I’m not thinking of…or it’s a bug…or I am just doing something in a way that can be done easier in some other manner(?)
This is working as I would expect: if the tuplet number/bracket is selected when you hit Delete, then you’re telling Dorico to delete the tuplet bracket/number just like you’re telling it to delete the selected notes. Dorico doesn’t know whether you’re planning to delete or copy and paste, and if you were planning to copy and paste, then you would need the tuplet number/bracket selected, otherwise the pasted music would not have the same duration.
If your specific goal here is to “explode” a chord written on one staff onto a number of other staves, we are working on a dedicated feature for this kind of workflow that will significantly reduce the number of steps you need to perform to achieve the desired end result.
Again I insist that this way to treat tuplets is kind of sick, and it would be really great if something more consistent would replace it.
I already tried to bring some arguments in Tuplet problem - Dorico - Steinberg Forums …
How it is now it causes a lot of trouble, not only when it comes to chords+tuplets, but also with voices.
Look at this:
Somehow, after I put some flows within one project (same instruments an all) together into only one flow,
I found the previously first-upstem voice (and in the original flow it was a first-upstem voice, there was no second voice at all on this instrument… ), then being now a first-downstem voice.
I wanted to correct this: make the “first-down” again a “first-up” voice.
The first interesting (and inconsistent) point here in the first jpg is, that in Write mode some of the tuplet brackets are hidden - this is in fact the selected switch option for Engrave mode, but should not have any effect here, in Write mode. And it is also not possible to access the tuplet properties in the property panel for this notes - but this notes are tuplets! How can the tuplet property of notes “disappear” ony with the bracket hidden in Engrave mode?! No bracket no tuplet ??? How can that happen!
Second, look what happens when I call Edit → Voices → Switch_voice_content “Stimmeninhalte tauschen” on the selection …
This is terrible and ugly! It can’t be done. The other commands in the Edit - Voices Menu don’t work either.
Filter the voice, copy it, try to get rid of every rest left in the bars, btw. not easy, paste the copied notes as Voice first upstem → same ugly result.
Again, the tuplet property seems something “meta”, not something bound to the notes themselves, as it shold be.
Obviously there is some kind of information about tuplets somewhere and somehow with influence on the first-down voice - and kind of “hidden” when the brackets are hidden - and this information stays with the voice - and does not move on with the notes it belongs to. Terrible.
Maybe things works fine, when I put this engrave mode options switch back to “visible” - I’ll give a try, because the notes with brackets were treated correcty - but anyway the example shows the problem.
A problem that will cost a lot of Dorico users a lot of time and should therefore not be dragged into version 2 or even further.
Please!
There’s no inconsistency here at all. All changes made in Engrave mode are visible in Write mode. Anything else would be ludicrous. A few changes (such as staff spacing) only affects Page View, but I believe every property of a note takes effect in both Galley and Page view.
Exactly. This information is stored in signposts, which you must have disabled yourself. You can re-enable them from View → Signposts → Tuplets. Make sure to select the signpost when doing operations such as voice shifting and copying, and most of your problems should be solved.
This is working as I would expect: if the tuplet number/bracket is selected when you hit Delete, then you’re telling Dorico to delete the tuplet bracket/number just like you’re telling it to delete the selected notes. Dorico doesn’t know whether you’re planning to delete or copy and paste, and if you were planning to copy and paste, then you would need the tuplet number/bracket selected, otherwise the pasted music would not have the same duration.
I find it weird that notes that are tuplets are treated differently to other note lengths. There is no question of copy/pasteing a crotchet that turns into a minim. So why is the note length of a tuplet not just an implicit property? Pasting then wouldn’t require selection of the tuplet number, and deleting wouldn’t be scuppered by the number being selected.
I’ve never ever wanted to paste a tuplet whilst changing it’s duration to a non-tuplet.
After selecting a given note in the chord in the passage, I have to go in and deselect the triplet symbol so that I can then delete the notes without affecting the rhythm.
Kloewen,
Until the “explode” function arrives, we can at least use the filter function again to “deselect only” multiple “tuplets” symbols before deleting unwanted notes in the chord.
Another way I found is to use marquee tool. when you select the unwanted note in the chord to delete them (on the individual instruments part), make sure not to include the “3” symbols in the marquee selection. Then you can use the filter function to delete top( or middle or bottom) note from the chord without messing up the rhythm.
I totally understand the reasoning Daniel mentions, but do tend to agree with Mr Parker…Dorico should just KNOW that these notes are of triplet duration and would require the triplet figure upon a cut/paste operation. that said it’s a small annoyance and certainly I can work around it. Just wondered what the thought process was around the design. Thank you all.
Exactly!!!
Simple copy-paste-operations including tuplets working or not - depends from having singpost visible or not!
How can that be! What’s that supposed to be …!?!
Well, you tell me to activate some singpost, that normally may show me some additional, and normally better hidden information, better hidden, because the screen is already full of complex information, so no need for more stuff around, if not really needed for some special reason. That’s like in a word processor, you’d need lets say “page view” to be tuned on, if you are planning to to copy words containing umlauts or ß or so, while in “continuous view” you get garbage. Well, a very small annoyance this would be to german writers, and indeed we had to write in LaTeX things like "a for ä for a long time, and that was fun. But now it’s 2018.
Again, take a look:
This was the task to do - simply copy some tuplets…
Do you really think this can be a desired behavior? Dorico messed up the whole score starting from the insert point, because Dorico switches to a kind of implicit “insert mode” when pasting tuples it’ s tuplet property it has “forgotten”. Everthing’s got shifted to the right, and differently in different staves.
And again I ask: How can the handling of notes depend on the visbility of tuplet brackets or “sign posts”?? That Dorico only knows that
tuplet are tuplets, if the bracket or a sign post is visible? That could be redundant and thus superfluous information for me, the stupid user, but not for Dorico, Dorico should know at any moment what it handles. And why shouldn’t a Note as a proud object be able to speak for itself if asked via its programming interface: “Hey, I am by the way kind of a tuplet, and I belong to the following tuplet group with the address I hereby kindly return to the caller, please ask there for additional information …”
Everything is so clear and well-solved and promising in Dorico, exept this stupid thing. So please, think about this seriously! I know this is about data structures an “design decisions”, and is not done on the fly. But programming a lot of workarounds and plugins to cope with this costs time too.
It accept that if I want to simplyfy the reading of music by reducing the amount of “redundant” tuplet brackets in the printed version (and it is really fine that Dorico does offer this), Dorico also hides them in write mode. Ok, maybe. But if on doing so Dorico looses track of note proprerties in write mode, it is clearly not ok.
And finally some more funny stuff with tuplets. This was a Sibelius-XML-Import, all notes tuplets. (And I think, xml import is generally done really well.) I could not move the switches (“Klammer”, “Platzierung”) shown in the property field to correct the error - it showed kind of “read only” behavior.
This was btw. fixed when I called “Edit-> Reset position”, so the information about all notes being tuplets was somenhow there.