ties across voltas
Can we finally (after YEARS of people wanting to do this) get note ties to work across voltas? Music scores NEED to be able to do this. Don't ask us to fake it by tying to invisible notes, fudging slurs in where they don't below, or other klutzy workarounds. And that includes shifting voltas by extra bars to avoid fixing this failure. Let us click on the note from the previous section, tie it to to the note in the second volta, and have musescore neatly manage correctly drawing the tie at the start of the next volta.
Anybody who says the workarounds people are forced into using are adequate just doesn't know what they're talking about.
Comments
See also: #310081: Support for ties across voltas / repeats .
In reply to See also: #310081: Support… by kuwitt
This ignores what I said initially. Musescore can't do what it needs to do. The workarounds are wrong!
In reply to This ignores what I said… by Tim Seifert
It does not ignore what you said initially at all. It links to the actual feature request in a way that your post gets added to it and gives it more weight.
I can't quite figure out what this would look like. If there are two options, then visually one might want the tie to go from the preceding bar to the first volta, but the second volta would have "ties" hanging to the left surely. Is that a sensible notation?
There is also the possibility that the tie would only be needed for one of the voltas. Doesn't it actually make more sense to restructure the music notation to avoid this issue? Can you provide an example where it might actually work - and be helpful?
In reply to I can't quite figure out… by dave2020X
No, the music score does not need to be restructured. The Musescore program is failing to do what it needs to do, to be able to enter the score properly. It's as simple as that.
In reply to No, the music score does not… by Tim Seifert
And that is why we have an active feature request in #310081: Support for ties across voltas / repeats
In reply to And that is why we have an… by Jojo-Schmitz
So why has nobody done it. This serious shortcoming has been around for years.
In reply to So why has nobody done it… by Tim Seifert
Because nobody with sufficient knowledge and sufficient time and motivation has been found yet. This is the nature of Open Source...
That issue is just about half a year old though...
In reply to Because nobody with… by Jojo-Schmitz
Even if it can't properly PLAY a score through the repeats, it shouldn't be THAT hard to programmatically tell Musecore that this note is tied to that note, and draw the ending of the tie. After all, it can draw ties when they span across bars with a line-break between them.
Pseudo-code: When two tied notes have voltas between them, only draw the ending tie to the second note. Likewise for codas, or any kind of jump. If it starts with a note that's supposed to be tied, draw the ending of the tie. And if the software can't manage to play the note across the tie, for the whole length it ought to, then don't play the note at the end of the tie, at all. i.e. Do what all us users have had to do by hand.
I find it hard to believe that nobody can come up with a way to do it, I can only imagine that they can't be bothered (over several years) because people have invented daft ways to pretend to do it. We shouldn't have to go onto a support forum to find out how to do such a basic aspect of music notation.
In reply to Even if it can't properly… by Tim Seifert
Feel free to give it a try, I'm sure a Pul Request would be very welcome
In reply to Even if it can't properly… by Tim Seifert
"it shouldn't be THAT hard to programmatically tell Musecore that this note is tied to that note"
That's almost spoken as if you're no programmer.
So a tie is defined as something that ties two notes (and exactly two notes) together, not one starting note to two ending notes. So the first change in code would be to allow that, but then be very aware of when it is ok to allow that and all ripple-on effects.
Aside from that the tie code is now to be made "repeat-aware". It might surprise you, but if you only have a note and the tie command, you simply currently don't have access to this kind of information easily; nor is it likely processed at that point in time. So this means you now also have to somehow force the playback order information to be available at that point in the flow, of course without impacting editing speed.
And yes, for me at least, focusing my free voluntary time on features/issues that have no workaround at all but are at least equally important (from my point of view/value, which is different for every person) makes somewhat more sense than focusing it on things that (although clumsy) have some kind of workaround.
If the current workaround is too labor intensive, then perhaps a plugin could be conceived to automate the process (like for tempochanges); but apparently, yes in all those years and the grand scheme of things, this one issue hasn't been addressed yet.
I can come up with several ways to do this in code and fix it (see the paragraph above for one of them). Feel free to talk to my dayjob boss and pay my consultancy fee, including the penalty fee for no longer working fulltime for my current client ;-)
To be clear, we're not saying you don't have a right to be frustrated by this, by all means, be frustrated about it and feel free to vent here in a post.
In reply to "it shouldn't be THAT hard… by jeetee
If you think I've never programmed, think again. In my day, we wrote programs on ink and paper before touching the keyboard. We debugged failing code by printing it out, hand-reading it, and penning in the corrections, then usually making the program run with just one set of going through that process. I'm old enough to have used paper punch card with a mainframe, and actually been the compiler who turns the handwritten mnenonics into handwritten op-codes that were hand typed into RAM chips.
I'm also a musician who knows what two tied-notes are. So, yes, I know that in music three tied notes are actually one long note drawn as three connected symbols on a page.
MuseScore can already draw the end of a tie-line when notes are tied across a line-break, so it's obviously got the graphics routines in there for drawing ties that aren't directly between two adjacent notes.
Lilypond can apparently handle drawing the end of a pair of tied notes correctly across a volta, even if it is merely drawing the end of a tie. So it can't be that hard, programming-wise, to make it possible to click on the ending note and say this is the back half of a tied pair of notes, even if it can't actually join those notes together for score playback.
And for most people that would be sufficient: Draw the end of a tie into a solitary note. Since their PRIME purpose of using MuseScore is to print scores, not to have it play them like a pianola. Even though that's a useful feature to catch mistakes.
What I hear across several years of people wanting this is; this isn't important to me, so I'm not going to bother.
In reply to If you think I've never… by Tim Seifert
Great to know you have programming experience; given how much this feature bothers you I'm looking forward to your pull request. It's just that usually those that state something should be easy to program are those not hindered by knowledge.
In reply to Great to know you have… by jeetee
There's a wild difference in being a programmer, and creating a program, to being able to take someone else's code and immediately learn it then add features.
In reply to There's a wild difference in… by Tim Seifert
Exactly.. and the original programmer isn't around within the project anymore.
In reply to Exactly.. and the original… by jeetee
Yet, you made it sound like you were THE programmer... And by your logic, if they've left, none of the current programmers can make any changes. How does anything get fixed? Surely you don't expect all outsiders to not just report problems but to fix them, too?
When I looked into this problem there were a number things evident:
* It was a long-standing complaint being ignored.
* There's a bunch of weird and dopey work-arounds, that are going to blow up in someone's face in the future.
* Few people understood the problem (didn't know how scores could have ties across voltas, or jumps to codas), and didn't know what it should look like (hence my hand-drawn example). And don't grasp that rewriting a score isn't the solution.
* There doesn't seem to be an understanding that the functionality is almost there. Surely, someone who coded the ability to draw tie lines, or slurs, across a line break (see the picture attached to this message, where I've drawn an interrupted tie between two high C notes) has the routine for drawing the ending portion that can be re-used. MuseScore can already draw tie lines into notes that aren't drawn as tie lines directly between two notes. At the very least, simply being able to indicate that a curved line needs to be drawn within the bar left of this (user selected) note, is a start on doing something useful.
In reply to Yet, you made it sound like… by Tim Seifert
@jeetee is one of many (207 up till now) code contributors.
As said earlier, long standing isn't really true, that issue is from September 2020.
There's a bunch of workarounds, listed with their pros and cons
Everyone here understands that ties across a volta is a thing and how it should look. Else none of the workarounds would have been documented.
In reply to Yet, you made it sound like… by Tim Seifert
Note that the "I won't do it because changing someone else's code takes time" was not my logic, but yours. If it is a decent enough reason for you to not immediately start fixing it, then why wouldn't it be a decent enough reason for me?
So here's what I see when I also look into this problem:
* The complaint isn't ignored at all; but on every occasion has been acknowledged by those involved. On top of that though, they've been helping out others to get their wanted notation with a workaround today rather than telling them to suck it up and wait for the event when it finally gets implemented
* Yes, the workarounds are far from ideal; the howto exists to try and minimize the blowing faces up part for the future. Although it being a workaround it is likely inevitable indeed, such is the nature of workarounds.
* There was one relatively recent forum user that indeed seemed to not immediately grasp what the problem is about. I think they have improved knowledge from your replies and thank you for also educating them. This is a public forum for all users and education is an important part of them.
* You very persistent that the functionality is almost there. Yes, there is a routine for drawing ties, even hanging them. You completely looked past the response that showed you that the internal data model however is not up to the task to mark a tie as having one starting point and two endpoints.
Unless you want to make a case for implementing it as an additional tie to be added between the starting note and the after-the-jump note in which the first part of the tie is not drawn (in some cases) and the 2nd part is. To my mind, that would maybe be almost acceptable but feels like a coded patch workaround and not a real solution. But then again, to make the assessment on whether the tie then would be of such an across-a-jump type would mean you'd have to understand jumps again; which brings us back to the previous remark of it being slightly less easy to pull off in a good structured way.
See my uploaded JPEG for what musescore needs to be able to do. I've hand drawn a few bars from a professional music book. The two "A" notes I've drawn arrows underneath are tied together. This how it's meant to be. Musescore needs to be able to do this, directly. No user kludges, no faking it. No rewriting of the bars to work around Musescore's inability to do this thing.
In reply to See my uploaded JPEG for… by Tim Seifert
See How to create ties leading into a 2nd ending for a workaround
In reply to See How to create ties… by Jojo-Schmitz
Yet another person who hasn't read what I said. The workarounds are THE WRONG way to do things.
If someone told you to use E flat because MuseScore couldn't do D sharp, that would be WRONG, too.
In reply to Yet another person who hasn… by Tim Seifert
Well, the workarounds are the only way to do it currently
That's what is the differences between a workaround and a fix...
And the current behavoir is not even a bug, it is just something that has not been implemented yet.
In reply to See my uploaded JPEG for… by Tim Seifert
Ah - it's much clearer what you want with the image.
So your intention is indeed that there are "hanging" ties (to the left) as I suggested. I've no idea if that is normal practice or not. If it is, then I agree that it should be considered, though the responses do suggest firstly that it might not be so easy, and secondly, since there is not as far as I can see a mountain pile of replies, that it would be of limited interest - though that consideration appears to have been applied to some of my suggestions earlier on.
For your example you could simply extend the volta by one bar on the left side and an unknown number on the right. That would also avoid the need to explicitly point out with arrows the left hanging tie on the right hand volta - though I don't expect you wanted those to be included in the final output.
How would you handle the case where the tie is to the first note of the first volta, but no tie wanted to the second volta?
Good luck with that.
In reply to Ah - it's much clearer what… by dave2020X
What you've referred to as "hanging ties" is normal practice, that's how many scores are done. It's clear from some people who haven't understood the on-going complaints about this inability that their music scoring and reading experience is limited. Don't discount lack of reports as it being unimportant. Many people will not bother making any bug reports. Many will have seen that there are complaints already, and not bother to add another. Many people will see that there are complaints that are being discounted, and not bother because it's obviously falling on deaf ears.
Rewriting someone else's score, which was already correct, is not the way to handle the problem. We don't write out glissandos in long hand, or any number of other alternatives that could be done instead of standard scoring techniques that have been around for decades, or even hundreds of years. Of course we could not use voltas, at all, and just write the score as a 10 page document that you read straight through.
No musician who knows how to properly read scores would need my arrows pointing out that those two notes are tied together. They'd play that "A" across the end of the first repeat and into the second volta. That's how you read such scores. If you didn't learn to do that, then there's decades of music books that you wouldn't be able to read properly.
When you tie two adjacent notes together (like that "A" into the first volta), that's immediately do-able and quite obvious. When you get around to typing in the second volta's notes, and type in that "A," THAT's the moment when you have either have some way to tie it to the "A" before the voltas (actually tie the two notes together), or at least have the program display it as the ending "A" (display the finishing portion of a tie line, even if the program doesn't know the two notes are joined together). Of course, if you didn't want the second volta to have the prior section's "A" tied into it, you wouldn't try and tie it.
In reply to What you've referred to as … by Tim Seifert
I'm sorry that my score reading experience isn't sophisticated enough. I have been reading scores for longer than I've been programming, and that - perhaps sadly - is a long time. As you noted however, being able to write code in a new and unfamiliar language - which might not even be suitable for a task - is not easy even for people who have written many programs before. Similarly, many people use music scores who are not explicitly aware of the issues in creating the notation for publishing, or other purposes.
I'm not now suggesting that there isn't an issue which should be addressed, and at least I accept that notationally there is perhaps a need for attention.
In other areas of life - such as writing articles, sometimes encountering problems like this suggests that maybe there ought to be other ways of finding a solution, and sometimes what you might consider to be undesirable workarounds highlight a problem which might sometimes be solved in a completely different way - which may on occasion be superior.
Regarding my last question "How would you handle the case where the tie is to the first note of the first volta, but no tie wanted to the second volta?" - would you have have hanging ties - with the right hand side not terminated - before the voltas and only one hanging tie at the start of the first - with the left hand side not started? Probably not - that still wouldn't work - so finding another solution might be the way to go. I am unaware of a notation for context dependent ties.
Tim Siefert wrote >> Can we finally (after YEARS of people wanting to do this) get note ties to work across voltas?
> + 1
I frequently need tied and slurred notes that extend into volta or extend out of volta. I'm aware of the workarounds.