>Date: Sat, 13 Jul 2002 02:27:01 -0800 >From: [EMAIL PROTECTED] (Mark D. Lew) >Subject: Re: > >I too dabbled in Mosaic once,
When? > and my experience there didn't really sell me >on the "view" idea. The basic concept was fine, but in practice I found it >didn't work too well. But maybe I just hadn't learned the program well >enough. Although MotU hasn't updated Mosaic for several years, it *did* go through numerous incremental developments from 1989/90 to 1995/96 (or there abouts). The end effect is that the difference between 1.0 and 1.58 is ginormous. Really: you have to see it to believe it. The View/Staff/Voice thing works *pretty* well. The 1.58 implementation does, admittedly have shortcomings, but the could all have been handled if MotU had been prepared to continue development. There is nothing wrong with the idea that could have been made to work right. Along similar lines, >Date: Sat, 13 Jul 2002 00:47:25 -0600 >From: bappleby <[EMAIL PROTECTED]> > >Whenever I'm working on a database in Filemaker, I often think that it would >be great if Finale could somehow work like a database as far as score and >parts go. Finale is already working more like a database than you may be aware of. (Aside: is Coda still relying on the CTree framework?) I was going to insert at this point "That's the way MOS works!" but you beat me to it.-) > MOTU's Mosaic was kind of along these lines - maybe it's too hard >with music and that's why that program was basically abandoned. No, the sad truth is that MotU is making most of its money with Digital Performer and that's where they see their future. They, too, have to set priorities for how to invest their resources, and Mosaic is not in their future business plans. Alas The way MotU handled the situation seriously browned off about 99.44% of their Mosaic users (statistical error: +/- 0.79%). A good example of how not to treat one's customers. But that's neither here nor there in this context. The point is: the Mosaic approach is *not* "too hard" to implement. (Not exactly trivial, but no approach to music notation is going to be "easy"). MotU simply has moved on to other things. >From: "Colin Broom" <[EMAIL PROTECTED]> >Date: Sat, 13 Jul 2002 10:05:42 +0100 > >Additionally, I would think that if a program like Finale (and let's face >it, this is never going to happen in Finale) did make files that contained >information pertaining to not only the layout of the score but also the >layout of all the parts would result in massive file sizes. Two things here. 1) Mosaic files are a *fraction* of the size of an equivalent Finale file. And that is *with* the combined score/parts-in-one-file approach. This is because Mosaic's data format is (must be) fundamentally different than Finale's. One disadvantage of Mosaic is that performance doesn't scale so well when scores get really big (think Wagnerian opera). But this is moot. The main point is that a score-with-parts format does not need to be (Number-of-Parts + 1) times the size of the scorefile. Probably won't be even twice the size of the scorefile. Most of the data (notes, articulations, etc.) only needs to be stored once, it's only layout data that will increase if you merge score w/parts (and any "override" information, where parts are not 100.00% identical to the score). So, files won't be much more massive than the currently inflated size of a Finale file. 2) You're right: this is not going to happen in Finale. At least, not in the short term. Coda has been following a policy of incremental evolution for at least five or six years. But: never say never. >Still, it's a nice idea, in theory. It's a nice idea in *practice*. I've seen it, and it can work. 3) OK, I lied, but this final comment applies to all the remarks on linking scores and parts: Aside from a "views" mechanism à la Mosaic, there is also the Publish/Subscribe approach (as mentioned previously). What no one has mentioned is the "book" approach used in FrameMaker. While the model, as used in Frame (or Word's wooly variant), wouldn't map 1:1 to music notation, the basic notion of a set of files (i.e., parts) that are "merged together" into a score (whereby certain attributes--indeed, a large number thereof) could be tweaked or overridden)... such a notion is a viable alternative. The trick is that, with music notation, people would want to edit the "score" and have the "parts" updated. The merge-parts-to-score-while-providing-the-illusion-of-letting-the-user-edit- the-full-score approach is doable. Not easy, but doable. Even robustly doable (without rampant file corruption, as someone was worrying about). And politely doable (as opposed to Mark's dystopic vision of an app wildly modifying files). And there are still other approaches... G'night, Peter --------------- <http://www.bek.no/~pcastine/Litter/> --------------- Peter Castine | From the Litter Power Thesaurus: [EMAIL PROTECTED] | Triangular distribution: lp.linnie [EMAIL PROTECTED] | _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
