At 8:06 PM 09/22/02, David W. Fenton wrote: >I had a score that printed out correctly, but I made the mistake of >looking at the source text in EDIT LYRICS and saw a lot of excess >hyphens, many of them at the *beginning* of syllables. So I was >deleting a few and seeing what happened. The first few seemed OK >(redundant hyphens should have no effect, right?), [...]
Right. "At the beginning of syllables" doesn't have any meaning in this system. I assume you mean that in the text stream there is a space before the hyphen but not after. Logically, there is no difference between "hal- le- lu- jah" and "hal -le -lu -jah". The hyphen does not exist as part of a syllable at all. A hyphen is a separator between syllables, so logically it can't be part of any syllable's text. The separator might be made up of any number of hyphens and spaces, but it behaves like a single hyphen-separator regardless. In type-in-score, I don't see how you can think of the hyphen as part of a syllable at all, since it acts as a key that moves from one syllable to another. You *can't* type a hyphen into a syllable (unless you use the special character). As soon as you type the hyphen key, the cursor jumps to the next note and starts editing a syllable there instead. It's the same idea as the tab key or right-arrow key, with the only difference that if you advance using the hyphen key the program will add a hyphen to the text stream after the syllable you just left if there isn't already a hyphen there. If the hyphen is already there in the text stream (eg, if you type multiple hyphens to advance forward several notes), then the hyphen key acts identically to the tab or right-arrow key. The hyphen key behaves the same regardless of where your cursor is within a syllable. If you put your cursor at the beginning of the syllable then type a hyphen, it still moves to the next note and adds a hyphen after the syllable -- just as the left arrow still moves you to the previous note regardless of whether your cursor is at the beginning or the end of a syllable's text. >I finally discovered that using TYPE IN SCORE, when you delete a >syllable that was input in TYPE IN SCORE with a typed hyphen, the >letters are deleted but the trailing hyphen sometimes? always? >occasionally? gets attached to the next syllable. These are the >hyphens, I believe, that were causing the problem. Deleting a syllable from type in score never deletes the hyphen, because it is not part of the syllable at all. It is not "attached" to anything, except in the sense that it has a position in the text stream between two syllables. When both of the adjacent syllables appear in the score, regardless of where, the hyphen will be placed between them. If one of the two adjacent syllables doesn't appear anywhere, then the hyphen doesn't appear at all. If the hyphen is at the end of the text string and thus has no following syllable, it will appear between the preceding syllable and the end of the score. If the hyphen is at the beginning of the text string and thus has no preceding syllable, it is ignored. There are various ways in which type-in-score might result in a hyphen failing to appear on the page. For instance, if you enter "hal-le-lu-jah" and then delete the note with "lu" on it, what will appear in the score is "hal-le jah" rather than "hal-le-jah", but that's not because the hyphen has disappeared; it's because the "le" and "jah" syllables aren't adjacent in the text string. There are also ways in which a user might reasonably think that he has entered a hyphen, but because of the way the input system works he has not. For example, if you type "hal-le--jah" (typing two hyphens to skip past the third note), then use the left-arrow to go back to the third note and type in "lu", you might reasonably think that you should end up with a hyphen between "lu" and "jah", since you've already typed a hyphen between note three and four. In reality, the hyphen keystroke you made there served only as a function to advance your cursor. If, in this example, you had typed a hyphen after entering "lu" at the end, everything would come out as you want it. All of this is a result of the disjunct between the type-in-score UI and the underlying data, which you correctly criticize. It would perhaps be a step in the right direction if, when you select a syllable in type-in-score, the program checks to see if that syllable is followed by a hyphen separator and, if so, displays a (single) hyphen on the screen in the selected text. When the syllable is de-selected, the hyphen could return to its regular display behavior. Or perhaps it would be even better if instead of displaying the hyphen alongside the text (which would reinforce the idea that it is somehow part of the syllable), some distinct display would show on either side of the syllable to indicate the existence or non-existence of a hyphen before and after. It would also be a help if when a syllable is selected the display somehow highlighted the syllables that are directly before and after in the text stream (including an indication if one of the adjacent syllables is unassigned). All of this would make it a lot easier to see what's going on in the data when using type-in-score, and would make it easier to recognize and fix peculiarities that might arise from irregular type-in-score editing. If the UI were designed tastefully it could do so without being distracting when you don't need it. (Or maybe it can be turned on and off as a "view details" sort of option.) More to the point, it could shape how users think about the data. Ultimately, I think that considering a hyphen as part of a syllable is just fundamentally misguided, because -- aside from any programming issue -- it just doesn't behave that way in printed music. A lyric hyphen isn't a text character at all; it is a marker indicating that a certain hyphen-drawing algorithm needs to be performed between two syllables. This is true even when one is engraving by hand. >So, the difficulty here is all in the UI of TYPE IN SCORE. Exactly. That's one of the reasons I don't like to use Type-in-Score. By the way, the suggestions I made above seem to me like they would help, but I'm just tossing out ideas. I think we all agree that the UI needs to be improved to better communicate the data, but I'm probably not the best one to make recommendations on how it should look, since I rarely use Type-in-Score anyway. I'd be curious to know what frequent users of Type-in-Score think about this sort of thing. >But I feel *very* uncomfortable with click assigning the lyrics. One >problem is the size of the dialog and the fact that it is tough to >tell where you are in repetitive text. But I discovered another >problem trying it out today -- the score doesn't automatically update >properly, even when you check off the checkbox for that. So, I'd be >assigning lyrics, but couldn't see the result onscreen. Because of >this, I only did about 5 measures of it, as I just cannot get >comfortable with flying blind in something that is so incredibly >prone to problems. By "automatically update" I gather you mean Automatic Music Spacing and/or Automatic Update Layout? I never use either options, so I wouldn't know. If this is a problem, I suppose that could be one more reason why click-assignment doesn't work as well for other users as it does for me. >[...] >As I've said repeatedly, Mozart's Requiem DOES NOT HAVE MULTIPLE >VERSES. And as I've replied repeatedly, I don't mean verses in the literal sense of the word, I mean the "verses" as provided in Finale software. How many times do we have to go through this? As I've already explained, in the case of Mozart's Requiem, my instinct would have been to put the different voice parts into different "verses". If all the movements are to be in a single Finale file (which isn't my usual practice), I'd also use separate verses for the texts of different movements. (Myself, I probably would also separate the "requiem" from the "kyrie" in No. 1, and the "benedictus" from the "hosanna" in the No. 11, though I'm guessing most others wouldn't go that far.) I like keeping distinct chunks of text separate, so that makes sense to me. You're telling me (again) that this doesn't feel logical to you. I know, I heard you the first time. >I simply cannot see how anyone could possibly type in the lyrics for >a piece with as much repetition as in the Requiem, and not lose track >of where you are in the repetitions. As I said before, maybe it's a consequence of being a singer. Maybe it's something else, I don't know. I just know that I don't have any serious trouble with getting lost. Now, if I were to go into the Click Assignment window and start bouncing back and forth throughout the text, I suppose it might be confusing, but I never do that. >Well, I'm not about to start using click assignment, because the UI >is too scary for me to become comfortable with it. I do know that I >should never try deleting lyrics with TYPE IN SCORE if hyphens are >involved, because that leads to excess hyphens in the source text >stream. Other than that, I can work around it. It's true that deleting a syllable with type-in-score never removes any hyphen from the text stream. If you delete a syllable which had a hyphen on either side of it in the text stream, that will result in redundant hyphens in the text stream. But those redundant hyphens have no effect, so I fail to see the problem. In fact, it seems to me that if you've got a syllable you want to delete, then deleting it in type-in-score is safer than the alternatives. (In earlier versions of Finale, it was different, by the way. Each hyphen acted as a separator, so that there were null syllables between multiple verses. This was problematic, and it has been fixed.) It might be a nice feature to automatically trim redundant hyphens and spaces whenever editing the lyric text causes them to come about. Logically, the redundant hyphens are irrelevant, and in a more communicative type-in-score UI as described above, they wouldn't need to appear at all. This option would only exist for the sake of type-in-score users who visit the Edit Lyrics window and get confused by it. A potential disadvantage of this is if the feature causes changes in the Edit Lyrics window to unusual which an Edit Lyrics purposefully entered. I doubt that anyone makes intentional use of redundant hyphens, but we do make use of extra spaces and carriage returns (sort of like many programmers do with their indents, etc.) Still, with a little forethought, I think this problem can be avoided. For one thing, the whole feature could be one which might be turned off. Also, if it's only triggered by exit from a syllable in type-in-score, then users who don't use type-in-score would be unaffected by it. >Actually, I'd think it would be *easier* when you already have a pre- >existing text to work from, as you have the repetitions of the text >already laid out for you, whereas when you are composing, you don't >know beforehand where the text goes. Knowing what I know about lyrics >now, should I ever compose a piece with text, I am certain I'll do >the text underlay on MS paper before anything goes into the computer. >It's obviously *much* too risky to put lyrics in until the point at >which everything else is entered, and given that words always drive >the musical fabric, during composition, text comes first. The bulk of my work is either straight engraving or adaptations which involve editorial changes but no major rearranging. My lyric placement habits have evolved accordingly. As I mentioned, on those occasions when I'm composing or arranging, I'll frequently put in lyrics ad hoc, and then clear them out and reassign on a later draft when I'm more sure of what I want. I don't find that to be particularly onerous, and it matches well with my creative process. >That means Finale is utterly useless for that kind of composing, so >far as I'm concerned. "Utterly useless" sounds like another exaggeration to me. >Well, in the end, had the messed up lyrics been at the beginning of >the source text stream, your advice, however Draconian it sounded, >would have been correct. Given that the corruption was in text 3/4s >of the way into the text stream, my efforts to rescue it were the >right way to go. Got it. Incidentally, if I had encountered a similar situation and I recognized the corruption as being 3/4 of the way into the text stream, my response would have been to delete all the lyrics from that point on and re-enter (with click-assign) from there, rather than delete them all. Not having seen your file, I had no idea where the messed-up part was. If there were a case like yours but with the corruption in the bass part, so that it was in the first quarter of the text stream rather than the last, and I were given the file to repair, I might have replaced the munged text with null syllables so that the remaining three verses were unaffected, and then I'd redo to the munged staff in a separate verse (or, if you insist, at the end of the same verse). Yes, I realize that this isn't an acceptable cure, since it requires unduly geeky knowledge of how the data works. I'm just saying that if I were faced with such a situation, that's a repair technique I might use. >I hope this is a priority for Coda. It is certainly by far the worst >part of Finale I have encountered in a long, long time. I'd love to see them improve the lyric system, though admittedly I'm far more interested in fixing up peripheral details like word extensions and improved spacing, as opposed to redoing the data structure (not gonna happen) or revamping the UI (possible). I've been saying this since version 3.0, and although we've seen several improvements since then, lyrics have never been a priority in upgrades. I assume that it's because users who care about lyrics are a minority. Even those users who do employ lyrics are primarily non-engravers who don't much care what they look like. In the world of low-budget performing, I've seen all sorts of amateur scores with lyric syllables smashed together every which way. I was in a show recently where the composer had entered all lyrics (not in Finale) with no hyphens at all throughout the entire score. (In a few spots it became an amusing little puzzle to figure out what the words were.) mdl _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
