Segno Variation ("Serpent") should be on barline, not above

Thanks for filing it. And apparenlty you set yourself to also implement in? If not, better unassign yourself from this (and change prioroty to normal, major is reserved for serious restrictions in using MuseScore and corner case crashes, this feature here definitly doesn't qualify)

Came up in https://musescore.org/en/node/37536

BTW: here's a possible workaround: add a new text style, as a copy of "Repeats Text Left", and change the vertical alignement from bottom to center then use that text style with this Segno Variation.

Actually getting this into the MuseScore source might even be the real fix?

As mebtioned in that thread, we are awaiting any information from an established authority to describe the most correct usage, since clearly examples exist showing multiple different usages, and Gould does not address the topic.

With the fact that there are multiple "correct" usages in mind, maybe the easier solution is to simply include multiple versions of this on the palette, one explicitly set to 0 vertical offset (or otherwise adjusted as necessary achieve that effect). I don't under the name text styling system so I can't say what's involved in doing that for 3.0. But I believe this could probably be accomplished directly in 2.1. Not sure how it would work if the user changed the vertical offset in the text style.

At least Lilypond seems to handle this Segno variation only on the bar line:

http://lilypond.org/doc/v2.19/Documentation/notation/bars#index-segno
http://lilypond.org/doc/v2.19/Documentation/notation/long-repeats#index…

in opposite to other repeat signs:

http://lilypond.org/doc/v2.19/Documentation/notation/list-of-articulati…

Without having another reference for the most correct usage we could compare the usage of the sign in other music notation programs.

Seems there it a) is bigger than our's and b) always goes with a double barline.
Makes me think we should implement it as a barline (with a jump tag/marker property), in addition to the 'real' segno variation, so we can have it both ways

The same for "musixtex":

http://icking-music-archive.org/software/musixtex/musixdoc.pdf
(see page 78 chapter "16.2 special symbols for repeating long sections")

http://icking-music-archive.org/software/musixtex/musixre1.pdf
( section "Miscellaneous Symbols")

For me the reason to implement this as an alternate barline style would be the fact that apparently this is intended to be used on all staves, not just the top as with normal segnos. How that looks internally in terms of whether there would also be a marker element is another matter.

Came up again in #206636: "Segno Variation" sollte ein Taktstrich sein

and again in https://musescore.org/de/comment/reply/node/283248

https://github.com/musescore/MuseScore/pull/4878 should allow for this

rather might be providing a workaround, easier placement or that symbol

Hi, since this is still not solved (no documentation on the Segno page how to place it on a bar line for ALL staves), I would like to see this in an upcoming version of musescore. :)

Just add it to a(ll desired) barline(s) via the Symbols palette of the Master palette and then move down 4.00sp, left -0.75sp via Inspector.
To act as a real segno, add a segno and make invisible
Maybe add that modified Segno Serpent to your palettes to ease later re-use

When I click a bar line and then try to shift-click the last bar line (downward direction), MuseScore crashes. Adding it to each individually? Not a workaround. Also, it does not play back (which is the actual requirement).
As long as MS crashes when selecting multiple bars using shift, I remove the workaround tickbox (sorry!).

(it only crashes when selecting from bottom to top, actuallY).

Neither crashes for me.
Actually Shift+click does nothing. And is not supposed to here, you're not (supposed to be) doing a range-selection, but a list-selection, Ctrl+Click

Next issue: In MuseScore 3.6.2, symbols cannot be added to a bar line. I can drag it to the bar, but not onto a bar line.

I just did, Click barline, Ctrl+click other barlines, open the master palette, there the symbols palette, searching for the serpent segno, clicking that and voilá, there are serpent segnos on all selected barlines

Sorry for that last workaround removal. When I started typing, it was still deselected from my last comment as I hadn't had reloaded the page yet.

Dragging is never the best way, but even that works, it is just difficult to find the 'sweet spot' to drop.

Ah, it does not work with REPEAT barlines!
Now, that is not a workaround at all. My segno starts on a left (start) repeat sign barline.

