[If I've remember the address right, this is cc to Coda tech support. Those who use "reply to all" might want to remove them from any replies.]
At 11:18 PM 07/09/02, Johannes Gebauer wrote: >BTW, I would guess that now is a good time to send in feature requests to >Coda, perhaps the feature set for 2k4 hasn't been decided yet. All right, maybe now is a good time for a thorough discussion of the whole system of expression metatools. I've see a wide variety of complaints and requests about expressions in this discussion, and it seems to me that *everyone's* needs could be met if the entire system of expression metatools were expanded in a way that would make them simultaneously more powerful and more flexible. I think this can be done without any major reworking of how the program treats and stores expressions, and in a way that preserves "the old way" as a default subset of the new way. The main thing, and probably the most difficult to implement, is that expression metatools need to be changed so that each metatool represents not an expression but an expression *assignment*. That is, all of the attributes specified in the expression assignment dialog are saved as attributes of the metatool. David W. Fenton asked: > (do expressions offer default positioning control in recent > versions of Finale?). The answer is no, and the reason it doesn't is because position is an attribute of the expression assignment, not the expression. This is a serious limitation. The great advantage of the metatools is it saves the tedious process of going through the expression assignment dialog. If I want my expression to appear on every staff and I'm satisfied with eyeballing the position with a mouse click, then it works fine. But if I want to use a staff list, or if I want better control over the positioning, I've got to go into the expression assignment to fix that, in which case I may as well have not bothered with the metatool in the first place. It's quite frequent that I'll want to use metatools to enter a bunch of common dynamic markings, but I'll want them on one staff only. Unfortunately for me (and for Jef, who was asking here about the same thing) metatools for measure-attached expressions always show on all staves. When I ask tech support about this, their answer is that if I want it on just one staff, I can use a note-attached expression instead. Well, that's true, but note-attached and measure-attached are two different things, and there are plenty of reasons why I might want my expression to be measure-attached. Also, I might want to have the expression show on the staves of a certain staff list, in which case note-attached is no help at all. Another thing that's quite frequent is that I know exactly where I want an expression to be positioned relative to the measure. If I'm detail-oriented, I'll want that positioning to be exact, which I can't get with just a click-and-drag. A lot of basic dynamics I prefer to always be horizontally right on beat 1 and vertically at 168 EVPU below the staff. Some other dynamics, because of their typographic appearance, look better if the horizontal position is something like -12 or -24 EVPU. For such expressions, metatools are useless, because I have to enter the expression assignment dialog in order to correct the H and V values anyway. There are, of course, some plug-ins which help with expression alignment, but they are only a partial solution. What is really needed is the ability to specify the positioning in the metatool definition. Thus, every metatool should include in its definition not just an expression, but the five attributes of the expression assignment as well (ie, show on, H position, V position, begin playback on, and allow individual positioning). Each of these can either be set to a value or left blank to go to the default. For those users who don't want to use such definitions, everything will default to the same way it's done currently, and they'll never need to know the difference. For H and V position, the choices should be: (a) default to the H or V component of the mouse click, (b) an absolute value which I define just as I would in the expression assignment dialog, or (c) a value relative to the nearest beat. The last one is important if, for example, I know that I almost always want an "mf" expression to appear -24 EVPU left of the beat and -168 EVPU below the staff. Then, if I have an "mf" on the first note of one measure, I can click somewhere near that first note, and Finale will do the math to place it where I want it. If I then have another "mf" on the third note of a measure, instead of needing to know if that means H=2.679 or whatever, I can just click somewhere near the third beat, and Finale will do the math to place it correctly. Obviously, when setting up my metatools I can't always predict exactly what position I'm going to want any given expression to appear at, but in many cases I can define something that will be right more often than not. And even if I have to nudge something down, I'd rather have a fixed V position to begin with and know that I can nudge six times with the down arrow and have the expression sitting exactly one staff space lower. For some expressions, I won't want this feature at all, in which case I'll just leave these values to default to the position of the mouse click. Some users who are happy with doing all their positioning by eye will probably do this for all of their metatools; that's fine too. With regard to the "show on" value, the metatool definition should allow for any of the choices in the expression assignment dialog (ie, all staves, this staff only, or any defined staff list) or to fall back on whatever the default is. That default should itself be changeable as a program option, with a menu somewhere that lets you change the default to "this staff only" or a staff list. This will be useful for users who don't care to write "show on" definitions into the actual metatool definitions but nevertheless find that they frequently want to use metatools for measure-attached expressions that don't appear on every staff. This setting would start as "all staves", so that default behavior remains exactly what users are used to from the current system, but I imagine that "this staff only" would be used much more frequently. -- As for the type-in-score question. The obvious problem with what was originally suggested is that Finale stores anything that's typed onto the page as an expression. On the whole, this is a very good thing, and I don't think it ought to be changed even if such a change were practical (which it surely isn't). So if a Sibelius-minded user comes along and types "pizz." over and over every time he wants one, he's going to end up with a dozen different definitions of "pizz." in his expression list. If you've got memory to burn and you don't really care about making use of the power inherent in Finale's expressions, I guess there's no harm in that. But some day that user is going to want to do something to all his "pizz"s, like alter the playback definition or change them to a larger point size, and then he's going to get angry when he has to change them all one at a time. So type-in-score per se is not a good idea, but we should still look for a way to allow essentially the same behavior to be interpreted in a way that makes sense with Finale's system of expressions. This does not need to be separate from metatools, but rather it can be an extension of metatools which simultaneously satisfies those of us who want even more metatools and wish there were more keys available. In my vision, every metatool has not just an assigned letter, but a name. The name is one more attribute of the metatool, it is a text string of any length (well, some reasonable limit, say 32 characters), and it must be unique. As Finale currently works, when the expression tool is selected, a single click can select an existing expression, a double-click will bring up the expression assignment dialog to create a new expression, and a click with a defined key held down will create an expression using a metatool. A new type of click needs to be defined -- let's say it's shift-click (though it could be something else). When you shift click, it brings up a small pop-up window which is a list of all your expression metatools, alphabetized by name. Once this window is up, typing a letter moves you to the first name in the list starting with that letter, typing a second letter moves you to the name starting with those two letters, etc This sort of list window is common in all sorts of computer applications, and anyone who isn't completely inexperienced has seen them before and knows how to use them. Some schemes are more flexible than others (personally, I prefer when you can also use the arrow to go up and down in the list). In any case, I assume this is a standard component which the programmers can tap into from the OS or whatever, and it'll work like those sort of windows always work. The point is that to get to any metatool, you can go shift-click and then type in the beginning of the name until it's on the one you want, then you hit return to select that metatool. Different users will want to name their metatools differently, according to their needs. Some will like having the name be identical to the text. Some will like short memorized abbreviations for quicker typing; others may prefer verbose descriptive names. Myself, I'd probably do both at once, using names like "4 = mf" or "p2 = Ped. (no playback)". As a convenience to those of us who will make huge lists of metatools, it might be useful to have a mechanism whereby the complete list of metatools can be edited directly. In addition to the usual definitions, there might also be the option to make the metatool "inactive" so that it doesn't show on the pop-up list. That way we could have a giant library, but only activate the ones we're likely to be using in a particular file. As for the original type of metatools, they still exist. When you click with a letter or number key held down, the computer will select the first metatool on the name list that begins with that letter or number. So long as your old metatool have a name which alphabetically precedes anything else starting with the same letter (and this is assured if the name is just the single letter), they will behave exactly as before. -- Johannes again: >I see >no reason why Finale can't support "Type into score" for expressions, it >would be a really usefull feature, especially with music that has a lot of >different expressions on a page, like in some modern music, where assigning >a metatool to each new expression is not really practical as most of them >never get called a second time. I agree with this. As discussed above, I think users should NOT be encouraged to invent a new expression each time they type a standard dynamic marking. Nevertheless, if you're transcribing some verbose composer like Satie who fills up his scores with dozens of little descriptive phrases that you're not likely to see again, then it's nice to have an easy way to make a one-shot expression without going through all the dialogs to set it up. My suggestion for this would be to define a certain type of metatool which could be thought of as a "fill-in-the-blank" metatool. Like every other metatool, it has a name, it has the attributes found in the expression assignment dialog, and it has an expression that it points to. But the expression it points to is only used as a model, and is not place in the score. When the fill-in-the-blank metatool is called, it instead creates a new expression which it puts in the score. The new expression has all the same attributes as the one it is modeled on (ie, all the choices that appear in the Text Expression Designer) except for the text itself. When this "fill-in-the-blank" metatool is activated, it brings up a little window that asks you to type in some text. You type it in and say OK. Then Finale creates a new expression with that text and then places it into the score according to the metatool definition. A slightly different approach to the same idea might be to NOT have fill-in-the-blank be a special type of expression metatool, but instead a different way of calling a regular metatool. Perhaps if you hold down control while selecting a metatool (either my new shift-click way or the old way), then instead of calling that metatool directly it, it does the fill-in-the-blank trick, modeling after whichever metatool you've selected. I can see that being useful for tempo markings. Maybe you've got your Adagio, Largo, Andante, Moderato, Allegro, Presto, etc., all set up with the proper playback definitions, and then you come across something like "Immer noch mehr zurückhaltend". So you figure, "OK, that's probably about the same as Largo", so you hold down control and metatool the Largo, then you type in the "Immer noch mehr zurückhaltend" and you automatically get it with the same typeface, positioning, and playback as you would for Largo. The business of modeling may seem a little indirect to some readers, but it keeps the definitions of the various objects consistent. That is, a typeface is not an attribute of an expression metatool, but an expression is -- thus you have an expression to model on instead of having the expression's attributes directly, even though you might want to think of the typeface as "belonging" to the fill-in-the-blank metatool. But in any case, the user doesn't need to worry about any of this. He just needs to know that he can define a fill-in-the-blank metatool called something like "x = generic instruction" which will make a 12-pt Times italic expression out of any text he enters in the box. The newly created expression will appear on the Expression Selection list (but not on the metatool list), so it can now be edited just like any other expression -- but since the whole point of the fill-in-the-blank metatool is to save typing, I don't imagine there'll be much reason to do so. Philip Aker wrote: > [...] why > not be able to type in Expressions if that tool is selected and > there's a checkmark on a "Type Into Score" menu item? Cursor > changes to a pencil, click for the location, type, and press > <Enter> when done. If it really makes a difference to some users to see a little pencil and watch the word being typed into the score, I suppose that could be implemented as a specialized sort of dialog box, which could behave exactly as Philip describes. Personally, I think having a normal dialog box is more logical, and in terms of keystrokes it's identical, but I know some people care a lot about little things like that. By the way, I am aware that "metatool" is perhaps not the best label to use for the object I'm discussing here, which is more fundamentally a named expression assignment object. The basic concept is built from the existing expression metatool, and it maintains the expression metatool's existing behavior as a subset, but at the same time, if users are accustomed to thinking of "metatool" as a single keystroke and not a list of names, that might be confusing. On the other hand, I do think that the whole scheme of names and the pop-up list for choosing one should be applied to all the other forms of metatools. For most of them, it doesn't make nearly as much difference as it does for expression assignments, but it still expands the power of the metatools. (Among other things, it makes the number of keys available infinite, in that you can have a two-letter metatool, a three-letter metatool, etc.) For note-attached expressions, there is a slightly different package of assignment attributes than those for the measure-attached expressions. For articulations, there is no assignment at all, since for articulations all of that is built into the designer instead. -- As for Richard Walker's idea that you ought to be able to have just one "pizz." to put into any part and have Finale know enough to make it play back "correctly" whether it's violin, viola or cello, that's an interesting problem. I'm not convinced that this is really the best thing -- like many others on this list, I don't care to have Finale second-guess my intentions too much, and I think that having separate "pizz.<violin>", "pizz.<viola>", and "pizz.<cello>", each defined with its own playback values, is quite satisfactory. But for the sake of argument, let's assume we want to do this. What we need now is a sort of meta-metatool, but since that's an ugly name, let's call is a "conditional" metatool. The conditional metatool has a name and is called by keystroke or from the name list just like any other metatool. But the conditional metatool has no expression or assignment attributes of its own. Instead, it has some sort of if-then algorithm which will result in choosing some other metatool, which will then be implemented as normal. (It would probably be much easier to have the conditional metatool have its own assignment attributes and have the if-then select only the expression itself. That would also be good, but I think it's a lot more powerful if it calls up another metatool.) The way I see it, the choosing mechanism names a particular attribute to be looked at, has a list of possible values to check that attribute against, and for each of those values names a metatool to call up if it matches. In our pizz example, you could have a conditional metatool named "pizz". The attribute it would check against could be the staff name of the staff which has been selected. The value list could say: If "viola" then use pizz.<viola>, it "cello" then use pizz.<cello>, etc. You can see the drawbacks of such a scheme. For one thing, you're running a risk of mismatches if someone misspells or mislabels something. It's very easy to imagine someone creating a cello staff but neglecting to actually name the staff "cello". You could let the checked attribute instead be the playback instrument assigned to the staff. That would probably work better, but there's still lots of ways that the conditional metatool could go wrong. There will of course be a default result for the case that none of the values on the list match, and if that is intelligently set, you've at least got a decent fallback value. The challenge for the designers here would be to put together a plausible list of all the attributes a user might want to use as the test attribute in the conditional. The possibilities are nearly endless, and no matter what is included, someone might find something missing and complain "how come I can't make my conditional based on such-and-such?" In reality, you might want your conditional to be based on more than one attribute. That is why I want the conditional metatool to choose another metatool to call, not to choose an expression -- so that one conditional metatool can call another. That way you can chain a bunch of them together and make as fancy a tree of conditions as you like. (Of course that brings up one pitfall to be avoided: the program will need to have a safeguard that makes it pop out if the conditional metatool calls itself, so that it doesn't get trapped in an infinite loop.) A major issue is that you have to have a certain amount of sophistication to set up your conditionals intelligently in the first place. In the current example, it means knowing what sort of playback definition accurately reflects the sound of each instrument's pizzicato, as well as knowing what to look for in the score that will tell you which one you really want. (For instance, is it really just the instrument, or does it matter what pitch is played, what string, what dynamic, etc.?) Anyone with that kind of knowledge is probably happier just assigning the different expressions directly and not trying to program the computer to figure it out for him each time. The real purpose of having a conditional metatool like this would be so that Coda, or any experienced Finale user who care to create a library to give away to others, can set up all these definitions and deliver them to a Sibelius-minded user who wants everything to work "automatically". But then that creates the problem of designing them in such a way that they'll give the desired results most of the time and still be "idiot-proof" for the user who isn't really aware of what's going on. If it were just the question of the pizzicato, I would say all of this is far more trouble than it's worth, but in the larger picture this is an extremely powerful concept, which could be extremely useful if implemented well. An immediate use I can see for it is in articulations. Like a lot of users, I have two different versions of almost all of my articulations, and four versions of some of them. This is necessary, to get the positioning exactly right, but it's also a pain. For the ones I use less frequently, I have to consult my notes to remember, eg, which accent I use for below the note on a downstem. (Just being able to give a complete name to the articulation would help considerably, since the "don't show text in angle brackets" isn't available for articulations.) But my rules for using my articulations are very algorithmic, and those algorithms could be built into the definition of a conditional metatool. I could have just one metatool named "staccato". That metatool could then have some sort of rule to figure out if I want a stemside dot or a noteside dot and call the correct metatool accordingly. (Of course, those regular metatools would also be available to me on my list, so that I could select them directly and make the choice myself. But having the conditional one available might be very handy for applying the articulation to an entire passage at once.) For other articulations, I might make a tree of conditionals based on whether it's an upstem or downstem note, in the staff or outside, what type of notehead, etc. There's a lot of little things that I would have built into my articulation definitions if it weren't such a hassle. For example, an accent on a whole note looks better if it's pushed a little to the right. For me it's not worth the hassle of creating a separate articulation just for this, so I just remember to nudge it when I put one on a whole note. A similar example is for fermatas, which, when defined to be centered over a notehead, end up way off-center when placed on a rest. Again, it's not worth the trouble to create three separate articulations for note, whole or half rest, and other rest, so I just remember to nudge them. But conditional metatools could open up the possibility of creating a single fermata metatool that positions itself tolerably well for all cases. -- I could go on, but I think I've already surpassed Peter in the long-windedness department. To summarize, I see the idea of making the expression metatool define an expression assignment rather than just an expression as completely separable from the idea of giving all metatools a multi-character name from which they can be accessed. Either one could be done without the other; the first is very much a functional idea, and the second is primarily about user interface. The modified type-in-score concept (ie, "fill in the blank" metatools) and the "conditional" metatools are each an additional feature which could be added on to the user interface idea, but are not essential to it. For me personally, the whole matter of type-in-score and access to metatools by name doesn't make a whole lot of difference. I'm an experienced Finale user, completely facile with the metatools they are, so I don't think it would make a huge difference to me in terms of time saved. I do, however, think it's a good way to make a small improvement in user interface for experienced Finale users and a very large improvement for new users who find Finale's current scheme of expression dialog boxes intimidating, while still maintaining the same basic structure underneath. The idea of changing expression metatools so that they are defined as an expression assignment rather than just an expression is very important to me -- the single most important change for me in terms of increasing my productivity. I spend more time on placing expressions than on anything else. If I could set up my metatools to avoid the expression assignment dialog box for nearly all of my expressions, that could cut down the time I spend on that by nearly half. If expanding the definition of an expression metatool proves to be too complicated, then I would at least like the ability to specify default expression assignment values. This would be analogous to the Default Tuplet Visual Definition. Just as that calls up a version of the Tuplet Definition box, I want to be able to call up a Default Measure Expression Assignment box, where I can set each attribute either to a value or to "no change". Those values will be used for every subsequent expression assignment created by a metatool. Then when I'm ready for something different I can go back to the Default Measure Expression Assignment and change it to something else. That's still not as good as being able to make the assignment attributes part of the metatool definition, but it's at least a step in the right direction, and no doubt easier to implement. It would be better still if I also had the option of entering (in any Measure Expression Assignment, not just the default) a value of "x+y" for the horizontal position, where x is a beat number and y is a distance (positive or negative) in EVPUs or other units. Then if the Default Measure Expression Assignment let me define x variably to be the nearest beat to where I click, that would be great. But even without this a Default Measure Expression Assignment would still be very useful. mdl _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
