Problem with hairpins Seem to live a life of their own

• Aug 25, 2014 - 14:51

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

• Aug 25, 2014 - 15:19

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

Reply

• Aug 25, 2014 - 19:01

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

Reply

• Aug 25, 2014 - 21:30

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.

Reply

• Aug 26, 2014 - 04:58

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.

Reply

• Aug 25, 2014 - 16:17

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 ;)

Reply

• Aug 25, 2014 - 21:02

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.

Reply

• Aug 26, 2014 - 10:55

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

Reply

• Oct 27, 2014 - 20:41

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...)

Reply

• Oct 27, 2014 - 20:55

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.

Reply

• Oct 28, 2014 - 04:00

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

Reply

• Oct 29, 2014 - 17:10

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.

Attachment Size
Vetter_Quartet_D.pdf 990.85 KB
Vetter_Quartet_D.mscz 20.77 KB

Reply

Do you still have an unanswered question? Please log in first to post your question.