I wonder what it takes to get that "workaround tick box" deselected. I cannot use your workaround for sure. And please do not suggest adding a 1/16th invisible bar or something like this.

Works for an end repeat barline and a start/end repeat barline, but indeed not for a start repeat barline, which is rather strange.

It still is a workaround, just not for this single one particular case.
Apart from that a Serpent Segno over a repeat barline doesn't look good at all:

If that Serpent Segno were made a barline in MuseScore, it'd surely be a single barline, or, using the other Serpent segno glyph, a double barline, surely not any of the repeat barlines and probably not an end barline either, maybe even instead of a barline rather than on top

Yeah, it doesn't look good. I'd move it a bit next to the barline like most publishers do.

But well, there IS NO WORKAROUND as of now to get it working. Clicking 30 barlines manually is hardly a workaround.

I am not saying I don't appreciate your work here (I really do), but just the plain existence of a workaround does not make it viable for users.

So PRETTY PLEASE remove that workaround tick. And besides, I would give some money for this feature to be properly implemented, e.g. via bounty source. I.e. I only need to drag it ONCE to a bar and it gets placed PROPERLY. I think Martin would be happy about proper symbol placement. ;-)

A workaround is a workaround even if it does require more work. And is far better than having none.
And 30 such segnos in a one single score are done pretty quickly, and are a rare thing to be needed in the first place.
And unless you're transcribing a score, just don't use them, use the normal regular segno instead. That even works with playback

No, not AS a barline.

So what I get from your message:

• You don't want to implement what can be seen in the score attached below.
• You haven't seen it often so you say it is used rarely and doesn't need to be implemented even though I'd offer a bounty. You don't seem to care that this is typical for Polkas etc.
• You think this should be a barline (WHY?).

> And unless you're transcribing a score, just don't use them

...

I really do not get your point. It is obviously being requested. It is obviously not THAT rare. If I write OR transcribe such music, why would I want to alter the style EVERYONE (i.e. every publisher publishing this kind of sheet music) uses?

See section C.
THIS CANNOT BE DONE.

I still do not get why you consider this issue having a workaround when this case is not covered.

It can get attached to any barline but to a start repeat barline. In that case just apply it to the measure rather than the barline and change its position to your likings (the latter is needed in any case)

Example:

That still doesn't qualify as a workaround.
For one, of I select a measure/bar, it gets applied to every element in the bar.
Even if empty, the position differs and I need to adjust it EACH.
Even if I did that, i have to repeat it for each part.

Whether you accept it as a workaround really doesn't matter too much. It is not only your issue here.
And no, it does not apply to every element, not if you drag it there. (so for a change here drag is the better solution)
Yes, you'd have to adjust. Just like if attached to a barline
No, that sample score you shoed has only one single part, so you'd have to do this only once! And that only if you insist on using that serpent segno, rather than using the standard one. Edit: ah, now I see this just one of the parts, for Tenor Horn (?). So yes, bad luck, you'd need to do if for all parts. And even twice per part. So the better workaround might be to just use a normal Segno and D.S. al Segno.

Start repeats are special because they are attached to the following measure rather than the previous. Not saying that means it is OK that attaching a symbol doesn't appear to work, but the special handling for these is almost certainly what explains it - they get dealt with in a different spot of the code, and when we added the support for attaching symbols to barlines, probably that wasn't taken into consideration. So, that's a bug in itself and should be filed as such, with the workaround being to attach the symbol to something else in the measure and then moved into position. Not ideal, indeed, but that's why it is a workaround, not a solution.

In the more general case, adding a symbol to the barlines across all staves isn't hard. Select the measure before & after across all staves, then right-click the barline, Select / All Similar Elements in Range Selection. Now you can click the desired symbol. But indeed, not for start repeats.

