Clef changing
Changing clefs under the nightly appears broken. Create a standard piano score, 4/4, C (See attached sample)
1. Drag any clef to a new measure, a standard treble clef will be created at the _end_ of the previous bar
2. Drop the clef I want onto this treble clef (from 1), a proper one will be created in the next bar where I wanted it
3. Drop a different clef onto this new one (from end of 2), the clef at the end of the previous bar will change to the one I want, but not the one I dropped it on.
In the sample provided, the treble clefs at the end of bar 1 and bar 3 were from dropping _other_ clefs into the next bars. The C8 clef at the end of bar 2 was created by dragging the C8 clef onto the treble15 in the beginning of bar 3.
| Attachment | Size |
|---|---|
| Sample.mscz | 1.64 KB |
Comments
I noticed that:
1) if the new clef is dropped on top of the existing clef, the programme behaves as expected (i.e. as version 1.0 behaved when dropping the new clef generically in a measure); note that the new clef has to dragged precisely on top of the existing clef and dropped when the latter turns red.
2) If the new clef is dropped generically on a measure (i.e. when the measure background turns brown) the result makes little sense, as schepers describes.
I don't know if this difference is a new feature (perhaps still incomplete in point 2) above) aiming at two different solutions for two different aspects, if point 2) is a left-over from the previous version and will disappear or if the whole is a bug.
A word from the code gurus would be enlightening...
M.
I'm new to this, but very frustrated by the need to add a clef and a change in key signature to the start of a new line of staves. Always pops onto the end of the one before. Did all the appropriate dragging. No luck. With a tune having three key changes, this is more than I can bear! OS X.4
Is this a problem in the latest nightly build?
I am a bit confused. Step one describes perfectly normal behavior as far as I can see. Dropping a clef onto a measure is *supposed* to actually create the clef at the end of the previous bar. That's standard notational practice. Step two seems like an odd thing to do - why drop a clef change onto the preceding clef rather than onto the measure itself? But I suppose I would expect it to replace the existing clef. And he's right - it does not. It leaves the step one clef where it was and adds a new step two clef at the start of the next bar. This remains true in the latest build. No idea if that's actually a bug or not, but I guess it probably is. Similar story with step three - againl, this seems like an extraordinarily odd thing to do, but if one were to do this for some reason, I would agree the results are not as I would "expect", if forced to think abut what the expected behavior would be.
Comment #2 appears to be an unrelated support issue, probably not relating to the nightly builds, and probably from someone who just doesn't understand that clefs are indeed supposed to appear at the end of the previous measure according to standard notation conventions.
Bottom line: changing clefs the "normal" way appears to work fine as far as I can see. Only these particular corner cases in step 2 & 3 differently than one might possibly expect.
The point in the original post was that, whatever clef you dropped, you were always getting a treble clef; then a rather circuitous process was needed to obtain the required clef.
I think this is fixed now, but a few specific tests would be useful.
Thanks,
M.
Ah, I get it. Since I didn't see the behavior described regarding dropping "any" clef resulting in "treble" clef being placed, I assumed he meant that the chosen clef appears but in an unexpected location. I have not been able to duplicate that.
Clef changes are still pretty strange in the latest nightly (9-15, Windows). Everything in the original problem report remains true, except that at step one, I don't see it always being a treble clef that is placed - the correct clef is placed in step 1. But steps 2 and 3 still produce the strange results stated. So that replacing one clef change with another now requires you to explicitly delete the old clef.
Marc, you are correct that I don't always know correct notation practice. A clef change in a measure should always be at the end of the previous measure. However, clef changing in the latest nightly 4ee8a2e are still extraordinarily weird.
1. Create a standard piano score, 4/4 in C.
2. Drag a bass clef to the beginning of the third measure, the correct clef is created at the end of the second measure (that's fixed)
3. Now drag a Treble 8 (or 15, something different) to the third measure and it appears the correct clef is placed, but you can still see the bass clef underneath. Now drag the treble clef from the end of the second measure and you will see the old clef is underneath it.
4. Drag any clef onto one of the clefs at the end of measure two and a new clef will be created at the beginning of measure three.
Yes, I definitely agree there are still issues with clef entry. Replacing one clef change with another appears to require you to first explicitly delete the old clef change or you get strange results. It's possible this was intentional, but I can think of a reason why I'd prefer it.
Fixed in 555a83a25a
More testing welcome but I hope I fix all the mentioned bugs.
Automatically closed -- issue fixed for 2 weeks with no activity.