> At 9:33 AM 09/18/02, David W. Fenton wrote: > > >However correct you may be as the voice of experience, that is the > >most ludicrous advice I've ever heard. [...] > > > >That's a really serious indictment of the stability of the Finale > >file format. > > First of all, David, welcome to the club. Those of us who use lyrics on a > regular basis have been complaining about the weak implementation for > years. If you have any more voice with Coda than we do, we will welcome > your support.
WinSupport has not responded to my email message. I solved the problem myself using hints from people on this list, and I'm quite grateful for the knowledge exhibited here. I did not take your advice, thankfully. > I don't mean to give the wrong impression. I agree with you that > there are serious problems with Finale's lyric system. I wouldn't use > characterizations like "corrupt", "broken" and "bug" the same as you > do, but the fact that it's possible for a user to inadvertently make a > mess of things is definitely a problem. Making a mess is not the problem -- it's the lack of capability for undoing the mess that is the problem. That's where "corrupt," "broken" and "bug" come in. > If it seems like I'm defensive of the system, it's because I'm a little > miffed to see a person who, by his own admission, a week ago had no idea > how lyrics work, and by the evidence of his posts still doesn't really > understand it, nevertheless has the audacity to come along and tell us how > the program ought to work. A lot of the suggestions you make which would > make lyrics easier for you would make it less efficient for the rest of us. Dennis has already defended me adequately, I think. But the point is, if someone who has been using Finale since 1990 (i.e., someone who is quite accustomed to Finale's idiosyncracies and counterintuitive approaches to many things) has this much difficulty, then how much more difficult is it for the new user *without* all that experience? I understand perfectly well *why* Finale "handles" lyrics this way. I don't think understanding it justifies it, though. It's a fundamentally bad design, poorly implemented, precisely as Dennis says, because it requires the user to understand the inner workings of the program in order to avoid mistakes. > I'm all in favor of making lyrics more intuitive and less treacherous for > inexperienced users, but not if it comes at the cost of dumbing down > functionality for those of us who know what we're doing. . . . Again, bollocks. Making a user interface that works does not require abandoning advanced features. It just requires designing the UI properly so that the novice user can't screw things up, and that when and if they do, they have all the tools they need to fix the problems. > . . . The lyric system > is definitely in need of improvement, . . . It is in need of a fundamental redesign. > . . . but an intelligent improvement needs > to take into account all of the functions that regular users of lyrics > need. In that respect, you simply are not speaking from a position of > knowledge. The system is designed around an assumption that the default and most desirable method for lyrics entry is to enter the words used one time, and then assign them all multiple times. That's a recipe for disaster, especially when there is no representation at all of what connects to what, either when viewed in the canonical version (EDIT LYRICS) or in the output representation (scroll or page view). That makes it very dangerous to edit anything, since you can't tell what the results of the edit will be. > >I will mail the file to Coda to ask them to fix it before I will even > >contemplate re-doing literally hours and hours of lyrics placement. > > Hours and hours? What kind of file takes hours and hours to assign lyrics? > Either you're exaggerating or you work very slowly. If I had been forced to put the lyrics back in, it would have required 3-4 hours of tedious work. Working from a source full score to an arrangement where the parts move around in comparison to their original source means that I'd basically have to completely re- analyze the arrangement itself. That's not the worst thing in the world (I did, in fact, find one ommitted part, but that was during the original editing of the copied passage), but it is work I shouldn't have to do. Once I've done that, I then have to go back and re-proofread 120 measures of text that had already been proofread. That's several more hours of work. The whole point of my doing a copy was that I knew that having the text of the copied part finished and proofread would mean that the copy would be consistent with the original. And even if it were *one* hour of extra work, it shouldn't be necessary. > If you want to email a copy of the file, I'd be happy to take a look. I > don't know that it will be of much practical help, but it might help focus > this discussion if I can figure out exactly where you went awry. A cc of > whatever you send to tech support would be fine. I thank you for your generous offer, but I have fixed it myself. > >From my point of view I was not doing anything haphazard. It's only > >in the crazy upside-down world of Finale lyrics copying that I was > >being haphazard. > > Fair enough. From my point of view, if you copy lyric assignments and then > use type-in-score to alter a syllable which is already assigned elsewhere, > that is haphazard. (And if you then go back to the first assignment and > alter them back, that is even more haphazard.) It is only haphazard from the point of view of the inner workings of Finale. And we are a long way from the days when computer users needed to understand the insides of the programs to avoid corrupting their data. > >> Your initial problem resulted from this. Your subsequent problems with > >> hyphens, mixed up syllables, and so forth resulted from trying to go behind > >> the scenes and patch together repairs. > > > >I did nothing but type-in-score corrections -- nothing behind-the- > >scenes at all. > > "Behind the scenes" was a poor choice of words. My apologies. From my point > of view, type-in-score *is* behind the scenes, but I can see how it would > look the opposite to you. How you could call TYPE IN SCORE "behind the scenes" is beyond me. Looks like Stockholm syndrome to me. > >In fact, I used only the editing facilities exposed by the > >programmers, so the results should be reliable and consistent. That > >they are not shows that the program is fundamentally broken. > > Well, the results are reliable and consistent, they're just reliably and > consistently what you don't want. . . . You have a gift for the Orwellian turn of phrase. > . . . As I mentioned in the other post, I think > the type-in-score for lyrics was a bad idea (I personally never use it), > because it allows the user to make a change in the lyric text data which > will affect all assignments, without going through some dialog that makes > it clear that that is what's going on. In other words, it opens the door > to unintended consequences which are not immediately recognized. That is > bad. So, you agree that the user interface is fundamentally broken, because it allows changes to be made without indicating the consequences of those changes. To me, type in score is the only sensible way to enter lyrics, as I'm creating a score with lyrics in it. Treating the lyrics printed in the score as specific instances connected back to a source text stream is a fine feature, but it should be secondary -- that's the one I'm not likely to need. Sure, if you're writing homophonic church hymns, that will work extremely well. For just about anything else, the simplest interface is TYPE IN SCORE. That the results of the two interfaces to the same data store are not consistent, and that the one can corrupt the underlying data clearly demonstrates that the whole structure is fundamentally flawed. > (An even larger problem, in my opinion, is the fact that when syllables are > added and deleted using type-in-score, Finale tries to second-guess your > intention with regards to how to order them in the Edit Lyrics window. > Obviously, this was done for the sake of the occasional stray syllable > deletion or insertion after the main entry, and for such cases is it works > nicely. But it also opens the door for even more serious unintended > consequences for the user who carelessly edits multiply assigned syllables > with type-in-score.) Why Finale would store things in the entry order instead of in the order in which they appear in the score, I do not know. That makes no sense to me at all. Except in terms of the underlying assumption behind lyrics that what everyone needs is a single text stream that will be assigned multiple times. > >The changes to the musical text were trivial to recreate in > >comparison to the Draconian advice that I have to completely redo the > >lyrics from scratch. > > I'm still amazed that re-assigning lyrics could be such a huge task. I > think of it as one of the quicker parts of the entry process. Is this just > a matter of experience? It is just the difference between click-assign and > type-in-score? Well, because everything was entered in an order that created a very haphazard underlying text stream, fixing the problems was not trivial. >From the end user point of view, what I entered was not haphazard -- it was quite orderly in terms of the score layout. That Finale allows me to have one metaphorical paradigm in mind for what I am doing and that this paradigm is prone to creating data that is very fragile shows that there is a fundamental design problem with the user interface. > >> . . . It is exactly analogous to how articulations > >> and expressions work. If you were to copy several measures of music > >> complete with all the expressions, and then went in to change individual > >> instances of "mf" or "cresc" to "mp" or "dimin.", you would make a hash of > >> your expression list and foul up other instances of those same expressions > >> in the same document. > > > >But lyrics and articulation definitions are fundamentally different. > > > >Lyrics are like the musical text. If Finale created a mirror by > >default and offered no other copying method, *that* would be > >analogous to the way lyrics work. > > No, David, lyrics are NOT like the musical text. What you are describing > is how you think it ought to be, not how it is. Your inability to reconcile > the way you feel the data ought to be structured and the way it actually is > structured is at the heart of the difficulty you're having. You're telling me that Finale forces me to change the way I look at my music, and adapt my music to Finale's data entry methods. You don't see anything wrong with that? > >Oh, bollocks. This is an instance where Finale is fundamentally > >broken. The default behavior of the copy is one issue alone, an ill- > >chosen default with no sensible alternative. But the real issue is > >that the process is not *reversible*, that once the mistake has been > >made, you can't undo it. > > You could have easily undone it, IF you noticed it when you first did it. But I *didn't* notice it. I should not have to rely on the undo buffer to edit my data. Had I been composing instead of transcribing, I could just as easily have changed my mind about what lyrics I wanted where, but it would have been just as difficult to undo. > The problem here is that the interface makes it possible for you to > accidentally alter the data in a way you did not intend without noticing it > until much later. Here is one point where you and I might agree, because I > too feel that is a serious flaw in the program design. It is a fundamental problem. It is all but a bug. > If when you made your first alteration to the copied lyric you had > immediately noticed that it made a corresponding change to the original > lyric as well, you would have said, "oops, that's not what I wanted" and > you would have used the undo function to reverse it. The problem is that, > because the unintended change was far away in your score, you didn't notice > it, so you proceeded with numerous edits and didn't notice the error until > much much later. Yes. And that shows that "you could have used UNDO" is no response at all, as it has nothing to do with the underlying problem. A program should always allow you access to alter your data. Finale in this case almost does not. > >> . . . Unless you're revamping the whole lyric scheme > >> altogether, that would be illogical and inconsistent with how the system > >> works. Would you have it do the same thing for expressions? > > > >Expressions copy in exactly the way that's expected. > > Yes, and lyrics copy in the same way that expressions do, but that isn't > what you expected. In terms of what I'm doing, appending a copy of data to the end of a file, the copy should simply be appended in the relevant locations. I see no reason why lyrics should create a link and the other musical text should create new frames with actual copies of the source data. I can see that it would be useful, naturally. I just don't see how it should be the *default*, nor why there is no option other than not copying lyrics at all. > >This is very different from any issue I've ever encountered, in that > >my data is corrupt and I can't correct the corruption short of > >deleting all lyrics data and starting over. > > Suppose that you have a four-bar passage which for some reason gets entered > entirely wrong, but you fail to notice the error and proceed with entering > the rest of the piece. After the first proof, you notice that the passage > is hopelessly mangled, but of course you can't use "undo" to fix it because > then you'd lose all the rest of your work. You could then say, "my data is > corrupt and I can't correct the corruption short of clearing all four bars > and starting over". But I have access to the tools I need to edit the data. With lyrics, the tools are too abstracted from the end result that I can't fix it. > The fact that the lyrics got messed up in the first place is in large part > due to the screwiness of the system, yes. The fact that you can't > magically repair them without starting over is nothing unusual at all. It is definitely a result of the underlying problem, that the user interface tools are wholly inadequate for representing what is actually going on in terms of source data and score representations based on that data. > >What the hell does "haphazard" mean? If the UI allows it, there's > >nothing haphazard about it. > > The UI allows me to transpose down 12 octaves. The UI allows me to rebar > an entire piece to 1/16 time. Surely you're not taking the position that > the UI should make it impossible to do anything stupid. And the UI also allows you to undo those things with predictable results. With lyrics, that is not the case. > >From my point of view I did nothing > >"haphazard" at all. I entered the lyrics syllable by syllable, page > >by page of my source score. I then copied and started editing the > >copied lyrics. > > > >This was not "haphazard" in any human-meaningful sense -- it was > >fundamentally logical and systematic. That Finale screwed up the data > >shows that the haphazardness is inside Finale itself. > > No, you screwed up the data. Finale did exactly what you asked it to do, it > edited the copied lyrics. The problem is that you thought you could edit > one assignment without affecting the others. I agree that the program > should make that more clear to users. Finale misrepresented what I was doing. And doesn't provide tools to undo that. That's a fundamental and serious problem. > >> [*] One thing that would make all these problems go away is if it were > >> changed so that it's impossible to assign the same syllable more than once. > > > >But then that would take away the capability of re-using a single > >text block in more than one place. That capability is a *good* thing. > >That it is the *default* for copying is where things start to go > >wrong. That a mistaken copy operation is not reversiable is the most > >serious problem. > > It *is* reversible. You just didn't notice it in time to reverse it. . . . Undo is not a valid response to my complaints about reversibility. If you transpose something down 16 octaves, you can close the file, close Finale, copy the file to a disk, take it to a different computer, open the file and transpose it back up 16 octaves. The mistake is reversible using the user interface of the program. With lyrics, the "mistakes" I made are not reversible except with extensive editing. > . . . If you > were paying careful attention to every edit you made, you could still > reverse it. Since you weren't, it's easier to clear out the lyrics and > start over, but for some reason you're resisting that. So, it's my fault. Message loud and clear. > -- > Obviously, David, you and I aren't going to agree on most of this. To > whatever extent you would like help in learning how to make best use of > Finale the way it is, I'm happy to offer it. If we're just going to argue > about how wrong it is and how it ought to be, you and I have each stated > our position and we disagree on many points. I have no further interest in > trying to persuade you otherwise; if you want to continue to try to > persuade me, have at it. I get sick and tired of people who defend in Finale those aspects that are so clearly screwed up, just because they've invested the time in learning how to avoid the places where Finale screws things up. Finale will not survive as a program if these kinds of braindead stupid implementations are not fixed. Sibelius will triumph unless these kinds of cases of very poor design and implementation are fixed. Explaining how to avoid it does nothing to excuse the fact that it shouldn't have been that way in the first place. -- David W. Fenton | http://www.bway.net/~dfenton David Fenton Associates | http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