Right now, MuseScore doesn't operate based on bounties, so that's not a consideration. Feature get prioritized based more on importance as judged by the number of requests for the feature, the reported value of the feature to the users (eg, "nice to have this non-standard notation as an alternative to the standard notation for my own private purposes", versus "the major publisher I work for requires this non-standard notation" versus "the notation is actually standard as documented in such-and-such a reference"), also the presence and ease of alternative and workarounds, etc. Allowing those with more financial means to divert resources from features that are higher priority overall is not really good for the community in general, in my opinion, so I'm not really a big of bounty systems. But that's just my own personal opinion.

Filed in #330631: Attaching an element to a start repeat barline is not possible

It is obviously not THAT rare
Well, so far it has been requested twice in 5 years. That's rare in my book...

Sigh.

First of all, thanks Marc for chiming in. It is nice to get a new point of view. And I certainly agree with what you write. I agree, it is not THAT important. I just hope that some VERY OLD RFEs get in, in addition to all important bug fixes.

That's all I ask. The way Joachim puts it is more like "I will never be able to use it as intended by engravers, because only few people asked for it". Again, I am not saying this is important or urgent, but it is the way Joachim writes his responses. But for both Joachim and me, English is not our mother tounge and I know myself that it is not always easy to rephrase things in a foreign language, being a German native speaker myself.

I just want to ask something:

> eg, "nice to have this non-standard notation as an alternative to the standard notation for my own private purposes", versus "the major publisher I work for requires this non-standard notation" versus "the notation is actually standard as documented in such-and-such a reference"

So, who gets the priority? Paying customers? Certainly not publishers who are interested in MuseScore but are not using it yet.

No back to other "accusations":

> Whether you accept it as a workaround really doesn't matter too much. It is not only your issue here.

It really sounds like YOUR opinion is the only accepted opinion in such cases. It will be only a matter of time when e.g. Troubadix will hit the same problem.

>> It is obviously not THAT rare
> Well, so far it has been requested twice in 5 years. That's rare in my book...

So what is non-rare for you? I used to play in a Ernst-Mosch-like ensamble and I rarely saw the standard segno. Just order Scores from Ernst Mosch et. al. and suddenly your percantage will raise. Again, this seems to be restricted on YOUR point of view.

On the other hand, this bugs me (just a little) for a few years now. I do write scores for my orchestra, I just do not publish them yet. Waiting for c3s... But it was just today I accidentally saw this issue. That said, I may be a small publisher in the future, I forgot to request it earlier. If I had seen this earlier it would have been two requests in one week to start with. Sorry I did some digging before creating a duplicate.

> Filed in #330631: Attaching an element to a start repeat barline is not possible

Thanks!

> So yes, bad luck, you'd need to do if for all parts.

Ah, the workaround which got MUCH WORSE is bad luck now.
Thanks for that.

> And even twice per part. So the better workaround might be to just use a normal Segno and D.S. al Segno.

... which was not the reason I replied to this thread in the first place.

Joachim, as I see it… the only thing you are trying to do is to avoid small issues getting fixed.

No worries, I won't PUSH you. I mean, how could I anyway? My subscription on musescore.com does not count,, I am no publisher, the publishers I know won't file a bug even though they are interested in MuseScore...

I just want this to be recognized as a missing feature where the workaround is so unfeasible you could say it is non. Instead you are coming up with ridiculous workarounds (yes, I know how I technically could do that).
The thing is… it IS a major pain to me and maybe to others.

If the segno sign was code and MuseScore was a programming library, you workaround would be like using reflection to alter some internal value of the code. Yes, it works. No, it is not easy to maintain, to understand as a maintainer, and I would most certainly ask what that would be about in a code review. Sometimes "you can get it working" is not enough to qualify as a feasible or viable workaround.

Sorry, to say this: But if you rephrased some of your sentences, it would work out much better.

Here's an example what I would write:

"Sorry this is not working as expected. The best »workaround« I can suggest is manual placement for now. I know, it is tedious, but the best we can offer at this point. We can put it into the backlog, but due to the lack of frequency, bugs from very active and big publishers and a major version coming ahead, we cannot give you an ETA just now.
Kindly ping us in a few months and we can re-evaluate this again."

