On Sunday, July 14, 2002, at 05:55 AM, Mark D. Lew wrote: > This would be great, but I was assuming this was one of those > things where it would require fundamentally changing the > structure of the expression, and thus there would be resistance > to doing it. I assume this means that all of the text > attributes are available, including tracking, baseline shift, > etc.
It would require an alteration in the expression structure but I don't think it would be nearly the effort of something like what was required for staff styles. Specifically, a text expression currently stores the font ID and size in 16 bits, the effects in another 16, and the actual text in a variable sized string at the end of the structure which by default is also 16 bits. The "new" version would store a text block ID in one of those 16 bit slots and the major upgrade work would be in the drawing procs and the conversion of expressions in old documents. While text expressions in multiple fonts with attributes would be groovy, they wouldn't be critical to the implementation (we'd just have to deal with gobbledegook text when music fonts were involved). >> # When a Type Into Score double-click occurs a reasonable >> sized editing frame opens up with the text characteristics set >> to either the System font or the Application font. [...] > I'm not sure what "system font" and "application font" means, System font = Chicago 12, Charcoal 12, etc. (OS 9). Lucida Grande 13 (OS X). Application font = Geneva 10 (OS 9), User choice (OS X) > but I assume this is a default which I can somehow set before I > start using Type-in-Score, and I'm not stuck with the same font > for the entire document, right? I don't know right now. But it seems to me that if one would just be typing nicknames for a match then any old text font will do. If one is typing actual expression names then it wouldn't be too bad to type the occasional music font character since that's what one has to do in the expressions dialog anyway. For entering new expressions then I'll have to put some more thought into this aspect of the design because Finale still hasn't cottoned on to the fact that having a permanent menu for text attributes is a good thing and it would be a bother if one couldn't (at minimum) choose between the default expression font and the default music font for the resulting new expression. >> # The nickname mechanism will be predicated on first matching >> angle-bracket text, then actual characters in the expression, >> and finally if there is no match, a new expression (in the >> default text expression font with no playback characteristics). > This is an excellent idea. With one caveat, this satisfies all > of my needs that led me to advocate giving each > expression/metatool a separate name, so if it's easier for them > to do it this way instead, that's fine by me. > The one caveat is that there does need to be a way to specify > that the angle-bracket text does not appear in the score on the > screen but only in the various dialog boxes dealing with > expressions (including type-in-score). Otherwise, your score > could become littered with codes on the screen, and it will be > hard to see what it's really going to look like. It seems to me > that you might sometimes want some bracketed text that appears > on the screen but doesn't print and other bracketed text that > doesn't appear on the screen or the printout, so perhaps it > makes sense to have a different set of brackets for each. (The > curly braces, I suppose.) You couldn't have known, but I've request for a color attribute for text blocks elsewhere. So I think eventually, one would be able to have at least a capability to have the angle-bracketed text appear in a whiter shade of pale. > (By the way, is there some sort of escape-character mechanism > in case you want to use the angle-brackets functionally but > also want a "<" in the expression? Seems like there ought to > be, but then again it's not really > likely to come up. I've never actually needed it.) The convention would be to use either '\' or '^'. >> - Because multiple-font expressions are now in effect, >> expressions that are in music fonts can have their angle >> bracket comments in a human readable text font. > It might be useful to be able to specify a certain font that > angle bracket text will always default to, so that we don't > have to change it each time we create an expression with angle > bracket codes -- but that's not really > crucial. The system font or the application font. >> # Special indicators in the angle bracket text will indicate >> placement and other options. I'm not describing them all but >> for instance H(number) and V(number) will indicate offsets. >> P(meas) would indicate that the H() and V() coordinates for >> note-attached expressions would be taken from the angle >> bracket text (if present) and be placed relative to the >> measure (over-riding their normal offset from the note). If >> there are no offset cues, then the expression is placed at the >> original pencil click. > Another excellent idea. I gather from your suggestions that > you are implying Coda will prefer not to expand the expression > object by adding new attributes for autoplacement, staff list, > name for type-in-score, etc, but this way you've incorporated > all of that into the expression's text itself. I assume that > these codes can be expanded to include plenty of sophistication > for those of us who care to learn all the codes, right? Thus, > in addition to the H and V position, we'll also have codes for > the staff list and other choices that appear in the Expression > Assignment dialogs, yes? Yes. > A few clarifications, if you don't mind: > - I take it that these codes for autoplacement etc are not > permanently locked in to the expression, right? That is, it > just specifies how the expression will be initially placed when > entered using metatool or type-in-score, but once it's placed, > we can still move it by dragging or going into the Expression > Assignment dialog, right? Yes. > - I noticed that in describing your "P(meas)" code, you don't > say that the code specifies that the expression will actually > *be* a measure-attached expression, but rather that it's still > note-attached but the auto-positioning is measured like a > measure expression. Yes, Note Expressions with an option for measure-based positioning (independent relative horizontal and vertical options). > In other words, it sounds to me like you are further blurring > the distinction between "note expressions" and "measure > expressions", so that they're pretty much the same thing except > that they happen to have different assignment attributes. Am I > reading that right? Not quite. Just the positioning options for note expressions. > - I assume that the H and V codes are such that I can set one > and leave the other blank. For example, if I make an > expression coded with a V but no H, then it will follow my > specified vertical position but use the location of the mouse > click for the horizontal, right? (And vice versa.) Something like that. > - I still would like to request that the code for H position > somehow include the possibility of entering a value that is > interpreted as "round the H position of the mouse click to the > nearest beat". I can very easily imagine that for an > expression like "ritard", I would want to assign a V value > relative to the staff (say, -168 evpu) but set the H position > as "round to the nearest beat, then add -12 evpu".) Am I alone > in this? There are certain expressions which I like to have > aligned to the horizontal position of a note, even though they > aren't note attached. If my only option for H position is an > absolute value, then I need to make one expression for beat > one, another for beat two, etc. Either that or I make it a note > expression, but in that case the V position will vary with the > position of the note, and I can't have a staff list. I think these could be accounted for by a scheme for the measure expression options: V(-168EV), H(1536ED) and say IH(-12EV). the last one meaning "Independent Horizontal Positioning". > (Or perhaps I can? which again raises the question of whether > you're intentionally blurring the distinction between note > expression and measure expression.) Nope. Just the positioning options for note expressions. > If I might now expand even further on your ideas. > The following idea would be irrelevant so long as there is no > autoplacement of expressions nor type-in-score, but so long as > we're seriously discussing having both features (whether by > your scheme or some other), can we take the logical next step > and devise another means of entering the expressions which > requires no click at all? > With what you've described so far, I can select an expression > from the keyboard using type-in-score, and I can have that > expression placed according to a predefined rules and position, > BUT I still have to use the mouse click to get it started, > whether for type-in-score or for a metatool. > That being the case, I want to have some sort of mode, within > the expression tool, whereby Finale highlights the "current > position". I don't need to go into detail about exactly how > this might work. The point is that once you're in this mode, > you can use the arrow keys to move around from measure to > measure, note to note, layer to layer, etc., until you're where > you want to be. Then you start typing and the "type in score" > happens. This part makes me think of a "baseline" indicator (like chords or lyrics but with only 1 arrow) and Speedy-like score navigation keys (or maybe just <Cmd-Arrow>). > 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. Best wishes, p h i l i p @ v c n . b c . c a h t t p : / / w w w . a k e r . c a / _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
