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
