On Wed, Jul 30, 2008 at 8:42 AM, dhbailey <[EMAIL PROTECTED]> wrote: > I think > there may be a programming issue where underlying changes in the way the > program works might have made internal tracking or control of more than 4 > staff lists difficult. >
I do not know any more about how this function evolved than anyone else on this list. I could speculate that they may have originally planned to have only hard-wired staff lists (i.e., completely uneditable), then thought better of it. What makes me say this is that you can find 4 names that look like they may be staff list names in the datafile that are currently not used. They are generic names that match up with the category names fairly closely. Furthermore, nothing about the data structures that I can see as a plugin developer precludes the possibility of lifting the artificial limit. If they lifted the limit, there is definitely more programming work they would have to do, mainly to do with libraries. I do not believe the staff lists get copied with an expression library: only the 1, 2, 3, 4 assignments are copied. If they opened up staff lists, they would have to be included in expression libraries. That said, I have not heard one iota of a word from MM that the limit has anything to do with programming priorities or time constraints. I'd feel better about it if I had. On the contrary, MM so far has steadfastly justified it as a designed and planned "enahancement" to the program. That is why it is incumbent upon us users to disabuse them of their folly. You know, the limit of 4 is not the only problem. I would like to have the option of *fewer* staff lists than 4. Many of my pieces require only 1, and the rest are just clutter. Why force us to have any certain number of them? _______________________________________________ Finale mailing list Finale@shsu.edu http://lists.shsu.edu/mailman/listinfo/finale
