On 19 Sep 2002 at 17:04, Mark D. Lew wrote: > 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 don't know if it's changed, but the soprano lyrics are at the end. I think this is because I started with the beginning of the Requiem, and the basses enter first, the sopranos last. I haven't checked too carefully, because there's too much junk in there, all of it the same, for me to be able to tell what's linked to what. Which is, of course, one of the problems -- the interface doesn't give enough information to be useful. Had I entered the lyrics with each staff in a different verse, this would be more organized, but even when that the workaround is not used, UI should still give you sufficient information to know what's going on. [] > >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. This is exactly what happened when we were discussing TYPE IN SCORE for expressions -- people oppposed it on the grounds that the people calling for it were going to gut the program of its existing features. That's not a viable debate tactic with me -- don't impute to me arguments I have no made. That is, I would not be calling for a removal of any functionality that is presently there, just a completely revision of how it is implemented. > -- > >Know, my computer doesn't have an OPTION key. > > OK, but I'm sure the same function exists with a different keystroke. I don't know what function you are speaking of. Does it have a name? What does it do? > >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? Yes, but it compresses everything into a syllabic assignment, removing any melismas in what is to the right of the shifted syllable. > >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. NO ONE IS CALLING FOR ANYTHING THAT WOULD "FOUL UP" EXISTING FEATURES. Geez. I get so tired of people arguing on the assumption that those who want the problems fixed are advocating the removal of features. > >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. After my first day with Finale, I've never touched Simple Entry. If it were gone, I'd never miss it. Type in score, though, is completely different -- it is the obvious way to put lyrics into a score, and should be fixed so that it works. > >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. But that's the only justification for building the whole infrastructure around the notion of assignment of one syllable in the text stream to multiple notes. If that is not seen as being the point of it, then it is nonsensical to build it in that fashion. > >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. The UI should allow 100% control over the data. Right now, it does not. > >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. Like a WordPerfect user and VIEW CODES mode, you are arguing that a flaw in the original implementation is now something you cannot work without. > >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". It doesn't give expected results, based on the expectations raised by that interface, and won't allow you to correct inadvertent errors without deleting the problematic text altogether. That seems pretty fundamental to me. [] > >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. What I'm saying is that IT SHOULDN'T MATTER. The user shouldn't have to worry about the issue at all. > >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. It think the order is chosen by the order of entry in time -- the voice that has lyrics first is first in the canonical stream. That would explain my file. > >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), . . . But they aren't really different verses, so why would one do that? Yes, I know, it's a workaround that helps you manage your text streams, but it *is* a workaround, one that would not be necessary if the UI and data store were better connected. > . . . 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. I really don't know what actually happened. I should need to *worry* about what happened. I should simply be able to edit the score to return it to the state that I intended. I was able to do so, but only by doing many of the edits multiple times. > >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. I'm fine with workarounds, but pragmatism is not a defense of the *rightness* of the implementation. In fact, it's an admission that there's something wrong in the first place. > 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. Then Finale is poorly designed. > >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. I fixed it by doing a whole lot of work twice. I should have been able to fix just the text that got accidentally edited (from the copied mirror), as that was the only thing that was wrong. But that wasn't sufficient, as there were errors onscreen that I could not see where they were coming from. I had to delete the affected sections of lyrics and then completely re-assign all the syllables that followed (using SHIFT LYRICS). If the interface worked properly, I should only have needed to fix the parts of the lyrics that were WRONG, rather than having to completely redo large swaths of lyrics assignments that were correct even after the error was made. [] > >> 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. A good example, and one that I have been thinking of. To fix it, all you have to do is change the meter, stick in an appropriate note value to shift things and it will rebar itself back to the original. Certain things are volatile and will be lost (such as beam breaks), yes, but the basic underlying structure is not lost, as with lyrics. -- 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
