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
