voltas and ties
Please see attached.
3 bars are shown.
I want the last note of bar1 to tie to the first note of Volta 1.
I want the last note of bar 1 to also tie to the first note of Volta 2.
Also the underscore from the lyric 'free' should extend from the word 'free' into Volta2, but not show in Volta 1.
How do I go about this please?
Thanks in advance.
Neil.
| Attachment | Size |
|---|---|
| volta_with_tie.png | 34.19 KB |
Comments
Why do you need a volta at all?
The endings are identical.
In reply to Why do you need a volta at by ChurchOrganist
Oops! I oversimplified the example. The third bar has additional notes starting at beat 4.
In reply to Oops! I oversimplified the by neil
In that case I think the simplest answer would be to include the previous bar in the volta:-
use a slur instead
In reply to use a slur instead by Jojo-Schmitz
I have also used slurs and edited them to "fake" ties. I've also used the tie-like character in the Text Shmbols palette (add staff text, hit F2, click tie character, then select it in the text and increase font size. I have't figured out a way to deal with extneder, but you could always just draw a line.
In reply to I have also used slurs and by Marc Sabatella
Thanks to all for your suggestions. It's good to have such a responsive forum.
I decided to go with the 2 bar voltas.
This has been requested a few times:
http://musescore.org/en/node/625
http://musescore.org/en/node/1691
http://musescore.org/en/node/11640
I propose this:
1. Select the note(s).
2. 'Tie'.
3. Dialogue: 'Note(s) tie(s) into volta(s) with the same note(s). Select volta to tie into: 1, 2,' etc (tickboxes).
4. Tick the voltas you want it tied into.
5. 'OK' (and cancel option, perhaps?).
What about general repeats (or possibly other kinds)?
Does anyone have opinions?
In reply to This has been requested a few by chen lung
That all sounds good, but I'd make it more general. Remember, we also need to handle the case of the last note before the end repeat tying into the first note after the start repeat. And there are always those situations - like the "l.v." (let vibrate) notation used for piano, guitar, cymbals, bells, and some other instruments - where you just want the appearance of a tie that goes nowhere. Although that can be done by slurs.
Because the behavior in these cases is all slightly different, I'd propose that if the user hits "tie" on a note with no similar neighbor to the right. a dialog would come up, asking if you want the one side tie *into* or *out of* the note. You'd simply apply these to each note involved - the note before the first volta, the first note of the second volta, the last note before the end repeat, the first note of the start repeat.
You'd eventually want to get the playback behavior reasonable too, but I think think that would be fairly straightforward to implement (or at least, to see how it *should* work). "Out of" ties have the effect of tying the note to the next *played* note, as opposed to the next *visible* note. "into" ties are for show only.
In reply to That all sounds good, but I'd by Marc Sabatella
I agree it would have to be fine-tuned, but it's an idea to work on. If you want to describe a more complete version, it could be put into the issue tracker.
What you mention about the unconnected tie should probably be as such (not as a slur).
In reply to This has been requested a few by chen lung
If possible we should avoid interrupt the editing process with a dialogue.
There maybe ways to mitigate or address each of the problems mentioned above, but can we explore another option? If their is a tie into the first alternate ending, add a "backward*" tie into every alternate ending that has a note on beat one. If there is a rest on beat one of any of the alternate endings then don't add a "backward" tie to that rest. If the user later replaces that rest with a note, add the expected "backward" tie at that time.
This takes care of every instance I can think of (a laissez vibrer tie would only tie into a rest). But if there other exceptions we could allow the user to select the backward tie and press Delete to remove it for a particular note. (To get the tie back probably they would need to re-enter the note).
*Any tie that starts before the note, rather than after it.
In reply to Without dialogue boxes by David Bolton
Using that same approach, add a backwards tie into the first note of a repeated section if the user adds a tie out of the last note of the repeat.
My main concern with thus automatic approach is that it is an awful lot of things being done automatically, and hence lots of opportunity for MuseScore to get something wrong. I completely understand and agree with the understand the objections to the dialog. But I would now propose instead a simpler mechanism that could live in conjunction wth the completely automatic one proposed above: simply add a new command to add a one-sided tie, and then have a property you can set on it after the fact to mirror it horizontally and convert it between forwards and backwards (perhaps via the existing "mirror" command). The initial position of this one-sided tie could be always forward, always backwards, or perhaps selected automatically using a very simple algorithm like assume backwards for the first note of a measure, forwards otherwise.
Really, I'd be OK with that *instead* of the completely automatic approach where ties are added for all voltas and te system has to check for this condition to see if at tie needs to be created every time you added a note. But I gather most prefer things be automatic.
In reply to Using that same approach, add by Marc Sabatella
Hi, just for reference, the laissez vibrer feature was already on the issue tracker. The 'beginning' ties are already implemented, but the 'recieving' are not. I've recently spit the issue for the last ones. See:
#14437: Laissez Vibrer: Chords tied to nothing
#17595: Notes receiving unconnected ties
In reply to Just for reference by guifre
Right, I wasn't aware of that until recently. But FWIW, I still like the approach I suggested above: The current algorithm for inserting forward half-ties depends on whether the next note is of the same pitch or not, and it shouldn't. For instance, the last note before an end repeat in the first volta should not connect to the first note of the second volta, even though they are physically adjacent and may happen be of the same pitch. Also, the current algorithm doesn't create a half-tie if the next note is the same pitch but is separated from the first note by a rest - you end up with a tie over the rest. So the implementation needs to be tweaked anyhow. I think it would be much more straightforward to simply have a half-tie command. The existing code could be moved there and wouldn't have to worry about those corner cases - it could always create half-ties. If it were to always create forward half-ties, the code is practically done. We'd just need the "mirror" command to flip it into a backward half-tie. THis would be the easiest to implement and wouldn't require anticipating every possible corner case of usage to make the regular tie command do the right things automatically. If someone were to also strive to add some automation to the regular tie command, that's fine, but I think first effort should be to just providing a clear and direct way of creating half ties, both forward and backwards.
In reply to Using that same approach, add by Marc Sabatella
Much of the automated behavior is what annoys me the most about Musescore. For example if you are editing a note toward the beginning of a measure and make it an accidental natural then Musescore decides upon itself to add additional sharps or flats to the following notes of the original pitch to force them back to the key signature which more often than not is unwanted.
The main wanted automated behavior is the spacing of the notes which is nice but changing flats and sharps without a user issued command is most unwanted. Now in the case of ties to the second ending, it should be more or less obvious that a note that's tied to the first ending would also be tied to the 2nd ending. This is an automation that should be taking place but not only does it not happen, it's very difficult if not impossible to correct it at least in an easily understandable manner.
Let's say that you didn't want the tie: Most ties are easily deleted. But you can't select the end note of a measure in front of 1st and 2nd endings, and then the first note in the second ending and get a tie. It's completely ridiculous. I use Musecore, but i never have considered it user friendly in the same sense that Inkscape or Gimp is. A learning curve is one thing, cul-de-sacs are something entirely different.
In reply to Much of the automated… by gBouchard
Thinking of MuseScore as adding accidentals is missing the point. The idea is, you originally entered an F# later in the measure, then you change an F# to an F earlier in the measure, MuseScore will kot automatically change the later F# as well. That would be automatic behavior, and I think it would be undesired most of the timin. After all, just because you change one note doesn't mean you want to change others too. The only time that would be true is if you actually meant to enter them both as F but made a mistake. a new command to automaticallyfix multiple errors at once might be nice, but it would be bad to make the usual non-error case worse.
This topic could extend to glissando (and possibly some other elements?), although more in the situation of repeats. The proposed prompt could apply here.
1. Open attached score (produced in 1.3).
2. Drag glissando to the final note of bar 3.
Potential results: The glissando connects to either: the first note of bar 2, the first note of bar 4, or both.
Actual result: The glissando connects to the first note of bar 4.
Using MuseScore 2.0 Nightly Build (4c859d8) - Mac 10.7.5.
In reply to Glissando in repeats by chen lung
Yeah Marc, Chen and indeed all. I don't remember see this before but it's really important.