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

Reply via email to