Sorry for writing an excessive amount of text. Being an OSS maintainer myself, I can see why you cannot fix it this fast. But I for myself try to stay polite and give an answer with at least some glimmer of hope. Sorry to say that, but your responses do sound like "you're dumb, there is SOME way to do it, you just didn't see it. Oh, that special case? Well, bad luck for you.".

I hope you see what I mean.

MuseScore is my MOST favourite open source software, and I only want to make it better by helping describing existing problems. If I wasn't a Java dev but a C dev, I'd create PRs right away.

• Ben

The automatic placement in the more recent versions is GREAT by the way! That makes it MUCH easier than I remembered, thank you for that to all Designers and Devs! :)

Thanks for your comments.

First, there is no such thing as a paying customer. As mentioned, MuseScore has no bounty system, and the software is completely free. Whether or not someone requesting a feature has a subscription to a score-sharing service like musescore.com makes no more difference than whether or not they have a subscription to a video streaming service like Netflix. Prioritization is based on the things I described, always, and they have nothing to do with who is doing the requesting.

FWIW, if a publisher were to request a feature, that automatically puts it in the second category among the random three I mentioned - a feature required in order to fit the house rules of a given publisher. Same as if the request came from a composer or arranger who is handled by that publisher. That will generally beat out a feature requested by a user who wants it just on personal whim, but lose out to features that are actually necessary to support established notation standards.

This is just plain common sense; anyone running a software project dedicated to music notation would have similar priorities., even if some would also accept "payola".

Anyhow, I completely agree there should be a simpler way to produce this particular notation, standard or not, because while very uncommon in the world at large, it's common enough in certain segments of the world to be worth supporting - like a hundred other relatively obscure notations we support.

But, since it isn't standard, and no modern engraving textbooks I am aware of specifiess the "correct" layout for it, we see that historically, different publishers have laid it out very differently (as shown by examples in this very thread). The variety in how the symbol is handled makes it difficult to pick the one best layout to support as a native feature.

This to me suggests the best way forward is to simply fix the bug that makes it difficult to add this symbol to start repeats.

If, on the other hand, someone does produce evidence of a true standard we could follow - not just one or two polka publishers, but one that is shown to be followed by the majority of publishers worldwide across genres who do choose to use this unconventional notation - then the possibility of implementing that particular layout as a built-in feature increases.

Again, this isn't some arbitrary decision passed down from on high; I'm not even in a position to make decisions on any of this. I'm just speaking to general common sense about how software development works.

Hi Jojo, I've been playing and singing for 50 years and didn't see the "segno variation" ever in any other way than superimposed on a double bar line (see attached filed). Maybe that's because I live in Germany and was doing only church choir and tranditional brass music, but even the few times I saw classical staffs I didn't see it any different ever. However, as capella has the same issue (I mean, the segno is not a variant of a barline there, too), there may be different styles of usage. Anyway I strongly opt for the option to have it as a barline in musescore. Thanks! Gerhard

Shortly we had a discussion about the correct usage here again: https://musescore.org/de/node/332863#comment-1131274.
If I understand it correct, there are different glyphs for the same convention (inside the repeat palette and inside the master palette). Does it really make sense to have different symbols with a segno variation in the repeat palette (which doesn't match with the convention of music notation) and a serpent inside the master palette with the same meaning? I'm not aware about ressources, where a segno-variation/serpent ist placed above a system and could image this different usage/labeling could be more confusing for users.
Would it make sense, to open also an issue for MS4 to this (minor) issue?

It isn't an MS4 issue, but exists since MS2, when the Segno variation got introduced (and uses the one from the Musical Text Font, whereas the one from the master palette is from the Musical Font, and as such fitting the staff size automagically, so only this one is suitable for placing on a barline)

Okay (maybe the developers of MS4 take also look here from time to time). As mentioned (my two cents), I'm not sure about it to offer the musical text font inside the palette, when it isn't the correct way of music notation.