On 8 Jul 2005 at 3:42, Darcy James Argue wrote: > On 07 Jul 2005, at 7:18 PM, David W. Fenton wrote: > > > No, it wouldn't. > > Yes, I knew you'd object. I'm actually pretty sympathetic to your > view, but I also have good reason to believe a multi-file equivalent > to Dynamic Parts (perhaps implemented by plug-ins -- e.g., "Update > score based on this part" and "Update parts based on this score") is > vastly more likely to be implemented than a single-file solution, at > least in the short term.
I think you're dreaming. The complexities of synchronizing files are an order of magnitude greater than those of relating data structures within a single file. Now, if they separated the data structure from the layout files, then it could work. That is, every Finale file would have two files, one the database, and one the file you worked with to edit and format the data (this is the way it's done in properly-designed Access database applications -- your data tables are in one file, while the forms and reports, etc., that you use to interact with your data are in another file, linked to the data file). Then, to create a part, you'd simply create a new layout file, linked to the same data store. Now, another way of implementing that might be to have the data stay in the score file, and then have the parts be separate files that have no actual frame data in them, and, instead, link back to the data in the score file. This would be not much more complicated than implementing it all within one file, and if you like the idea of having separate files (I *don't* like this idea), then that would be an easy way to implement it that wouldn't be very different from implementing it the way I've suggested. > So, for the moment, can we put aside the issue of technical hurdles? > It's the "harmonizing potential conflicts" aspect that I'm more > interested in. > > Let's put it another way -- let's say you *had* to come up with a > multi-file, manually synchronized plugin equivalent to Sibelius's > Dynamic Parts. What would that look like? How would you want it to > resolve discrepancies between score and parts? [what follows was written *before* I wrote most of what is above, so it pre-dates my idea of having a Score file with data in it and part files with no data, just layout information] I would want to avoid the problem. Seriously. In a multi-user database, if two people edit the same record, you have some choices for what to do: 1. lock the record as soon as user1 edits it so user2 can't start an edit. Problem: inconvenient to user2, especially if user1 starts and edit and goes to lunch. 2. don't lock but keep track of who is editing. If user1 starts an edit, allow user2 to start an edit of the same record. If either of the users save the record, you have to inform the other user when *they* save the record that somebody else has edited the record and then you give them a choice of what to do: 1. overwrite the other user's changes with mine 2. drop my changes and use the other user's changes 3. show me the differences so I can resolve them somehow Now, all of this is a huge user interface challenge. First off, a dialog that gives you these 3 choices is very hard to understand -- most users won't know what the hell it means. You could skip it all and just do #3, but designing a user interface for that is very difficult, too. Of course, what you're suggesting is not multi-user editing, but it kind of comes down to the same thing. This is the scenario that is basically the same: 1. you have a SCORE. 2. you have PART1 and PART2. 3. you edit PART1. 4. you edit PART2. 5. you tell Finale to update the score with the changes you made to PART1. 6. you tell Finale to update the score with the changes you made to PART2. Now, what if you made mutually contradictory changes in PART1 and PART2 (and let's leave aside changes that shouldn't cascade back to the score)? Perhaps there aren't any linked changes that would overlap, but my bet is that there would be. Take, for instance, inserting a measure into a part. Say you insert it at measure 20. And you do it in both the parts. Finale has to be smart enough to know that you've done the same thing twice, not made two independent insertions. Now, from a common-sense perspective, that sounds simple, but from a computer point of view, it's rather complicated. If you think of it as FRAMES, and each FRAME is assigned a unique ID, somehow Finale has to translate from the FrameIDs of the part (which, since it's a separate, newly created file, independent of the score, will be different from the score) to the FrameIDs of the score. I don't know how this would be managed. A lookup table? Or, creating the parts using the same FrameIDs as the score? Again, I don't know, since there are drawbacks to both (the second is actually an attractive alternative, since then you'd have an exact match back to the original data; but I don't know if Finale's database engine allows it). This is only one example. Secondly, there's the other direction. Say you insert a measure in the score, and populate it with notes for the various parts. What happens when you open the part file. Does it check the score to see if there've been changes and ask you if you want to import them? I'd think it would have to, don't you? Now, what if the changes in the score somehow conflict with changes you've made to that individual part (and chosen *not* to send up to the score)? How does that get resolved? Should Finale tell you that changes imported from the score are going to overwrite some changes you've made in the part? Or should the score changes be lost in favor of the part changes? Again, we're back to the same kind of problem you have with multiple users editing the same record in a database -- you have to create a user interface to allow the user to resolve the conflict between the two edits. The alternative is to lose some or all of the changes, and that just doesn't seem like a good idea to me -- it sounds like a recipe for redoing your work many times, or a requirement for doing everything in a particular order of steps so that you don't lose changes (I'm philosophically opposed to computer programs imposing a user-enforced order of operations; either the program should preserve your changes, no matter what order you apply them in, or it should impose an order of operations that won't allow you to accidentally overwrite your own changes)! Now, considering the idea I came up with at the top for having separate part files linked to the data in the score file, this would allow you to have separate files. But I just don't see the advantage to having separate files without their own data. It just seems much simpler to me to keep these part files that include nothing but layout information as part of the main score file. It seems to me that the advantage of separate files comes only once you've completely broken the link back to the data in the score file. Once you've got two copies of the same data, you've got a major problem in keeping them synchronized in a fashion that is consistent with both contexts in which the data are used. ... I'm not sure if any of this makes sense to a lay reader. But I have definitely convinced myself that, assuming my surmises about the capabilities of Finale's internal database are correct, that it would be much easier to implement dynamic parts without duplicated data. That is, the easiest way is within a single file. The second easiest way is to have the separate part files *not* include any frame data, only layout data (the frame data would be linked from the score file). But I don't know if Finale's database engine would allow that. My bet is that it would require a substantial rewrite of the db engine to implement it, whereas keeping everything in a single file would not require nearly that much re- engineering. If multiple copies of the data really are maintained (the whole score in the score file, the part data duplicated in the part file, as is the case today with extracted parts), then you have to build lots of mechanisms for insuring that data retains a valid structure when you synchronize it between the two copies. That entails creating at least one user interface (and probably more than one) for helping the user manage and resolve conflicting edits (and clearly presenting the nature of the conflicts to the user is the hard part), and this seems like an absolutely enormous task. We already know that the folks at MakeMusic are not really geniuses at UI design, so I wouldn't expect such an interface to be terribly intuitive. Single-file data storage obviates the need for that entirely, and it also avoids a major rewrite of the Finale internal database engine in order to somehow avoid the problems of duplicating data in multiple files. And the whole problem of duplicating data in multiple files is what I've been harping on for years and years as the major flaw in Finale. It's the reason templates and libraries don't work the way they ought to, because creating a file on a template forks the file so it no longer has any connection to the original template. That is, it has a second copy of the data. Anyone who has ever tried to redo a batch of files in order to implement new layout, new fonts, new articulation/expression definitions, etc., knows exactly how much duplicate work is involved there. I keep a spreadsheet that records the settings so I can refer to them when I need to update a file. Yes, Robert's Settings Scrapbook can be used for some of these things, but doesn't work for all kinds of data, such as reconciling articulation definitions and such. Anyway, I've gone on much too long. >From my point of view, linked separate files sounds an order of magnitude harder to implement, regardless of how the implementation is designed. It may seem simple to a user, but in terms of the way databases work, it's very much more complex. -- 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