Problem with hairpins Seem to live a life of their own
I have a problem with hairpins. They seem to live a life of their own.
When I anchor a hair pin between a couple of nodes, save and close the score, the next time I open the score several hairpins have moved. A hairpin is sometimes anchored to the original node, sometimes not.
I’ve attached a score and before and after snapshots.
Is this a bug or am I doing something wrong?
(Running: 7108e51 on Mac -OS X 10.9.4)
Attachment | Size |
---|---|
Before_save.jpg | 77.87 KB |
After_save.jpg | 76.67 KB |
Coro_di_Schiavi_Ebrei_Hairpin_problem.mscz | 40.21 KB |
Comments
Can you try to reproduce that with the latest nighly? 11 days old can be lightyears away :-)
Actually it seems you moved the haripins by dragging, with left their anchors in place.
See http://musescore.org/en/handbook/line#Change-length for how to do it right
In reply to Can you try to reproduce that by Jojo-Schmitz
I'm sorry, should have done that.
Yes the problem is the same in the 7b097b7 build.
What I do is I create a hairpin selecting the start and end notes, and press "<" for crescendo.
By default the hairpin is put below the staff, however I need it to be placed above the staff so I move the hairpin by dragging. I'm not changing the anchor points.
Should I do this in another way?
(By the way - I'm continually amazed about the speed in which you get replies to problems in this forum. Thank you very much indeed!)
Jes
In reply to Reproduced in nightly build 7b097b7 by Jwagner
for moving the hairpoins up, better use the inspaecto (F8) and change the vertical offset of the hairpins. Should be more exact that dragging them into place.
However, as my picture shows, the anchors weren't matching the visible position of some hairpins.
In reply to for moving the hairpoins up, by Jojo-Schmitz
Couldn't it be change like in preference for some parts (generally as lyrics are under the staff, hairpins for choirs and singer are above) ...?
In reply to Couldn't it be change like in by Zynette
There is a style setting available for this, but it is global (per score), not per Instrument.
In reply to There is a style setting by Jojo-Schmitz
what a pity ;)
In reply to for moving the hairpoins up, by Jojo-Schmitz
I’ve got to work now.
The only way I can get the hairpins to stay exactly where I want them is to set the global “Default vertical position” as you suggested — in my case to -3. This will place the hairpin precisely where I want it above the staff.
I then have to add hairpins by using the keyboard shortcut (selecting the start and end note and type “<“ or “>”.
When I save the score close it and open it again everything looks fine.
However if I move the hairpin by dragging it a tiny bit and save it, the next time I open the score the hairpin is moved far away from the original anchor!
The only down side for my current score is that all existing hairpins in my score are now moved according to the new global setting (way above the staff), so I have to delete them all and re-create then only using keyboard shortcuts.
I would be nice if you could drag hairpins around and have them stay where you put them.
Anyway — thanks a lot for your help. Much appreciated!
Jes
In reply to Got it to work now by Jwagner
To move it a little ou can select the begining or the end and use arrow key (normally that works) and not move with mouse.....
Anyone confirms ?
In reply to To move it a little ou can by Zynette
I've attached two snapshots. I've moved the hairpin using the arrow keys one note. When I save, close and open the score, the hairpin is moved four notes further to the right.
In reply to That did not work by Jwagner
with arrow jkeys only I was thinking about just visually, if you want to move the 'anchor" to another note you should use shift with arrow key....
after I don't know :'(
In reply to with arrow jkeys only I was by Zynette
I only want to move the visual. This seems to be the problem. The moment you moved the hairpin for visual reasons you loose control of it.
In reply to No, I don't want to move the anchor points by Jwagner
but looking at your before/after images you do want to change the anchors.
You'd never ever want to move begin/end of a hairpin to be over a note that is not the anchor
In reply to but looking at your by Jojo-Schmitz
I'm only moving the hair pin an entire note to emphasize the problem. Even moving the hairpin a tiny bit generates the problem. It is the move itself - not the distance that is the problem.
I guess my original problem came from having to move the hairpin from below the staff to above the staff. This is solved by changing the default setting for hairpins in the score. Thus avoiding a move.
My only concern now would be: What if you by mistake get a hairpin moved and want to move it back? I know you could undo, but say that that you don't discover your mistake until you have made other changes, Then you would have to deleted the hairpin and recreate it. It would be nice if you just could drag it into place.
In reply to I'm sorry if I confuse things by Jwagner
First, the easiest way to reset a hairpin or other element to its default position is with the Reset command (Ctrl+R). Or use the reset controls in the Insepctor.
But dragging *does* work. So my earlier response below in which I ask if you can reproduce this in a score created from scratch. I'm guessing you can't, that the problem is just an artifact of a change made to hairpins in the past 11 days since you created this score.
In reply to but looking at your by Jojo-Schmitz
I'm sorry
In reply to Reproduced in nightly build 7b097b7 by Jwagner
I have an orchestral score with hairpins created with 1.3, and now it opens perfectly in the nightly builds.
I made the hairpins with the mouse though, - I didn't know the shortcut- and when I had to change the anchor I did it with shift and arrow keys, so , now no problem ;)
In reply to I have an orchestral score by Zynette
Can you reproduce this in a score created from scratch? As mentioned, a lot changed since 11 days ago. You could laos try simply deleting the existing 11-day-old hairpins and inserting new ones.
Anyhow, I can't reproduce this in the current build in a score created from scratch. If you can, I'd love step by step instructions.
In reply to Can you reproduce this in a by Marc Sabatella
When I created a new score from scratch I was, like you, not able to reproduce the problem (using build c9c9076).
What really puzzles me is that even though I delete the hairpins in the original score and create new ones (this is the procedure I have followed so far) I still have the problem if I drag hairpins.
Anyway, I'm now able to produce a score where the hairpins stay where they should, so that is fine.
Thanks for your time and great help!
Jes
In reply to Create a new score from scratch by Jwagner
Hi,
I have been following this since I downloaded the 2.0 alpha version ( fantastic program ). From the comments so far I was hoping that this issue had been fixed, however it is still present in the latest build (f262e9c) 2014-10-27. I did manage to figure out how the problem is triggered, but avoiding it is problematic. The issue is that if you move the position, even accidentally, of ANY hairpin (Cres./Decr.) anywhere in the score and SAVE CHANGES while in continuous view the horizontal position pos tag of every hairpin stored in the zipped scores (scores .mscz) file is apparently from the start of the entire score which is far larger than from the page as it should be (it appears to be about that from looking at the scores .mscx file inside of the zipped scores .mscz file). I think this is because the continuous view is treated as a really long page ( full score width ). The only way to fix it is to reset ALL of the hairpins in continuous view by selecting them one at a time and in the properties re-setting the x position to zero, THEN you must switch to page view and save from that view to store the correct values.
The problem is that I do almost all of my editing in continuous view (far easier to work with), now with auto-save and since I usually hit ctrl+s to save after every few changes, any accidental movement of a hairpin would cause all of them to be wrong the next time I load the score. I hope that this helps in finding the cause of this bug, or at least how to avoid it till then. below is a hairpin excerpt from my score.
if you have a lot of these in a score and have to re-set them to zero I have tried removing the "< pos x="??" y="??"/ >" with notepad++ and the hairpins returned to the default position ( can be faster than doing it through musescore, but a bit risky if you don't know what you are doing )
< HairPin id="12" >
< subtype >0< /subtype >
< Segment >
< subtype >0< /subtype >
< off2 x="17.5692" y="0"/ >
< pos x="143.235" y="-4.57957"/ >
< /Segment >
< /HairPin >
thanks,
pmaurano
(sorry had a bad char in the post, though it looked ok in the preview...)
In reply to Save from continuous view causes this error ( Hairpin position ) by pmaurano
Thanks for the report! I don't think anyone had ever noticed this particular problem before, or if they did, they never posted about it. So no surprise it hasdn't been fixed! Could you file an official bug report in the issue tracker? Use Help / Report a Bug from within MuseScore. Set component to Code, leave it unassigned (unless you are volunteering to fix it :-).
BTW, to apply the workaround of resetting, you don't need to select individually. Right click one, choose Select All Similar Elements, then do the reset. So definitely better thsan editing the MSCX file.
In reply to Thanks for the report! I by Marc Sabatella
Thanks for the tip about the selection of all the hairpins ! I forgot about the selection options when I wrote the post. I am an assembly language programmer win32asm mostly, I am afraid that I never learned c++ but I would love to help out, perhaps I may start with something a little less intricate. bit of a learning curve. ;-)
Thanks again,
pmaurano
In reply to I just posted the bug report. by pmaurano
Understood, I was kidding about programming - but it's a common misnake when people file bug reports to assign to themselves, not realizing what "assigning" means.
[ Edit: I see you did file the report; I missed it at first. Thanks! ]
In reply to Save from continuous view causes this error ( Hairpin position ) by pmaurano
Hi, I've attached two files. One is a PDF of how the score was save out of Page View at 100%. The other is the file itself. When I open this file, all of the hairpins and slurs that have been manually adjusted (by typing values into the Inspector) have radically changed positions. I'm using a 2.0, a Mac running OSX 10.8.3.
In reply to Saving out of Page View worked yesterday, not today. by Soolip
I haven't tested it, but this bug was fixed this morning (http://musescore.org/en/node/37691) and will be in the latest nightly version download.
In reply to Fixed by schepers
The hairpin problem seems to have been fixed with the nightly build, but the problem with adjusted slurs remains. As saved:
When the file is re-opened:
Thanks.
In reply to Slurs? by Soolip
Ah, the bug report didn't mention those, so it wasn't obvious those were affected too. Could you file another bug report? :-)
In reply to Ah, the bug report didn't by Marc Sabatella
Will do.