At 12:19 AM 09/20/02, Dennis Bathory-Kitsz wrote: >Forget how Finale's lyrics work now. Just drop the concept.
OK. > In what I'm >proposing, no 'understanding' would be needed. A hyphen or space would just >be a marker processed by the display system, and could just as easily be >moused in place like a smart shape or word extension. Onward... Yikes! I sure hope you have something better in mind down the road, because I sure as hell don't want to mouse in every hyphen. That would be horrible. I want hyphens to know how to keep themselves centered between two syllables, even if the syllables move, and I want them to know to add more hyphens when the distance goes beyond a certain threshold. Right now they do that. If they lose that ability, there had better be something else to take its place. >I think you've skipped over the critical parts of my explanation, >particularly the analogy to "slip" editing. Yes, I skipped that because I couldn't make heads or tails of it. I know nothing of audio recording editing, and the analogy was completely lost on me. >The several major modes of entry would still exist. Both would create text >pool entries. Type-into-score would be creating pool entries on the fly >(incorporating corrections until the mode was exited), and text-window >entry would create them in bulk. They would be stored as any other text, >and could be assigned or reassigned as needed. (Editing could be forced >from either mode, and would be the province of more experienced users >willing to enter destructive-editing mode -- keeping in mind that **all** >lyrics editing in Finale is presently destructive.) Unless you count deleting from adjust-syllables mode as editing, yes. >Here is an incomplete description: >TYPE-IN-SCORE ENTRY: Text, fonts, styles, colors, sizes, weights, etc., all >available. Creates a new numbered text pool entry on exit from >type-in-score mode (including the text formatting), on command keystroke, >or on "thumbwheel up" (new numbered entry starts). Resulting text pool >entries can be click-assigned elsewhere. I don't understand the term "thumbwheel up". >TYPE-IN-SCORE EDIT: Mode 1, nondestructive edit -- changes only the visible >contents (see also accept-edits command, below); Mode 2 (with warning), >destructive edit. >TEXT BOX ENTRY: Text, fonts, styles, colors, sizes, weights, etc., all >available. Creates a new numbered text pool entry. Can be click-assigned. >Can be used as a text block in score. "Thumbwheel up" starts new numbered >entry. Subsequent in-score edits behave as type-in-score, above. >TEXT BOX EDIT: This is always a *destructive edit*. All lyrics in the score >change. Warning displayed. >NOTATION EDIT: Floats text when notes deleted. Floats gray marker box when >notes inserted. Keypress-click-drag to stretch the hyphen, space, or word >extension across the area. I don't understand what "notation edit" is. Are you talking about dragging the syllables around? I'm also still not following how hyphens fit into this scheme. >LYRICS EDIT OPTIONS: Drag and drop syllables, words, or groups; rubber-band >assign/reassign notes; select and drag positioning (syllable shift, >re-centering, baseline adjust); copy/paste (nondestructive editable copy of >current text pool entry), copy/paste (new copy=new numbered text pool >entry), copy/mirror (nondestructive mirrored editable copy of current text >pool entry). Mirrors would have shading or other indication of their >mirrored status, and show ownership. >ACCEPT-EDITS COMMAND: Searches score (or selected area/staff) for all >visible text changes and applies them according to a series of selection >options (such as consolidate text, resort text, smash mirrors, etc.) with >or without confirmation of each acceptance. > >The major difference is usability and visibility. You could tangle them up >like a rat's nest of cables, and they would still be loyal to their place >in the contiguous text as it was entered *and you could find them* because >of their visible ownership. Um, OK, I can see the visibility improvement, though I'm not sure why you couldn't achieve it with less roundabout means. I'm still not getting the usability advantage. For example, suppose I've got an art song with a French text and an Italian text. After putting in the lyrics, I decide I want to move the baseline of the Italian lyrics down 6 pts. In the current system, that's a snap. I'm not seeing how I would do it in your version. Are you envisioning baseline as a feature that can be edited from Text Box window? >There's no hyphen fixing or fixation:) going on. If the syllable contained >a hyphen marker, it still contains a hyphen marker. In the unusual >situation that the word was force-edit changed to one without a hyphen, >some sort of context menu could make the change (with accompanying warning >box if the change was intended to be applied to the pool contents). Well, I'm still fixated on the hyphen because I don't understand how you're making them work. You said something about dragging it around with the mouse, and that scares me. I don't want to have to place all the hyphens myself; I want the program to intelligently calculate that for me -- which (with the notable exception of crossing system breaks) it currently does fairly well. >Two options would always be available -- to edit the current (visible) text >(nondestructive), or to force the edit to the base text (destructive). >Again, a stupid-move warning box would need to appear, and an accept-edits >feature could clean up the mess. OK, suppose you're in non-destructive mode. A certain syllable is attached in more than one place in the score. If I edit it in type-in-score mode, how does it change the one assignment without changing the other? Do you create a new syllable and add it to the end of the text stream? >Which problem are you wanting solved with this question? From one >viewpoint, you can think of (say) MSWord's round-robin editing mode. >Changes are not committed until after the edits are made. The base text is >the pool, and the edits are maintained separately (and differently >colored). It can get messy, but the result is solid, and accept-edits >cleans up everything that's visible. I don't understand this. I don't know what MSWord's "round-robin editing mode" is. >Have you actually used nondestructive editing? I think it would go a long >way to help envision how this would work, and how it would solve almost all >the problems that are seen. I don't know. If so, I don't recognize the term. >Because the text is an integrated element. You assign to it because it is a >pool item. It gets to be used for many things, including lyrics, commentary >text (for a reader), descriptions, and even titles and subtitles. Let's say >you have a score with a few repetitive phrases, perhaps biblical with some >words in italics, and it also includes an unmetered spoken area (with the >same texts, or parts of it), and other areas where it's in bordered blocks, >on a diagonal or curve following a dynamic, or part of a shape -- and it is >also the title and the copyright and in the credits and included in full on >the last page. > >Using this method, that same text can appear in all those places for a >single pool element. That doesn't seem like a big deal to me. I don't see why lyrics should be combined with every other text. I do in fact occasionally retype the lyrics separately into a text box (if I'm including a separation translation at the end of a song), but retyping (or cutting and pasting) the lyrics into a text box is trivial. Surely you're not rehauling the entire data structure just for that. >>The whole thing sounds to me like it's an abstract database concept not >>directly related to how one is likely to use lyrics in engraving music. > >Like the current method. Ahem. I don't see it that way. The current method, notwithstanding its various shortcomings, still bears a basic resemblance to how lyrics (in my mind) ought to behave. You can create any number of strings of ordered text. The basic indirection lets me view the text separately from the music. The existence of the separate "verses" in which I can group texts lets me make changes to a logical group all at once. The existence of an established order of syllable makes it possible to do all-at-once click-assigning, lyric-shifting, and intelligent placement of hyphens. What I'm hearing you say is that yes you're keeping all of that but at the same time you're changing it all (which confuses me), and meanwhile you're mixing it all in with every other kind of text in the file (which further confuses me). Maybe your scheme is some wonderful new thing that will magically solve all the problems, but I just don't get it. I feel like I'm listening to a late night TV infomercial: It'll do this! It'll do that! Throw out all your old tools because this one will do everything! >>Obviously I'm just not understanding this at all. Let's back up. If a note >>has a syllable and that syllable has a hyphen, how does the program know >>where to draw the hyphen? Currently it does it by looking at the position >>of the syllable which it recognizes as coming next in the text stream. > >It continues to draw the hyphen(s) until the next syllable appears. You can >type it or drag/drop that next syllable, or click-drag the hyphen line. >That's the easy part. OK, but how does it know what syllable counts as the "next" one? You keep telling me that there's no such thing as a "next" anymore. >>If >>there is no sequence of "nexts" in the text stream, what are you suggesting >>instead? > >That this paradigm is not in force. :) See, like that. >I just finished some studio work that began as a Midi file and some >separately recorded vocal tracks. I had to sync these and create a full >result. The work of applying the bits and pieces of various singing takes >to the Midi track (which was also being edited) was exactly like applying >lyrics to notation -- I could split, click, drag, re-order, copy, paste, >and shift around everything I needed to get their s's and t's in sync, >their notes in tune, and the spaces closed up or moved apart. Compared to >this, lyrics are a piece of cake -- just put 'em into a pool and mess 'em >up in the score as needed, then apply the results. Huh? I've never done Midi editing, but it doesn't sound "exactly like applying lyrics to notation" to me at all. In fact, it sounds completely different. I appreciate your zeal in making it possible to drag and re-order and mix them up with abandon, and I surely agree that maximum flexibility should exist for special occasions -- but the bottom line is that I really don't WANT to spend an hour tossing my lyrics around like a salad. I want to just type them up in a logical order, assign them to their proper places in the score, and then be done with it. -- Dennis, I know you described all of this to me because I asked for it. At this point, I think I'm overwhelmed. If you want to continue trying to explain it to me, I'll keep trying to read it, but if you're only persisting for my sake, I'm ready to give up. Anyway, I think it's a safe bet that Coda isn't going to make such a drastic change to the data structure. I gather that some people will never be entirely satisfied so long as the underlying structure remains the same. Nevertheless, I think we all agree there are plenty of superficial changes which would go a long way toward reducing the mess. mdl _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
