On 6 Jun 2004 at 8:13, dhbailey wrote: > David W. Fenton wrote: > > > On 4 Jun 2004 at 22:17, Mark D Lew wrote: > > > > > >>On Jun 4, 2004, at 9:29 PM, Eric Dannewitz wrote: > >> > >> > >>>Lyric tool works well. > >> > >>Really? Lyric tool works well if you know what you're doing, or if > >>you never do anything complicated, but it has lots of pit-traps that > >>the unwray can fall into. And there are failings, too, such as > >>control over hyphen behavior. > > > > > > Well, as much as I complained about lyrics in my first big project > > with them (in August 2002), now that I learned from all the gurus > > here on the list, I find it pretty darned easy to use. The main > > point: > > > > DON'T USE TYPE INTO SCORE > > > > Once you figure that out, it's pretty easy to use. > > > > But, of course, I thought we were discussing examples of > > subcomponents of Finale that were majorly overhauled and then never > > worked right any more. When has the Lyrics subsystem been overhauled > > and exactly what ended up badly broken? > > > > It hasn't been overhauled, but the point in bringing it up was that it > was implemented so poorly that a very major and to many people a very > useful aspect can't be used -- Type Into Score was not properly > implemented, is extremely quirky to use and very frustrating until you > learn DON'T USE IT. > > We're just afraid that the parts/score linking might well be > implemented in a similarly stupid way that would never be fixed once > it was implemented. Who wants valuable development time spent on a > feature that we then have to tell newbies not to use, as we have to do > with Type Into Score?
Seems to me that Lyrics got the way it is because it is an *old* subsystem, dating back to very early versions of Finale, and the changes to it have been bolted on the sides over time, making it rather baroque and nearly impossible to figure out. And the problem is that the basic system on which it is all built does not have the best architecture to support all these additional features. It is exactly the kind of component that appears to me to need a major rewrite, from the ground up, so that the basic architecture could be altered so that all the parts that have been bolted on could be integrated into the basic structure, instead of having this kludgy afterthought feel to them. Indeed, a lot of very small changes could make Lyrics much more usable (like allowing resizing of the click assignment dialog -- geez, how frigging hard would *that* be?), but the basic underlying problem of the Lyrics tool, that the visual representation of the data and the actual underlying data do not have a clear relationship to each other (and, secondarily, that the UIs involved require you to understand the relationship between the displayed data and the stored data), could, I think, only be rectified by a ground-up rewrite of the whole thing. > Who wants a score/parts linking that would force people to leave it > turned off because every time we change something in the score the > layout for parts changes even if we are just experimenting? As long > as it was user-selectable or a ctrl-l sort of thing such as screen > redraw or saving feature or update-layout thing that would only be > done when we tell the program to do so. Yes, you're certainly right that Coda could screw it up, but they could also screw up any bug fix they implemented, as well. So I just don't see the point of bringing it up when evaluating new features. It's only relevant when the new feature has neglible benefit in comparison to the amount of effort required. I don't really think that's the case for linked parts. > We're not saying that it would definitely be implemented in the most > stupid way possible, merely pointing out that MakeMusic has shown > itself capable of doing so and we want to be sure it will be > implemented in a useful way. There are many aspects of Finale where there are two ways to do things (e.g., Speedy vs. Simple). Many of us wouldn't touch one of those two ways (I'd never bother with Simple Entry). What I'm suggesting is adding another part extraction method (or altering SPE to store information about individual part layouts), while leaving the original method unchanged. Some people would migrate to the new method, some people would stay with the old, just as some people still use Simple Entry. I don't see the issue. And I think it would be the kind of change that would serve to keep Finale competitive with Sibelius. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
