X-Y axes for dynamics
hello
Windows XP PRO
Nightly R 3095
It seems that changes in the X and Y axes for dynamics has no effects (?)
regards
ph
Do you still have an unanswered question? Please log in first to post your question.
hello
Windows XP PRO
Nightly R 3095
It seems that changes in the X and Y axes for dynamics has no effects (?)
regards
ph
Do you still have an unanswered question? Please log in first to post your question.
Comments
Please give step-by-step instructions.
In case you are not aware, you can drag dynamics with the mouse.
In reply to Please give step-by-step by David Bolton
go to style-edit text style-dynamics.
change the default 8.00 sp for the Y-axes to any other number.
The dynamic sign is placed at the sameplace as it was when the Y-axes was 8.00.
(compare with "chordname". If you change the Y-axes there, the chord is placed closer or farther from the system.)
regards
ph
In reply to x-y axes by ph
Is this still open ?
ph
In reply to Is this still open ? ph by ph
.... or ?
In reply to .... or ? by ph
I submitted this as an issue a couple of days ago - http://musescore.org/en/node/9330. I notice it is fixed in the trunk. There's actually quite a few sort of similar issues with text style parameters being ignored, impossible to set, or misinterpreted in 1.0, pretty much all of which are fixed in the trunk. The next version looks to have vastly improved text handling - not just bug fixes, but also the ability to have text style changes affect already-created text. I'm personally hoping they decide to roll the new text handling facility into a 1.1 bug fix release - I suspect it would be no harder than fixing the text-related bugs in the 1.0 branch. But depending on how far out that next major release turns out to be, maybe that's wasted effort; I don't know.
In reply to I submitted this as an issue by Marc Sabatella
I would consider text styling as not critical and so not to be fixed in 1.1. The main problem is that I would like to limit the number of MuseScore file formats out there and except if a bug is very critical, the 1.X serie will keep the same fileformat all the way.
In the trunk, there is now a way to define if a text will be changed by text styles or not. It's a new element in the file format.
In reply to I would consider text styling by [DELETED] 5
Makes sense; I hadn't considered that the new style mechanism would require a format change. Still, while individually the none of the text-related bugs in 1.0 could be considered critical, collectively they do kind of cripple 1.0 a bit. It's just harder to get text where and how you want it than it should be. But I do understand the reluctance to fix bugs that a) aren't critical and b) are already fixed in the trunk but can't simply be ported directly into the branch. I have no desire to delay progress toward 2.0 unnecessarily!