On 20 Jun 2004 at 17:36, Christopher BJ Smith wrote: > At 5:02 PM -0400 6/20/04, David W. Fenton wrote: > > > >No, I didn't try using a clip file, because I have absolutely no > >comprehension of why the hell there are three different methods for > >copying data. > > Two. . . .
No, three. Ctrl-C/Ctrl-V is different from SHIFT-CLICK copying, and then there's Clip Files. That's three. > . . . Clip files are like drag-and-drop, for all practical purposes. > Just clefs are different, AFAIK. I don't know why they changed one and > not the other. What is the purpose of clip files? > >I began with the question: > > > >First off, why is copying so incredibly complicated? > > Part of it has to do with inherent restrictions in the clipboard > (system's copy and paste). I suppose you already know what does and > doesn't copy when you control c, control v. Not much to do about that, > but I take advantage of it to decide what I want copied. This is the > first of two copying methods. I don't understand why the default should be to copy selectively, and not to copy everything unless you've told it to omit some things. *That* is confusing. > This is the second. Drag and drop copies pretty much everything, but > most people are using this to copy between staves, or to later bars in > the same piece, and so don't want things like clefs to copy (at least > not between staves!). . . Finale should be able to know if where it's copying from and where to and then be intelligent about what it copies. It should copy all clef changes if the source and target clefs for the systems are the same, don't you think? > > . . I remember early on this was an issue, and they > changed the default to go along with what most people were using this > for. Shift-clicking to copy large sections and then alt-shift click to > accomplish the same thing is just an easier way to accomplish > drag-and-drop on large sections. > > Clip files do pretty much the same thing, but between files, because > the system's clipboard won't copy things that drag and drop will copy. > That's all. What are you talking about the "system's" clipboard for? It's not involved -- it's Finale's use of the clipboard. I have no other applications that don't do just fine with copying all of their own metadata, even between separate instances of the same application (let alone between different documnets within a single instance of the application). If you're blaning the underlying OS's for the problem, then I think you're letting Coda off too lightly. Just as with EPS, other applications manage it, so Finale could, too. > >> Hm, I just tried it. Apparently it only copies clef CHANGES; it > >> won't put the first part of the passage in the default clef of the > >> staff you copied from, but rather in the default clef of the staff > >> you are copying TO. Keys were copied, though. But yes, as I always > >> knew, it ignored my staff lists in the target file for > >> measure-attached expressions. > > > >It's all completely messed up, confusing and, basically, useless. > > > >Everything, absolutely everything, with no exceptions, should be > >copied unless I've asked for selective copying, It's one thing to > >copy from one staff to another within a file (where you might very > >well *not* want clef changes copied, though it seems to me that if > >the destination staff has the same clef as the source staff that > >you'd usually want clef changes copied), but entirely another copying > >from one file to another. > > The starting clef is part of the staff attributes. Clef CHANGES are > copied as normally as you would expect in a clip file, though they > seem to be the exception when you drag-and-drop. But, as I said, this > was a conscious decision based on user input. You can set clefs (and > everythign you want!) to copy, under Mass Edit>Copy Measure Items> set > to ALL, and leave it that way if you want. Except I tried that, and it still didn't copy the clef changes. Actually, it copied mid-measure clef changes, but not the ones that happened on the bar line. Is there any justification for *that*? > >But it seems to me that the whole mechanism is hopelessly > >complicated. > > > >I can't figure out how to do something very simple, just copying data > >from one file to another. > > Funny, I have the same rants about Microsoft Word. I can't figure out > the formatting, or how it gets copied when I duplicate things, to save > my life. Yet it is the dominant word-processing program on the planet. > AppleWorks does everything I ask it to do flawlessly, but noone can > read the files I send them. Well, I don't know about Word on the Mac, but on Windows the formatting copies pretty much exactly in all instances, unless you are doing deleting section breaks or paragraph marks. In that case, things can change, but that's because formatting for blocks are stored in the terminator for that block. Once you understand that small piece of information, it because quite easy to work with. But I've been working with Word almost as long as I've been working with Finale. Of course, there's a difference: I understand how Word works. I still don't understand many very basic things about Finale. > >Add to that the fact that the source of the problem was hidden data > >of some sort in the instrument definitions, and it's pretty clear > >that Finale is, overall, a complete mess. > > I don't know anything about the instrument definitions. If it is a > bug, report it. I don't know if it's a bug or not. I don't even know what causes it. I'm also not interested in having a 15-message back and forth with WinSupport to try to get them to acknowledge that it's a bug. My experience with the blank notation spacing bug really soured me on WinSupport -- they were unwilling to acknowledge that there was something wrong. -- David W. Fenton http://www.bway.net/~dfenton David Fenton Associates http://www.bway.net/~dfassoc _______________________________________________ Finale mailing list [EMAIL PROTECTED] http://lists.shsu.edu/mailman/listinfo/finale
