At 6:54 AM 07/13/02, Philip Aker wrote: > [...] I'll expand on the original notion taking into >account some of the nice ideas I've seen go by and offering an >advancement suggestion for text expressions:
And an excellent job you've done of it. You've read between the lines in my long rambling post and zeroed in on my real needs, devising ways to meet them which seem to be more compatible with the program's design. Thanks so much. ># Expressions will be upgraded to handle multiple fonts. 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. ># 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, 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? ># 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.) (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.) > - 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. ># 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? 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? - 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. 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? - 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.) - 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. (Or perhaps I can? which again raises the question of whether you're intentionally blurring the distinction between note expression and measure expression. ) -- 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 would be absolute heaven. I'm imagining dancing around the score with the arrow keys and typing in all of my expressions for the entire document without ever touching the mouse! Surely I'm not the only one excited by this prospect. -- One last thought: Is it at all practical to also apply some of these ideas to the articulations? Obviously, the needs are very different, since an articulation is only a single character, and the auto-placement stuff is already built into the definition. Still, I sort of like the idea of having a type-in-score for articulations as well, especially if it can be done without a mouse click. And having angle-bracket text would solve the problem on not being able to easily distinguish one's multiple articulations with different placement rules. I don't really see quite how this would work, but maybe it's worth some thought. mdl _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
