At 2:42 PM 09/12/03, Noel Stoutenburg wrote: >Actually, you don't move to the next syllable box in my example, because the >"seven" is on the last syllable of the line. [...]
Thanks for filling me in on this. I don't use type in score regularly, so while I'm familiar with its basic behavior, I don't know the details. I know that typing a hyphen advances to the next syllable, but I didn't know what happens when there isn't a next syllable to advance to. >> you aren't inserting a hyphen character at all; you're creating a new >> syllable in the middle of the list and shifting every syllable that follows >> it. > >Yes, exactly. Attempting to do the same thing, that is, hyphenate "seven" into >two syllables, yields different results if one attempts it in type into score, >than if one attempts the same thing in "edit lyrics". If instead of trying to >hyphenate a word, one had run two words together, and attempted to insert a >regular space, one would also obtain different results in "edit lyrics" box, >and type into score. Maybe this is just semantics, but I don't see how anything that involves splitting a syllable can even be considered the same in type in score and edit lyrics at all. If you're editing within a syllable, fine, but as soon as you start moving syllables around it's not just editing text. If you add a syllable in the edit lyrics box and it's not at the end of the text, then you're reassigning all the syllables. There is no equivalent in type-in-score. >My position is simply that the two editing methods should >have the same result, or if this is not feasible for some reason (and I'm >willing to concede that it might not be), then this should be clearly >documented in the on-line manual. I happen to think that much could and should be done to remove a lot of the weird inconsistencies, such as the redundant hyphens that can appear with certain type-in-score combinations, but ultimately they're two different functions and should be. The ability to shift lyrics in Edit Lyrics is useful, if only for the cases when you type it wrong the first time and omit a desired space. Would you really want Type-in-Score to do the same thing? ie, when you type a hyphen it bounces every subsequent syllable forward. Maybe you would, but I think that would just make it even more confusing. I guess the bottom line is I just don't think of these two functions as supposing to be parallel in the first place, any more than, say, Apply Beat Spacing and manipulating the Beat Chart. Either one manipulates the same basic data, but in different ways. To whatever extent you make them more the same, it defeats the purpose of having two different methods. >Well rather than a special code character, I would say that the hyphen is a >hybrid, in that the "ordinary" hyphen instructs the software to do two things: >while typing into score, to advance to the next syllable, if there is one, and >when being interpreted in processing for a score, to place zero or more hyphens >in the score between the syllable immediately preceeding, and immediately >following it, the number depending upon the distance between those two >syllables. Exactly. The hyphen instructs the software to do something special. That's why it's a special character. I suppose you're right that it's a hybrid, and that's the problem. The fact that the instruction is tied to one specific character is what makes treatment of syllable separation so restricted. >I've used an hexadecimal editor to inspect both "~.ETF" files generated with >Finale, and document files created with my word processor of choice, and while >I see the tags you refer to in the word processor files, I see no sign that >Finale makes use of these "tags", so there would not appear to be anything to >type in. OK, you've looked at the raw data and I haven't, and as as result I referred to "tags" that don't exist as such. However it's coded, the hyphen is an instruction to the software to do various things. I assume they do in fact have some sort of tags embedded in the text, for font changes and so forth. I'm proposing that the hyphen and space be implemented as tags as well, because it will increase enormously the flexibility of how syllable separation is treated. As you said, the hyphen instructs the software to advance to a new syllable and draw a certain number of hyphens between the preceding and following syllables. Suppose instead of the hyphen character there is a tag <ns>, for new syllable. This instructs the software to advance to the next syllable. The tag has a parameter "rule" to tell it what to do between the syllables. <ns rule=hyphen> would insert the hyphens between syllables according to the default rule; <ns rule=space> would insert nothing in between. The rule for placing the hyphens between syllable has various parameters such as which character to use, space between hyphens, and so forth. Currently some of these default parameters can be changed and some cannot. You and I agree that the Lyric Options allows the user access to more of these defaults -- space between hyphens, baseline shift of the hyphen, and default character (including font attributes), etc. This alone adds flexibility to style of "hyphenation", allowing, for example, imitation of the old Ricordi style with its baseline dashes. All of these parameters are also available as parameters in the tag. If the parameters aren't specified, it resorts to whatever default is set for that document, but if you need to change something for one particular syllable separation, you can. Thus, you might have a document in which the default character is the hyphen but for one particular word you want to use the equals sign (as is done in some German scores when the hyphen represents an actual hyphen in the text and not just a syllable break). For that one, the tag would be something like <ns rule=hyphen char="=">. If for some reason you want one particular hyphen in a piece to be smaller than the text that comes before it, you can have something like <ns rule=hyphen size="8">. A major benefit would be the extensibility for creating a new rule entirely. A while back on this List someone inquired about using the sort of hyphenation style whereby any time the first note of a system has a syllable which doesn't start a word, that syllable should have one hyphen immediately to its left. That style is not very common anymore, but it's perfectly respectable tradition and Finale ought to be able to handle it. Currently it's impossible without severe kludging. Another rule for syllable separation I'd like to see is one to draw a curve from the end of the previous syllable to the beginning of the following, subject to certain parameters of curvature, stroke thickness, offset points on both sides, etc. This sort of thing is sometimes used in pedagogic vocal music, and I myself would like to have it available for use to indicate liaisons for certain French vocal scores. Perhaps MM doesn't want to trouble to actually write the code to implement either of these rules, but it could at least make the lyric system extensible so that someone else could create one as a sort of plug-in. >I'm not sure how Finale deals with returns, [...] As far as I can tell, a return in the lyrics text behaves exactly like a space, except that it appears differently in the Edit Lyrics box. There could be a display parameter for that. <ns rule=space disp=nl> would start a new line in the Edit Lyrics text but would otherwise behave the same as a space. Default is disp=space, and the disp parameter is completely ignored for everything except how to show it in the Edit Lyrics box in normal mode. You might also have a disp=tab, a capacity for multiple newlines, or for that matter you could even have parameters for horizontal and vertical displacement if anyone cares to be so fancy. >[...] but we already have hard hyphens >(cf. above) and hard spaces (Alt-0160) on the windows side. As we've discussed, the hard hyphen does not work for Mac. As for the space, in most fonts, Mac's opt-space matches the regular space in appearance, but in a few fonts (eg, Geneva) it is noticeably wider. A hard return could be useful for those occasions when you want a whole sentence to appear under a single note, as sometimes is called for in church music (and in some G&S songs). The return lets you put the overgrown "syllable" into multiple decks without needing to enter some of it into a separate verse. It would also be useful for pop songs where you want to indicate "he/she" and so forth with one on top of the other. >I'd like these, though, too. A simple way to achieve non-hyphen characters >acting like a hyphen would be to use indirection, just as Finale does with >clefs; allow the user to specify which character should be used as a separator >between syllables, and in the process, adjust the baseline and the distance >between iterations of repetitions of that symbol in the process. The interface >would be something like what is used in the clef tool. Agreed. Allowing the user to set defaults is a huge improvement, but it still locks you into one scheme for the entire document. I'd like it even better if there's a way to override the defaults on a case-by-case basis. Obviously you don't want to have to type in tags all the time, and you don't want to drastically change any input methods. That's fine. My suggestion is that what appears in the Edit Lyrics box is a special-looking hyphen or space for when the hyphen or space is a code. Maybe it's enclosed in brackets and the whole thing is bold and in blue. As far as typing it, it's no different. If you're in Edit Lyrics mode, and you type the hyphen key, your screen shows the fancy looking hyphen, and you say to yourself "Aha, I just typed something special." Your screen will show something like "Hap{-}py{ }birth{-}day{ }to{ }you", with appropriate color-coding, and you have a strong visual cue for syllable separation. Typing a hyphen or space still gives you the usual coded character. If you want a plain one, there can be an escape character, say the backslash. Typing backslash alone shows nothing on the screen. Typing backslash followed by hyphen with draw a regular hyphen. So you might type "qu'en-di-ra-t\-on", it will show up on the Edit Lyrics screen as "qu'en{-}di{-}ra{-}t-on", and the "t-on" will end up together under a single note. Likewise with backslash-space. (And if you need a real backslash, type backslash twice.) All those tags and parameters I was discussing before aren't visible under normal Edit Lyrics mode, since 99% of the time you won't want to look at them anyway. For that 1% of the time, your Edit Lyrics window can have a "show source code" option. As has been remarked on this List numerous times, the Edit Lyrics window is a UI dinosaur. It ought to be resizable, it desperately needs its own zoom function, and you ought to be able to leave it open and visible even when you're not using it. (I'm on 2k2 until FinMac 2k4 comes out, so perhaps it has been improved?) In addition, I propose that it has different display/entry modes. When in normal mode (the default) the display and keystrokes behave as I've described here, pretty much the same as it's always been. If you switch to "raw code" mode, then you see all the text and codes in a uniform font; in this mode, typing characters edits the code directly. That way, there's a way to deal with special situations like the ones I described earlier without the need for an immediately understandable UI for every little thing. A user wouldn't be expected to go into this mode any more often than one uses Edit Frames currently, and a casual user would never go there at all, but those times when you need it it's there. A third different mode for the Edit Lyrics window, I suppose, would be Click Assignment. The current Click Assignment window is, if anything, even more clunky than the Edit Lyrics window. I see no good reason why they can't be the same window so that one doesn't have to be switching back and forth. When the window is in Click Assignment mode, you can't type into it at all. (Or better, typing a key automatically switches it to normal mode.) The current syllable (ie, the one due to be assigned next) is highlighted in some way, and if you want to move to another syllable elsewhere in the text, you can just click where you want to go instead of laboriously scrolling through a one-dimensional window as is necessary in 2k2. For those of us who like to use option Click Assignment to assign syllables faster, tags could be added to make this more efficient. I have a vague recollection -- maybe I'm thinking of a different application? -- that at one time you could type multiple hyphens in the Edit Lyrics window for a melisma, and it would know to advance extra notes when doing the click assignment. If that still works (or if it ever did), I've forgotten how to do it, because it isn't working for me now. Suppose there's a tag <adv> with parameter "num". The routine that draws the lyrics on the page ignores this tag entirely, but the routine that does option click assignment reads <adv num=x> as an instruction to advance x notes before assigning the next syllable. In Edit Lyrics in normal mode, this code would be displayed with a funny little arrow and the number, like {->2}. (But it would be better if the "->" were a single character designed just for this.) To enter that, in normal mode, some key is assigned to the tag, perhaps the plus sign. (For a real plus, use the escape key then plus.) Thus when you type "+", Edit Lyrics checks to see if you're immediately following an <adv> tag. If not, it writes <adv num=1> and displays it as {->1}. If so, it increments the num parameter and updates the display accordingly. Now, if you're entering lyrics in Edit Lyrics to later assign with option click assignment, you could type "The+ first+ No+-el, the+ an-gels did say...". Then you could assign them with option click assignment and they'll all fall into place without resort to the Shift Lyrics function. And if you have an aria with long melismata, entering them in Edit Lyrics is as simple as tapping out the rhythm of the tune on the plus key. ("Shall be ex-al++ ++++++ ++++++ ++++++ ++++++ ++++++ +++++++++++++-ted") I don't know about anyone else, but I would find that a great time saver. >If my guesses about how the lyrics work are correct, this may be >problematic. [...] It *is* problematic. That's why it needs to be fixed. >[...] My observations about type into score are that the lyrics appear to >be added to >the lyric block as follows: the lyrics for each staff containing lyrics are >added to the lyrics block in the order in which the first lyric is added to its >staff. Suppose one is editing a choral work for Soprano, Alto, and Bass. If >the first lyric one enters is attached to a note on the Bass staff, the second >lyric one enters is the soprano staff, and the third lyric is the Alto staff, >then in Bass lyric will appear in the lyric block first, followed by the >Soprano lyric, and then the Alto lyric; my explorations also suggest that the >finale document file keeps track of the location of the first syllable of each >staff, relative to the beginning of the lyrics block. Within each lyric, my >experience suggests to me that most of the time, the syllables of each line are >usually sequential. I do know that there is some way in which syllables can >become "orphaned", that is, a syllable in the block not attached to any note, >but I've not explored exactly how this happens; I have learned that trying to >get rid of these causes more problem than it is worth! Yes, but suppose someone who normally uses Type in Score finds himself in a situation where he needs to rearrange lyrics en masse and he thinks to go into the Edit Lyrics window to fix them and, assuming it can't be too counter-intuitive, starts changing some syllables. Then he goes back to page view and discovers, to his horror, that he has completely bollixed the whole file and can't figure out how to restore it. Sounds crazy, but this sort of thing has happened to intelligent users, and on at least one occasion has been reported on this List. That's not acceptable. Something should be done that makes it impossible to get into so much trouble so easily, but without removing the powerful functionality that the Edit Lyrics scheme provides, and hopefully without requiring the system to be overhauled too drastically. Some time I'd like to sketch out my thoughts on how that could be neatly done, which I hinted at in the previous message, but I've already written way too much for one morning, so it'll have to wait for another day. mdl _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale