At 4:47 PM 07/12/02, Johannes Gebauer wrote:
>Having read a lot of posts on this now, I feel a lot of people just confuse
>UI questions with technical stuff. I don't see why much of Finale's storing
>and handling of expressions and metatools has to be changed at all, instead
>I would suggest that a lot of improvement could be implemented by simply
>adding an additional way of _entering_ expressions.
OK, perhaps I focused too much on how the data is dealt with internally.
Mostly that's because I instinctively think that way, but there are other
reasons for it.
For one thing, it anticipates objections from others who are inclined to
say, "No, that's impractical because then Coda would have to rewrite the
whole data structure, blah blah blah." I realize that their work/time is a
finite quantity and some things are harder to implement than others, so I
try to look for ways to achieve what we want without requiring major
overhauls.
I agree with you that the way expressions are stored and handled shouldn't
change much, but it does matter how a type-in-score situation is treated.
If it is treated by creating a new expression every time, that's a problem,
because some day the user is going to want to edit one of his expressions,
and it will make a difference to him if the edit changes all of them or
just the one.
I see now that some readers took it for granted that any type-in-score
function would essentially work like selecting from a predefined list (ie,
more or less what I was suggesting). Evidently, Sibelius's scheme works
that way, and you guys figured it was obvious that Finale would too, making
a large chunk of my discussion irrelevant.
OK. It wasn't obvious to me. Someone compared expression type-in-score to
the similar function in lyrics, which works by adding a new item every time
you type something, and others used phrases like "make a new expression"
which I interpreted literally. I thought people were suggesting that
type-in-score should always create a new item on the expression list, which
strikes me as a bad idea.
Anyway, it sounds like we all pretty much agree on the general idea of
selecting from a list.
>I suggest adding another input method for expressions that is separate from
>metatool as we know them. The way I would like it to work is this:
>With the tool selected, click on a note or whereever else you need an
>expression. Start typing, ie "pi" for pizz. Finale looks up it's expression
>library and auto-completes the name I type (just like most browsers do these
>days). When I see the correct expression ("pi" may display piano, so I will
>have to type on for "piz" and Finale complete correctly) I type return. The
>correct expression is entered from the expression list.
>Given the case that I want an expression that is not currently in the list I
>just keep typing until it is complete (and Finale should then not suggest
>any completion - if it does I will have to hit backspace to delete it) and
>hit return. Now perhaps there should be an option where Finale could be set
>to _ask_ whether it should add the expression or always add.
Maybe I'm misunderstanding again, but it sounds like one thing where you
and I differ is that I want every item on the list (whether it's the
expression itself or the expression *assignment*, which I was equating with
metatools) to be keyed off the NAME of the item, not the text of the
expression.
If you want the name to be the same as the text, great -- I'll probably do
that too in many cases -- but I think it's important that the name and the
text be separate. For one thing, it gives us quasi-metatool functionality.
Suppose I'm an efficiency freak. I'll want to be able to name my
expressions so that the most common ones are accessed by one letter, and
the next most by two. I don't want to have to type four letters to get
"ritenuto" instead of "rit.", and I certainly don't want to have to type 11
letters to get "pizz.<viola>" instead of "pizz.<violin>". We've all got our
own key association schemes which we've evolved from our metatools and
macros. The text needed to call up an expression shouldn't be tied to the
text of the expression itself. That's fine as a default, but the user
should be able to assign different names.
Anyway, what happens to expressions that are in a music font? If I've got
an expression which is the pedal marking, it's going to show up on the list
under opt-shift-8?? That's crazy. I want to list it as something like
"Ped." Users who are less technically minded than I am are going to take
it for granted that in a type-in-score situation, they should type "ped" to
get the "Ped." character. For basic dynamics, some people will want to keep
the numerals which the Coda templates have traditionally used. Others will
want to use "mf", "pp", etc.
>In addition I would really like to see autoplacement for expressions. I
>suggest that autoplacement can be done either automatically or perhaps when
>a hotkey is pressed simultaneously - again a program option to allow both
>ways as the user prefers.
Yes, autoplacement of expressions is extremely important to me as well.
That is the gist of my suggestion that expression metatools should
represent an expression assignment, rather than just the expression. I
felt (and still feel) that this is the most logical way to create the
situation that you and I both want, ie, to be able to have the metatool put
the expression in an exact position which we have predefined. If Coda
prefers a different way to achieve the same thing, that's fine by me.
(Incidentally, it occurs to me now that whether the resulting expression is
note-attached or measure-attached could be one more attribute of the
metatool. That seems obvious now, but for some reason I was thinking of the
note expressions and measure expressions as two entirely separate sets.)
>I don't see why this should conflict with the flexibility we already have.
I agree. I was just a little more verbose in spelling out why. (OK, a LOT
more....)
mdl
_______________________________________________
Finale mailing list
[EMAIL PROTECTED]
http://mail.shsu.edu/mailman/listinfo/finale
