At 07:49 PM 9/19/02 -0800, Mark D. Lew wrote: >Proper behavior of hyphens relies on a correct understanding by Finale of >what the "next" syllable should be.
Forget how Finale's lyrics work now. Just drop the concept. 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... >I'm citing an example of how the current system works. The user >behavior described (entering lyrics, deleting the note, and then >re-entering) is not unreasonable, yet it results in a messed-up hyphen >which to the typical user will be inexplicable. If your system would allow >the same actions with different results, I don't see how. It would "float" the syllables in the meantime, which could be reattached once the note corrections were made, or deleted from the visible text. They wouldn't become the invisible gremlins they are now, so there would be no temptation to retype them. I think you've skipped over the critical parts of my explanation, particularly the analogy to "slip" editing. Since I'm not doing a very good job of getting it across, I'll try a different summary. 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.) 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. 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. 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. >>2. The syllables change color and 'float' until you rubber-band reassign >>them or delete them. Most of the time such corrections will just mean >>reassignment. > >OK. They still need to be deleted to fix the hyphen, but your >color/rubberband scheme is there to make this more evident in the UI. Good >enough. 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). >can you edit >the base text while in type-in-score mode? It sounds like you're saying >you can't. In that case, what happens when the type-in-score person notices >a typo and wants to fix it? Is he not allowed to? 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, fine, but the type-in-score people are going to want to be able to >select a text from score view and then alter it by typing. If this alters >the base text, and other notes are attached to the same base text, then >you've got a problem. 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. >Yeah, I can hear them, too. That's why I think your proposed system >changes the underlying structure but doesn't get us any nearer to solving >the practical problems which are bothering people. 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. >If one plans well, the current lyric system is fine. I think people are >suggesting that a good system ought to keep you out of trouble even if you >*aren't* careful. Exactly right. And this will do that, even if you are determined to screw it up. It will just *look* messy, but it won't be messy because nothing can get permanently lost. >>I'm suggesting these do solve quite a few existing problems. Make the text >>an element that is dipped into as needed. Let's say it has the features of >>hyphen and space defining syllables, with a (visual) nonbreaking space and >>hyphen pair as needed. Once you have that database, it's usable once, many >>times, or in any order, a piece at a time. > >Isn't that the case right now? You can type text into the Edit Lyrics >window (on the template, even), and it's usable once or many times. I'm >not seeing how your suggestions make it any different. Because it can be used *differently* many times. Some here, some there, the whole thing, and even with words or syllables mixed up. You simply can't do that now. You crash and burn like David did. >Huh? I *want* to make text-style changes at the base text level. And so you can. And, nondestructively, in the local (in-score) text. >So you're saying that you want type-in-score delete to work the same as >adjust-syllables delete (ie, delete the assignment and leave the base text >alone)? I have no problem with that, but I don't see why it requires >turning the data structure around. 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. >Adding a missing syllable in type-in-score mode sounds like a very common >occurrance. If your default doesn't get it right, a lot of people are >going to be unhappy. It's going to be right. Just type it in there. It will be visually assigned. If you want it destructively applied (then or later), apply the edit. (You vill be varned.) >I think I'm still not understanding your scheme at all. Perhaps not. It goes back to a pool entry, and how it is largely kept intact unless a destructive edit is desired -- which is normally a rare occurrence. If it's a typo, you change it and apply the edit. Otherwise, the pool entry is left alone and drawn from and reordered and trimmed as needed. >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. >If as a side effect I can kludge barlines through the lyric function, >great, but I sure don't want the lyric function redesigned with that sort >of thing in mind. You can do that now, no problem. That's how I can stagger barlines consistently -- they all have the same baseline because they've been typed into score as lyrics and moved backward and up. >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. >If >there is no sequence of "nexts" in the text stream, what are you suggesting >instead? That this paradigm is not in force. :) 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. Dennis _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://mail.shsu.edu/mailman/listinfo/finale
