On Sunday, July 14, 2002, at 09:26 PM, Mark D. Lew wrote:
> So your scheme for type-in-score is for note expression only?
Nope.
> Or is there some other way to specify them as measure expressions?
For clicking, I mentioned the "weeny" note indicator in the cursor.
> I gather that "ED" is the abbreviation for that unit of time
> where 4096 of them equals a whole note, yes?
ED = EDUs.
EV = EVPUs.
> If I have either time or space units available for the argument
> of the H item, and I can enter more than one H on a single
> expression and have them add together, then yes, I believe that
> covers everything I want. No, I take that back. I'd sort of
> like to be able specify it as the *beat* for whatever time
> signature I'm in. That is, I could define a single expression
> to always default its horiz position to the nearest beat, and
> then have the program know how to apply that correctly whether
> the time signature is 2/4 or 6/8.
I think that would be possible because the initial click
location would be known. If there was a baseline followed (as in
true Type-Into-Score) and the cursor advanced, then it seems to
me the only logical advancement would be the per entry type
already used in the Lyric and Chord Tools. Hence the entry would
be known. Knowing the entry implies being able to calculate it's
position with respect to the start of the measure.
> Maybe your new pencil-cursor can hop around from measure to measure?
That was the intent.
>>> One last thought: Is it at all practical to also apply some
>>> of these ideas to the articulations?
>> Hard to say, but I'd think at best, a baseline, insertion
>> point which moved to the next entry, and then typing a
>> previously assigned metatool might be the max available
>> without putting the Articulation structure though open heart
>> surgery.
> That's all I really want.
I could be mean and hold someone to a statement like that. =8-)
> The one drawback I see to this is that it seems to be
> incompatible with Philip's original suggestion that the
> type-in-score goes to the first text within the
> angle-brackets. In retrospect, I'm not sure this is such a
> great idea anyway, since it would mean most
> auto-placement-enabled expressions are going to start with "H("
> or "V(".
That's not what I designed. The total text of the expression
would consist of the printable part of the expression and the
non-printing angle bracket part of the expression--just as now.
Inside the angle brackets would first be the nickname and then
the optional positioning and other cues to represent the dialog
box items. Since angle brackets denote a clear separation
between the "real" portion and the "cue" portion of expression
text, and the various cues would have specific delimiters, the
location of the cues is not a consideration for parsing. Only
that they exist.
*
Sorry I can't address the other speculations at the moment. I'm
clearly out-gunned for verbosity and in all honesty would have
enough to think about presenting TIS for expressions as a
succinct and viable feature request.
Best wishes,
Philip
_______________________________________________
Finale mailing list
[EMAIL PROTECTED]
http://mail.shsu.edu/mailman/listinfo/finale
