In various posts, David W. Fenton wrote: >Historically speaking, yes. But before I upgraded to WinFin2003, [...]
Oh, so you're in Fin 2003 now. Does that mean it has changed back?? In MacFin2002, if I use type-in-score to enter lyrics out of order, but within a single staff and verse, Finale will arrange them in the Edit Lyrics window to match their order in the score. >I can't see using click assignment for any large project. The user >interface is hideous, with a non-resizable window and insufficient >feedback about where you are in the text stream, and what is >connected to what. I still don't know how to un-assign a syllable, >except by deleting it using TYPE IN SCORE. If you're in "Adjust Syllables" mode and you delete a lyric, it removes the assignment but leaves it alone in the text stream. If you want to remove several assignments at once, Mass Mover->Clear Items->Entries->Lyrics also removes the assignment but leaves the text alone in the text stream. >The whole lyrics substructure should be redesigned from the bottom up >and a new user interface created. I would certainly oppose that. I want some sort of Edit Lyrics windows, and I don't want all of my files from previous versions to become unusable if I upgrade. -- >Know, my computer doesn't have an OPTION key. OK, but I'm sure the same function exists with a different keystroke. >In any event, with a highly melismatic piece, the SHIFT LYRICS is >very tedious, as it removes all assignments to the right of the >syllable you are moving. Another improvement I would like is if the multi-click-assign (the one that's option-click on the Mac) could examine the music for slurs and skip notes melismatically accordingly. Even if you're using a style in which you won't be keeping the slurs anyway, this could still be a help. And if you are entering the slurs, it will be automatic so long as you enter the slurs before the lyrics. I'm not sure what you mean by removing all assignments to the right of the syllable you are moving. The whole point of Shift Lyrics is that it moves the entire string, right? >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. So long as I keep the advanced features, I have no problem with whatever reform to the UI you recommend. But I still don't see why a restructure of the data is necessary, and if doing so fouls up the advanced features that currently exist, that's a problem. >The lyrics tool requires too much specialized knowledge to be useful >for the person who uses it very seldom. That it was formerly much >worse is really completely irrelevant since it is still >extraordinarily badly implemented. Being dead is worse than being in >a full-body cast, but neither is a desirable state. The more I read, the more I'm thinking it would be a good idea to have a separate "Simple Lyrics" system, sort of like Simple Entry. >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. No, it's not. That's not how I operate, and that's not how sample files provided by Coda operate. >That makes it very dangerous to edit anything, since you can't tell >what the results of the edit will be. Much of the danger could be fixed with some simple reforms, short of redesigning the underlying data structure. The rest could be fixed with a more explicit UI, again without redesigning the underlying data structure. >How you could call TYPE IN SCORE "behind the scenes" is beyond me. >Looks like Stockholm syndrome to me. It's because I recognize the Edit Lyrics window as the "canonical" text (as you describe it), and I am accustomed to thinking of any changes there as being direct and any changes through type-in-score as being indirect. You are correct that this way of thinking is "geeky" and I only view it this way because I'm accustomed to thinking like Finale thinks. I've already acknowledged that "behind the scenes" was a poor choice of words. >So, you agree that the user interface is fundamentally broken, >because it allows changes to be made without indicating the >consequences of those changes. Essentially, yes, though I probably wouldn't use the word "fundamentally". >To me, type in score is the only sensible way to enter lyrics, as I'm >creating a score with lyrics in it. > > [...] For just about anything else, the simplest interface is TYPE IN >SCORE. For me, it is much faster to type all the lyrics in the Edit Lyrics window and then assign them using (option-)click assignment, combined with shift lyrics. Others have different preferences. Finale should be able to accommodate both preferences, just as it accommodates both Simple Entry and Speedy Entry. >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. I agree that the two interfaces need to be more consistent, and elsewhere I have suggested some reforms that would bring them a lot closer. I still believe that complete coordination is not possible, because the essence of type-in-score is that the user is not specifying a position within the text stream, and thus the program must infer it from the position on the page. >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. In FinMac 2002 it does not. Within any given verse and staff, it infers an order based on the position in the score. If your experience is different, I don't understand that. >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. So long as you enter different voices in different verses (which I suppose might be made automatic as a default), and you don't make edits to copied lyrics (which could be flagged by a warning), I don't see why your preferred method of entry would have mixed up the lyrics in the text stream. Perhaps I'm missing something. >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. No, but you can't be in a fantasy world about how the program works. If your way of looking at the music is that a "voice" should be a single unit throughout a piece regardless of which staff it appears on or whether other voices appear in different layers on the same staff, that's all well and good. But if you expect to use the program you'll so better to accept that Finale works differently. When you say that Finale ought to work differently, I can agree or disagree. When you say how Finale does work, you are either correct or incorrect. You stated that lyrics are like music text and not like expressions. In Finale, that is not true. >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. I thought you did fix it. >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. I agree that the user interface (and documentation) should better illustrate the underlying data. >> 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. If you mistakenly change the time signature with rebar turned on, and then proceed with numerous other changes elsewhere in the file before noticing the error, undo becomes just as impractical as it was for you with your lyrics. This happened to me once, when I thought I was changing the time signature for one bar only and didn't realize until later that I thoroughly mucked up everything that followed. It was a disaster, and I ended up redoing a lot of work. -- >> "3. Never use Type-in-Score. Type your lyrics in the Edit Lyrics box, and >> enter them in the music using Click Assignment. [...] > >And TYPE IN SCORE is the most intuitive and the only proper way for a >graphical program to enter lyrics. Now you exaggerate. It is surely not the "only proper way". You are denying alternate entry methods for those of us who prefer them. Hyperbole like this is what makes me so quick to dispute you, because you seem to be insisting that everyone else must do things your way. >[...] Saying that it shouldn't be used >shows that you admit that the implementation is fundamentally broken. Yes, I know. Someone asked for a "lyrics for dummies", so I was going for the simplest instructions that would keep someone out of trouble. For a non-dummy, the better answer is to get to know the system better so that one can get the most out of it and still avoid the pitfalls. An even better solution is if Coda makes some significant improvements to the program, but we have little say over whether that happens. -- >The problem is not the concept, but the fact that the user interface >fails to hide the underlying implementation from the user. Or, more >correctly, it doesn't expose enough information about the underlying >information to allow the user to understand what is going on. > >If the user needs to know that a syllable is multi-assigned, then the >UI needs to indicate that somehow and no allow the user to >unknowlingly do something to that syllable that will corrupt the >source data stream (such as deleting it in TYPE IN SCORE mode). > >The point is, the user shouldn't have to know -- the program should >make it impossible for a user to unknowingly take an action that will >potentially corrupt the underlying data stream. > >[...] >And that's the fundamental problem -- Finale's UI is not making clear >the consequence of edits. Nor does it represent in any way how the >underlying data stream is being used. Amazingly, you and I are getting closer to a consensus. I agree with everything in this post. -- Thanks for starting such a lively thread, David. In spite of the frequent contentiousness, I think it has been very constructive. mdl _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
