On 7 Jul 2005 at 22:24, Johannes Gebauer wrote: > While we are on about it: House styles is another area where Sibelius > is far superior to Finale. > > Several times I have suggested ways how some house style functionality > could be added to Finale with as I understand very limited programming > effort (as most of it is already in Finale, just not used). > > All it needs from my perspective: > - More fields in the File info, which should all be addable via > placeholders. > - Better handling of default fonts > - a description field for articulations > - a set of plugins which can deal with moving the notation data from > one template to another, utilizing the above (ie distiguishing > standard articulations like staccato etc by their description field), > plus the ability to run certain plugins automatically (like Patterson > beams). > > As far as I can see this would open the way for house styles, in a > more flexible way than Sibelius offers.
I honestly see nothing about any of these suggestions that belongs with what I conceive of as the concept of "house styles." However, the concept *does* relate to my suggestion of cascading templates/libraries, where you could maintain a link between a file and it's parent template (or break the link, if you chose) and also maintain a link back to libraries, instead of having the current proliferation of item definitions that make it a mess to manage libraries. Libraries should be stored *outside* the file -- copying them into the file rather breaks the whole concept of library files. And what I'd really want would be two-way editing of linked libraries. What I mean is, if I edit the library, all Finale documents using that library would have their definitions updated automatically (perhaps the next time the file is loaded; perhaps conditionally, with a warning "The Articulations library on which this file is based has been updated. Would you like to import those updates? YES | NO | SHOW ME THE UPDATES SO I CAN CHOOSE WHICH ONES TO IMPORT"). Likewise, a change in a document that is to an item that is stored in a library should have the option of pushing the change you make up into the parent library. This kind of thing would make my life much easier by allowing me to keep all my files consistent without having to replicate edits in multiple files (in combination with running Robert's Settings Scrapbook plugin, which can't copy everything). But, none of this would really work well until expressions/articulations/etc. (the items that are library-based) were altered to be sub-classed, where you could create instantiations of a parent object with different characteristics. A perfect example of this is bowing marks. Rather than having a set of four, one for notes without articulations and one for notes with them, you'd have one parent definition, then a second definition that is a child of the original bow mark, but has different vertical spacing parameters. If you then altered, say, the font size of the original, the child mark would automatically inherit that. This would not preclude the actual copying to a new articulation definition, as is the case now -- it would simply allow one to have multiple related items that shared the common properties. For me, this would be most useful for the stroke articulation. I presently have to maintain a set of 6 of these, since the stroke is used as both a stacatto and as an accent. I want the appearance to be identical, but I want the performance effect to be different (one shortens duration, the other increases velocity). I also need a version of each that shows onscreen but doesn't print, and a version that prints but does not have a playback effect. Then I also need editorial versions of all of these (with brackets). If there were sub-classing of these, I could organize them either around appearance or around performance effect, then base the child definitions on the basic definition, but with different properties. Depending on what you could override, I could have a single definition as the parent for all, and then make the adjustments all based on the original. It makes more sense to me to have two performance-based definitions and then have those have multiple manifestations. Sounds complicated, but I don't think it must be in the implementation -- it's really not much different than simply replacing the existing copy button with "copy to new definition" for one button (that work the same as it does now) and a new button that says "copy to linked definition" (obviously there'd need to be work on terminology to make it more transparent and less geeky!). Or, you could have the existing copy functionality work the same as it does now, and have a checkbox that controls whether the new item is linked to its parent or not (and a program option that allows you to set the default behavior for this; probably most people would want it to be unlinked, so that it would work exactly the same as the current functionality). The complexity would be in two areas: 1. figuring out how to store the data, AND 2. figuring out how to represent this different kind of object onscreen. I'm sure both could be handled, as 1) requires only giving the articulation/expression definition a property indicating whether or not it has a parent (e.g., a ParentID field; if it's empty, it's a standard articulation; if it's filled out with a ParentID, it's linked to the articulation represented by the exact articulation ID), and then if it has a parent, it would only need to store the properties that differ from the parent (all others could be blank). I guess my point is that the kind of restructuring I'm calling for here would go much further to making it possible to manage "house styles" than any of the things you mentioned. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
