automatic placement (of bows)

• May 20, 2019 - 21:17

Hi. Sorry, but I'm a bit unnerved. Everytime I change the layout, or it gets changed - meaning, when the measures rearrange, all the binding bows are off. I replaced them tidiously maybe about 10 times or so already. And there are 100s of them...
So what happens is: Doesn't matter if I turn off the automatic placement for a bow, or not. As soon there is something going on in the layout, every element, that I unckecked (AutoPlacement), gets activated again. Then just every (mostley the bows) element is off. I also realized, that the bows often bind themselves not to a note, but to a staffline or whatever.
Please, can you fix this, I exhausted from bow rearrangement... /(#_#)\

Don't know why, but cannot upload the mscz file. Maybe to big (5.2MB) ?

Attachment Size
Bows are off.png 503.75 KB

Comments

• May 20, 2019 - 21:39

Bows = Slurs in English?

I suspect that it will be difficult to understand without a good example, but I think I do understand.

Here's the scenario I'm imagining: There were 3 measures on the second system and you adjusted all of the slurs to make them look right, you then did something that caused the second system to have only two measures. At this time, the slurs all changed their shapes, and now you have to adjust them again.

It would be very helpful if you selected the measure you are showing in your picture and use File->Save selection and attach the file with only those measures. I have some thoughts as to why they are not doing what you expect. This file would allow me to confirm my suspicions.

Reply

• May 21, 2019 - 00:52

It's known that cross-staff slurs don't work correctly in 3.0. It's fixed for 3.1, check out a nightly build to test or wait for the release candidate in a couple of days if you're feeling lucky :-)

Reply

• May 21, 2019 - 03:51

Hmm, that's not good then, I don't think there were any further fixes to this after the first beta. I opened your score in 3.1 and things look basically OK on the first system, and are messed up after that. I did a Ctrl+A to select all then Ctrl_R to reset. Then I tried to manually adjust some slurs by double-clicking and adjusting handles. All seemed to go just fine, at no time was disabling autoplace necessary or advisable. I saved and reload and it was still fine. I tried adding and deleting system breaks, and aside from the expected fact that manual adjustments no longer make sense if the length of the slur changes, all was still fine.

Can you give precise steps to reproduce a problem?

Reply

• May 21, 2019 - 05:06

Hello!Marc Sabatella
My current problem is that exported SVG does not have the information I need.I am wondering how to export the SVG content customization in the MuseScore3.0.5 open source project by adding "id" and "transform=" matrix() to the "Note".Please see the attachment for the specific format. Thank you!

Attachment Size
1.svg 240.96 KB

Reply

• May 21, 2019 - 14:37

If I had an answer I would have done so in the original post, just like any other contributor who answers questions in these forums. Hijacking threads does nothing to get you a quicker response. Most of the people you addressed directly, including myself, turn off e-mail notifications and read EVERY post and then decide if they have an answer. As you probably have seen by now, people who have an idea of how to answer you have since logged back into the forum, probably after a night's sleep in their home, and started answering your question in the original post.

Reply

• May 21, 2019 - 16:06

Well. I tried to reset the score completely, which messed up a lot of the placements of different elements. Also I tried to reset only parts of the score, like a part that has a certain cadence. Sadly nothing works. It's not possible to place the slures right, when I try to attach them to the correspondending notes. It's always off. Also, to place them right, I have to turn off the automatic placement feature for the slurs, otherwise they get deformed and wont let them be put to the right position.
If you want to repoduce this, you can try to reflect a slur and try to arrange it the way it is streching over a span of notes, so that it bind them from beneath. Not possible with AP, even hard without.
See screenshot

Attachment Size
Slurs underneath.png 78.1 KB

Reply

• May 21, 2019 - 18:03

Resetting shouldn't "mess up" the placement of anything, and when I tried it, it worked perfectly. Everything was reset to the defaults, just as expected. Of course, the defaults might not be exactly what you want - in any version of any program - so you may indeed want to reapply some manual adjustments. But doing so for slurs should not require disabling autoplace. Nothing about autoplace should interfere in any way with this, except to the extent that prior to 3.1, autoplace enforces collision avoidance for non cross-staff slurs.

So if you are seeing some case where you are seeing autoplace needing to be turned off where you feel it shouldn't, please give us precise steps to reproduce that problem.

Meanwhile, I am not sure what we are supposed to glean from the picture you posted here. But to flip a slur below notes, you shouldn't be playing with the shape at all, you should simply press "X", same in MuseScore 3.1 or 3.0.5 as in 2.3.2. However, I can see that in the case of these particular cross-staff notes, there does seem to be a problem with the default after flipping, not sure why, will investigate.

Reply

