Melismatic baseline won't span rests
Is this a bug, or just something that hasn't been addressed yet because it's not that common? In setting the lyrics to a Handel aria ('Da tempeste' from Julius Caesar in Egypt) I have run into a problem during the lengthy melismatic passages, such as that from measure 17 to 22 (see below). It begins with the word desiar and the last syllable of that word is sung through a complex colouratura passage including rests, trills, and you name it. Handel really wanted to give Signora Cuzzoni a chance to show off on this one:
But as you can see, I cannot get the program to set a continuous baseline extender. It stops dead at the first rest after the end of 'desiar'. The only way I can get the program to set a baseline after that is to start with a new 'word' (I used a period as a workaround to get this image) after each rest, followed by the baselines up until the next rest. And nothing will get me a baseline under the rest.
This isn't professional, and it's a major pita. Any suggestions from the brain trust?
Comments
You could fake it using a line from the lines palette
In reply to You could fake it using a by Jojo-Schmitz
Yes, I suppose so, but that would be problematic when it comes time to do the page layout. Those lines from the palette don't have any respect for the ends of systems, and have a nasty tendency to run right off the edge of the page into nowhere when the system breaks change.
Is this something you guys could address in a fix? I know long melismatic passages like this aren't common in popular music, but they are in opera.
In reply to Yes, I suppose so, but that by Recorder485
I would enter a second melody line in another voice beneath the real melody, it doesn't have to be the same rhythm, it could be whole notes. Then mark them all invisible and not to playback, then re-enter the lyrics against the new melody line. You might have to mark some rests invisible as well.
In reply to Yes, I suppose so, but that by Recorder485
Yes, this is a workaround only and probably not the best.
Guess it's time to report this as a bug?
In reply to Yes, this is a workaround by Jojo-Schmitz
Miseria.mscz Hi all,
Simpler workaround: use dummynotes instead of rests first.
Add melismatic extender. Delete dummy notes.
In reply to [inline:Miseria.mscz] Hi by MichLeon
Oops. Sorry for the inclusion of the attachment 'Miseria', not a composition of mine!
I'm new to this beautiful community.
In reply to [inline:Miseria.mscz] Hi by MichLeon
Thanks, that works quite well. I'll use that method until Jojo and the boys find that bug and squash it. ;o)
It is curious to me, though, as to why that sort of workaround does indeed work; I've forgotten the details now, but there was another situation recently that I solved (more by luck than logic) in a similar manner and I remember wondering about it then, too. In theory, if two elements are so linked that one is dependent for its existence or behaviour upon another, then altering or removing either one should logically alter or remove the other. Or so I would think. Not that I'm complaining in this particular case, of course.... ;o)
In reply to Yes, this is a workaround by Jojo-Schmitz
Yes, I would think it is indeed time to report the bug. ;o) Although the 'dummy note' workaround appears to be a usable one, it would be much better if it weren't needed. It is not obvious what the problem itself is at first, and just diagnosing it can be time-consuming.
When I encountered the problem, my first thought was that my file had somehow become corrupted, since I was doing everything properly but not getting proper results. So I deleted all the lyrics entered so far, saved, closed, and re-opened. Which of course solved nothing, so I went to theory (b): MuseScore itself was hanging or getting ready to crash, so I closed the score again, then the program, and restarted both.
By the time I got to theory (c)--that my OS was hiccoughing, probably through lack of temporary memory (I generally operate with a lot of windows and tabs open) and that it was time to reboot EVERYTHING--I was thoroughly annoyed, so I shut down and went to dinner before giving in to the temptation to fix things with a hammer. It wasn't until several hours later when I came back to find the same problem that it finally occurred to me that it might have something to do with the rests.
Do you see it printed that way in published scores? What I'd expect is to see the syllable repeated in parentheses after each rest to make clear to the performer what is happening. That's better than using a period. You could use an empty lyric (Ctrl+Space), but I really think the actual syllable in parewntheses would be best.,
If you prefer the line to extend under the rest, simply enter a note instead of a rest, add the lyric & extender, then delete the note leaving a rest in its place (ooops, as suggested earlier as well).
Not sure I'd consider it a bug that this doesn't happen automatically. In the majority of cases, extending a syllable over a rest would be operator error, and I think it's not bad that MuseScore doesn't allow it by default.
In reply to Do you see it printed that by Marc Sabatella
To answer your first question first, yes and no. In the Walsh first edition (which is not indication of modern practise, of course) the melismas are indicated with a series of = = =. In Chrysander (which is a better guide to notation, but is, as usual, full of Chrysander's unidentified editorial 'adjustments'), the standard baseline extender is used continuously under the entire section, rests and all. Modern practise concords with that, for all terminal syllables. Dashes (hyphens) are used for extending intermediate syllables.
I don't remember having seen an edition of a score or vocal part with the syllable itself repeated in parens as you suggest; perhaps that's a convention in popular music or jazz, with which I am relatively unfamiliar.
Second, we disagree on the question of whether the program should allow a continuous baseline extender under rests. For one thing, MuseScore does allow a continuous series of melismatic dashes to be set throughout sections containing rests, even though it does not allow baselines under the same circumstances. So there's a dichotomy of logic there that needs to be resolved. For another, while the 'dummy note' workaround does work, it's a time-consuming procedure and shouldn't be necessary in a program like MuseScore which is fast becoming one of the best-regarded scorewriters available.
My feeling is that MuseScore should definitely set baseline extenders under rests as default behaviour, so long as the extender starts before the rest and continues past it. In other words, yes, it's fine that MuseScore automatically skips past rests when one hits the space bar--saves a bit of the typographer's time--and there's obviously no point in printing a new syllable under a rest...but since colouratura passages of this sort are common enough in operatic material, until you guys fix that bug there are going to be a bunch of users grumbling every time they have to shift into note-entry mode to enter a dummy note, shift back to lyrics mode to create the baseline as it should be, shift out of lyric mode to delete the dummy, and shift back into lyric mode to continue setting the lyrics. In something like Da Tempeste, there are numerous passages with numerous rests; that workaround process took me approximately as long as it took to set all the rest of the lyrics, thus doubling my work.
If it turns out to be too complicated to code the conditional exceptions I mentioned above so that MuseScore can recognise them and react appropriately, I would have no complaint if we lost the automatic skip over a rest on the space-bar. A flick of the thumb is a heck of a lot less trouble than all that other stuff.
Hope I've persuaded you to reconsider, Marc.
Thanks.
In reply to To answer your first question by Recorder485
I have no strong opinion; as I said, I'm "not sure" :-). I do see that in your particular case case it seems like a win to make this change. But it's tough to anticipate what other cases there might be where it might seem a step backwards, or whether your use case is common enough to merit the risk to others. Maybe there is no risk, and maybe your use case *is* common enough. Again, I'm not sure. I just know that all too often we make changes to make one use case easier but inadvertently break something else. So I'm just saying, we should consider this carefully before jumping to any conclusions.
In reply to I have no strong opinion; as by Marc Sabatella
Well, you and Jojo and the other genius code-writers would know far better than a dumb typograpaher like me how much is involved in fixing one problem without creating another. I DO know that Baroque opera is full of stuff like this, and I SUSPECT that anyone wanting to set scat-singing lyrics in a jazz score (does one even do that??) might run into the same problem. But the guys producing EZ-Play Editions of Blowin' in the Wind or Stairway to Heaven probably won't care much one way or the other. ;o)
As I said, it wouldn't bother me much (if at all) if I had to flick my thumb an extra time to jump over rests on which nothing is happening. I am totally incompetent to evaluate the difficulty of writing code to differentiate between an element which starts on a rest and one which continues through a rest. For that, I rely on you guys.
Thanks.
T.H.
In reply to To answer your first question by Recorder485
FWIW, Elaine Gould's "Behind Bard" (the modern "bible" for matters of notation practice) suggests extending the extender under short rests as in your example. For longer rests, she recommends *not* extending the extender under the rest but instead starting up again with a new extender beginning with the syllable in parentheses as I suggested.
Your suggested design - letting space continue to skip rests but having underscore extend under rests - does seem likely to be good.
In reply to FWIW, Elaine Gould's "Behind by Marc Sabatella
Is that something you could code without having to rewrite the whole segment on lyrics input? The very little I know about writing code (REALLY very little) harks back to the days of my HP 'reverse Polish notation' calculator and the occasional foray into html for dummies....
In reply to Is that something you could by Recorder485
It's likely not hard, but Miwarre is really the one who wrote most of this code - he did a big overhaul to vastly improve on how it worked for 1.3. Also, he'd have a better sense of whether there are any reasons *not* to do this.
In reply to It's likely not hard, but by Marc Sabatella
Well, since he's the one who pushed the fix for an option to set the spacing of melismatic dashes (on my request), I'd be more than pleased if he'd offer his opinion on this question. Is there a way to let him know about this discussion?
Trying to summarize the situation:
A) The 'automatic' detection of rests (and their skipping) has been so far considered a 'feature' (which I found already existing when I recently updated this part of the code) but
B) The OP reports a case where it can be reasonably considered a 'bug' or at least a limitation.
Melismata across rests do occur and, while personally I am not that fond of over-long melisma lines which might look as turning a 5-line staff into a 6-line tablature (!) and may puzzle some reader, I agree that it is something which should be addressed.
____________________
I see at least 3 cases:
I) The current 'standard' behaviour: rests are skipped and continuing with the melisma (pressing '_') after a rest results in no lyrics at all under the following note(s). I might be wrong, but this seems to me particularly convenient in 'common' situations if the user presses the '_' too many times. As 'usually' the note after the rest has a syllable, if the '_' key is pressed too many times forgetting the syllable, a totally empty lyrics is a more visible alert of the error than a 'something' visible (the line) lacking the actual syllable.
II) A possible 'resume after rest' behaviour: rests are skipped (the line is interrupted), but continuing to press the melisma short-cut will resume the melisma line after the rest, even without any new syllable being entered.
III) A possible 'fill the rest' behaviour: rests are NOT skipped and a previous melisma is carried over no matter what is above it (notes or rests).
The difference between I) on one side and II) and III) on the other might be relevant to accommodate different use cases, as outlined above.
The different between II) and III) might be relevant to accommodate, for instance, the distinction that Gould makes between 'long' and 'short' rests, where the former are better skipped and the latter are better connected. As the programme cannot be expected to make this sort of stylistic decision for the user, it would be convenient for the user to have a way to choose.
____________________
So, it would be nice to have all three, if possible. And I believe it IS possible, for instance by adding a new action (and its corresponding short-cut); by lack of a better name, I'm calling it "extra-melisma" for the moment. It could work in this way:
I) By using the current "melisma" action ONLY, the current behaviour would remain in effect: rests are skipped and when notes resume, nothing is entered.
II) By using the "extra-melisma" action when notes resume, a melisma is resumed after the rest(s), if a melisma was in effect under the LAST note before the rest(s); otherwise, same as I).
III) By using the "extra-melisma" action UNDER THE (FIRST?) REST(S), a previous melisma is carried over under the rests and continues under the following notes when they resume. If there is no previous melisma, same as I)
It is my feeling that this would not be tremendously complex to implement, if some tolerance is allowed for corner (and usually undecidable) cases like, under a sequence of rests, mixing the two melisma actions or mixing melisma and space (in those nonsensical cases the programme should be allowed to generate nonsensical results). Also, the use of a new, separate, action would minimize the risks of introducing regressions.
____________________
Two more points:
1) This is going to be a 2.1 feature, as the presence of melismata under rests is very likely going to affect the file structure.
2) No idea about which default short-cut to use for the "extra-melisma" action, as [Ctrl]+'_' is already used for 'hard' underscores and '_' already uses [Shift] by itself in many keyboard layouts. Suggestions are welcome.
In reply to Trying to summarize the by Miwarre
Alt+_ ?
In reply to Trying to summarize the by Miwarre
Thanks, Miwarre. I appreciate your analysis. Two questions and a comment come to mind:
Comment: I don't actually see the need for defining behaviour II as distinct from behaviour III, since restarting a melismatic baseline after a rest is already possible under the default behaviour I. If one wishes to use Gould's style and repeat the syllable in parens at the re-start, it's no more complicated than entering any other lyric. If one wishes to re-start after the rest with a simple baseline (no lyric) that can be done by typing CTL+_ to enter a hard baseline as the 'syllable', then continue as usual.
Question 1. Default behaviour right now is I and we're proposing to add a new behaviour III . Should the decision as to which behaviour to use be (a) implemented automatically by MuseScore based on the situation at the given point in a score, or should that choice/decision be (b) left entirely to the user?
Question 2. If (b), the further question arises as to whether the 'extra-melisma' capability should be accessibe only by keyboard shortcut, or if it could also be set as default behaviour by, perhaps, a checkbox ('allow baseline extenders to run under rests') on the STYLE>Text>Lyrics menus.
In reply to Thanks, Miwarre. I appreciate by Recorder485
@Recorder 485, about the comment: II) and II) were distinct in the analysis for the sake of clarity but, if you note, in the proposed implementation, a single extension is used for both (depending on when the "extra-melisma" action is used) and I believe that the final user perception would be that of a single 'thing'.
About question 1: I consider important to leave the choice to the user on a case by case basis; I am always suspicious of 'automatisms'... This is my feeling but, if anybody sees serious complications with this, let's discuss.
About question 2: the 'standard' melisma can be entered only via the keyboard; I believe that having the "extra-melisma" also as a keyboard stroke would only be consistent. Incidentally, as I see it, this additional action would not be a toggle ("now I want lines under rests | now I do not want them"), but it would, by itself, visibly create the additional line segment, forcing it to exists even under rests: it would not be used in adddition to the standard "melisma" short-cut, but in stead of it; perhaps a better name could be "force-melisma".
Incidentally-bis: all the text styles ("Style | Texts| ...") have the same structure, setting the same set of parameters in each text style; adding an extra item specific for the Lyrics style would be much more complex than it may look at first sight. In case, the option should be in the "Style | General | ???" menu; but note that none of the score style parameters in "Style | General" is a behavioural toggle: each changes all occurrences of the corresponding elements in the whole score, as they are "score styles" indeed. So, my feeling is that a keyboard short-cut would be clear, consistent and easy to use (after all, while entering lyrics you are already using the keyboard).
@Jojo-Schmitz: [Alt] is a tricky key, often already overloaded by the OS; but if no better option pops up, it might be a solution.
In reply to @Recorder 485, about the by Miwarre
My original thinking was that from a user point of view the convenience of having the input field skip past rests automatically is relatively unimportant. In other words, I thought to have the lyrics field behave in the same way that the figured bass field does, advancing to the next staff element whether it's a rest or a note. After all, what's an additional flick of the right thumb now and then? No big deal, really. I understand your point about having the baseline vanish so as to leave a blank space to warn the user of an input error, but I can't agree that that outweighs the inconvenience we're facing now. Besides, MuseScore can't possibly detect and warn the user about every possible input error in a similar manner without severely limiting its functionality.
Then I started wondering if perhaps some sort of decision tree might be built to determine when it would be appropriate for MuseScore to place a melismatic baseline under a rest (proposed improvement), and when it would be appropriate to skip over the rest (current default). But in trying to construct such a 'tree' myself (with my VERY limited experience programming RPN pocket calculators thirty years ago), I discovered that it's more complicated than it seems. There are too many possible variations in score configuration to query each possible condition without adding thousands of lines of code, and each query would require parsing the entire score from that point forward, slowing down the process enormously, especially for big orchestral scores. So I have come to the conclusion that you are right, and automating this function is probably a bad idea. After all, as I suggested above, the user does have a certain responsibility.
That said, I can address your points about having a toggle.
My intention in suggesting that was indeed to create a score-wide style change, but I had not noticed, until you mentioned it, that all the text-style dialogues were the same. I can see that now and obviously you're right that modifying one of them for this would be a poor approach. However, the question arises if there might be another control dialogue where it could be put without rewriting everything surrounding it. Perhaps create a 'Lyrics input' tab in 'Preferences' (which would, I understand, affect ALL scores)? This could have toggle options and parameter inputs for a number of elements, such as the spacing of melismatic dashes we discussed a month or so back, choice of default font, what character and size to use for the dashes (hyphens, or en-dashes), thickness for the baselines, etc. I'm just brainstorming here, of course.
Finally, it seems we may indeed come down to choosing a simple keyboard shortcut. I first thought as Jojo did that ALT+_ might be appropriate, but ALT is an awkwardly placed key on most keyboards, and there is always the question of L-ALT or R-ALT. Might I suggest a simple + sign, which on most keyboards is right next to the underscore? It's used for a different function in figured bass, of course, but would that cause a problem? You could also consider the = sign, but that is sometimes used in old editions for melismata (see Walsh's edition of Julius Caesar in Egypt).
I think this used to be possible in 1.3, and whilst series 2 will import these, they cannot be created or amended in such version.
In reply to I think this used to be… by chen lung
That's not true, see above for the solution - extend melisma line under dummy notes, then delete the notes.
In reply to That's not true, see above… by Marc Sabatella
You're right - thanks Marc.