Trill question
I've seen some discussion of problems with trills, but I can't find anything that clarifies a problem I've come across:
trillexample.pdf
trillexample.mscz
A sounds like I want it. But Gould says that "a trill line must be used with tied notes." So I made the notes look like B, but now playback plays an extra quarter note after the trilled tie -- oddly, the extra note sounds to me like a high e rather than the d's, which are trilled. Experiment shows that C both looks and sounds right, so apparently the bar break is part of the problem.
So the question is, can I make the notes look like B but sound like A?
Comments
Thanks for pointing out this flaw.
You could go 12/8 briefly, but that's not what you're wanting.
Yes, you can. To make the notes look like [B] but sound like [A], hide and extend:
1) Make the first trill be a trill line and then extend the line over the tied note
2) Take the final trill as in [A] and hide it: select + "v"
3) Optionally for visual purposes while working, uncheck "Show Visible" in View.
Update: ... Forget the aforementioned work-around for this instance.
This is not a flaw, but rather the devil is in the details:
The problem is one of anchor points as with cresc. and dims.
Instead of dragging with the mouse the trill-line: press SHIFT+Right and the anchor point will move to the next note--dragging doesn't change the anchor point. You only need one trill-line.
Thanks again for pointing this out so as to clarify the need to precisely place anchor points and not only for crescendos but for all objects.
In reply to Thanks for pointing out this by worldwideweary
Thanks, shift-right seems to get me what I want.
In reply to Thanks for pointing out this by worldwideweary
This isn't the first time I've had problems in Musescore because of using drag instead of shift-arrow. I wonder if Musescore shouldn't just remove the drag function. Does it do anything that shift-arrow doesn't do more reliably?
In reply to This isn't the first time by jcorelis
It allows you to fine tune the position of an element without changing the anchor. Useful when avoiding collisions for example.
In reply to This isn't the first time by jcorelis
It's not out of the realm of possibility that we would consider forcing the user to use shift or some other modifier to get that fine tuning behavior. This would make it less likely a user would do it accidentally when he really meant to change the anchor. In the end, there is no substitute for reading the Handbook and no way to prevent users from making mistakes, however.