• May 21, 2019 - 19:39

I'm not 100% sure we are talking about the same thing because again, autoplace is not at all relevant to what I am seeing, but the problem I can reproduce and now understand has to do with slurs on beamed cross-staff notes. The default looks like this:

cross-staff-slur-1.png

which is actually wrong - according to the intent of the algorithm, the slur should have attached to the end of the stem of the first note. But it's not obviously wrong. It only becomes obviosuly wrong when you try to flip it:

cross-staff-slur-2.png

What has happened here is the algorithm is thinking that first note is stem up, so the slur is dutifully attaching itself directly below the notehead and when placed below, and above the stem that isn't actually there when placed above.

The fact that the algorithm thinks the first note is stem up explains not only why neither layout looks correct, it also explains why the slur is defaulting to below the staff when actually the intent of the algorithm might have otherwise placed it above (not sure either is objectively better than the other).

I will contemplate how to best fix this.

Reply

• May 21, 2019 - 22:46

Thanx for your looking in to it. I wrote 'messed up', because I made many adjustments in my score, which has about 463 measures. They all get reset and its no fun to readjust.
Also,reseting the score, and even typeing in the last 60 measures again, didn't help me.(made it a lot better thoug). The slur problem persists anyways.
Turning autoplacement off for the most of the slurs helps in that way, that I can adjust them at least to look ok, even when they are not binding to the intended notes. Leaving AP on makes them kind of 'jumpy' and deformed, with no chance, to set them right.
To reproduce. In the file, with autoplacement on: flip the slur that's crossing the beamed notes and try to anyhow get it look right + try to adjust the look of the slur by double clicking on it and moving the dots. It s almost impossible.
Turning AP off, lets you handle the look of the slur

Attachment Size
measure test.mscz 7.5 KB

Reply

• May 21, 2019 - 23:19

Regarding the example here, I think maybe I understand. It's an extremely unusual case where, because of odd shape needed to produce a slur over notes that are vertically distant from each other, autoplace is indeed altering the slur shape more than usual to avoid the other notes. So manual adjustments do affect how hard autoplace needs to work, thus and thus sometimes the two adjustments are in conflict. In these unusual cases, indeed turning off autoplace for just those slurs help. In the vast majority of cases it won't make a difference though.

So if this is what you mean when you say your changes "all get reset" - that the slur shape changes ou from under you if you leave autoplace on while adjusting these unusual slurs - then indeed, turning off autoplace for those slurs solves that. But I thought you were saying that after you succeeded in making an adjustment to some particular slur, you then did something else, and that something else caused the original adjustment to be undone. If you were in fact saying that, I would also love it if you could come up with precise steps to reproduce that problem, because that would pretty have to be something unrelated.

Meanwhile, I have a tentative fix for the basic issue I identified earlier - getting the wrong end poitns for slurs on cross-staff beams in certain cases. Because we don't know the final stem direction for cross-staff beams while we are laying out slurs, my fix is to simply ignore the stem and always lay out the slur close to the notehead regardless of which side the slur is on. It might not be the perfect solution, but it's much better than the current. With luck the fix may make 3.1.

Reply

• May 22, 2019 - 14:39

Think that's a good idea. At least it will attach to the right notes then.
You asked about the reset. I experienced it yesterday. After 6 hours of work, all the replacing I was doing was gone.
This happens, when a staff gets replaced in the layout. For example, when I delete a staffline, to edit the score,the autoplacement for all elements (slurs, dynamics, other lines) I had turned off before, get switched on again. So all the adjustments are reset and I'm back at square one.
To reproduce:
In attached file: check the AP at the slurs. (most of them it's turned off), ->delete a staff-> check the autoplacement again.
Also strange Musescore crashes now, when I delete the bassline in the first measure :|

Attachment Size
autoplacement_resets.mscz 38.23 KB

Reply

• May 22, 2019 - 20:31

You're deleting a staff that contains notes with slurs on them? I'm not understanding how you'd expect that not to affects slurs? As far as I can tell, though, deleting unrelated staves doesn't affect anything.

If you are still finding otherwise, can you please tell me more specifically which slur to check and which staff to delete?

I can tell you also that if a slur spans more than one staff, and then something changes in the layout so now it spans only one staff, then again, obviously manual adjustments you made to the two separate segments of the slur cannot be preserved - they are likely in conflict. Similarly, it's not reasonable to expect manual adjustments made to a slur that exists on a single system to continue to make sense if the layout changes in a way where it ends up spanning multiple staves.

I was able to reproduce the crash though, somehow this has to do with the playback of the hairpin. Can you please file an official bug report to the issue tracker (Support / Issue tracker, above; or Help / Report a Bug, from within MuseScore).

Reply

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