|
|
| MakeMusic Forum > Public Forums > Finale - Windows - FORUM HAS MOVED! > Mass copy/insert | Forum Quick Jump
|
 |
Tyler
Registered Member
      
Date Joined Mar 2001
Total Posts : 3586
| Posted 12/27/2003 4:15 PM (GMT -6) |   | |
Wow, I'm getting behind. Unless I'm mistaken, Diane, you are copying within a document, not between documents, right? Don't bother using the edit menu commands for copying and replacing/inserting (or their shortcuts, ctrl+c/ctrl+v). Just highlight the source material and ctrl+shift+click the first measure of the target. That does the same thing as dragging, and it will fix all the problems you are having with expressions. The confusion here all along has been that some people are trying to copy between documents, and when doing that the ctrl+shift+click option doesn't exist. Only drag copying or ctrl+shift+click copying pays any attention to the settings you have selected in the MassEdit menu. If you instead need to insert the material within the same document, choose "copy and insert" from the MassEdit menu before using ctrl+shift+click.
"so here is my question: what is the simplest, most direct way to take a section of music from one place in a document and insert it into another place in the same document (or another open one) - so that the newly inserted section looks exactly like the original source? Is this possible?"
No, not in one step. This is where the limitations are coming into play, and this is an area we'd like to address. The full version of TGTools can help some with this as it offers plugins for copying expressions between documents, but ultimately this is just something we need to improve in Finale.
"Inconsistencies like this can’t be justified on the basis that they are useful in some circumstances. They make the program too hard to use — and to document. In your example, if you were copying one clef to another, you would expect to have to make some adjustment afterwards, or to make a setting so that the clef didn’t copy. "
I don't think people would expect to have to make a change for this. From the thousands of files I saw while working in tech support, I'm confident that a huge majority of the time it is not desired for the clefs to be copied. Because it is so skewed, I think it makes more sense to have people who are trying to include clefs do one special extra step. It's better to inconvenience 5 people than 95.
Regarding lyrics: "There is a simple solution to this — the ability to save and invoke named sets of parameters (in this case, the items to be copied). "
I'm not sure we're thinking of the same issue. When lyrics are copied with the edit menu commands, they are duplicated in the Edit Lyrics dialog box. This is convenient because it allows you to change the words in one place afterwards while not changing them in the other. Copying with ctrl+shift+click does not duplicate them. This can be convenient when you want to be able to change the words in one place and have it affect both. Consolodating the two copying methods could lose this very important functionality if not done well. I'm not sure off-hand what the ideal solution would be.
"The bass clarinet to bassoon argument is a valid one but there are other scenarios as well. In my experience, when copying between files (using either insert or replace entries) I'm almost always transfering between like instruments so I would want any clef changes to come along. When copying within a file (ctrl-shift-click or drag-and-drop) I'm most likely copying from one instrument to another so I usually DON'T want the clefs."
There may be a level of intelligence that can be applied to when clefs will be copied and when they won't. I'm not sure that copying between files is normally between like-instruments. It may be. For my own work it actually isn't because I'm mixing compositional ideas, and the ensembles aren't generally the same.
"The real problem is that when using the clipboard, it is not possible under any circumstances to copy clef changes that occur at the start of a measure. "
Yes, I think this is actually the cause of 95% of this thread. Copying within a document is pretty decent as long as the normal method is used (ctrl+shift+clicking). Since that's not possible between documents, we run into these limitations.
"I feel that for the sake of consistency, clef changes ought to be included by default under all circumstances unless the user deselects them. "
I'm pretty sure we have to go the other way. Make clefs not copied by default (unless copying onto a later place of the same staff??), but open up the functionality for the edit menu commands to pay attention to what's selected in the MassEdit menu. If we changed it to copying clefs in all circumstances, I'm absolutely positive we'd hear hundreds if not thousands of complaints. You also have to keep the other versions of our software in mind which don't have access to these filtering options. If PrintMusic and NotePad users couldn't copy between instruments without changing the clef every single time, they'd go insane. I understand the argument for wanting "Copy Everything" to include clefs, but if not doing so is correct 95% of the time, that should be the default.
"I think it's time to take a serious look at what the real world (we users) has (have?) to say."
This is not the issue. The issue is time. We have a limited amount of time to develop the features that will be the most helpful and be the most desired. We certainly have no problem understanding what things in the program are confusing or how to improve them.
Post Edited (Tyler of MakeMusic) : 12/27/2003 9:16:26 PM GMT | | Back to Top | |
|
Mike Dallwitz
Registered Member
Date Joined Apr 2003
Total Posts : 60
| Posted 12/28/2003 12:56 AM (GMT -6) | |
Tyler said:
‘From the thousands of files I saw while working in tech support, I'm confident that a huge majority of the time it is not desired for the clefs to be copied. Because it is so skewed, I think it makes more sense to have people who are trying to include clefs do one special extra step. It's better to inconvenience 5 people than 95.’
In the end, everyone is inconvenienced if the program is inconsistent and illogical. Instead of introducing ad hoc inconsistencies to cater for what are thought to be the most common requirements, it would be better to provide logical, consistent, intuitive, and convenient mechanisms for meeting those requirements.
Mike (quoted by Tyler) said:
‘There is a simple solution to this — the ability to save and invoke named sets of parameters (in this case, the items to be copied).’
Tyler said:
‘I'm not sure we're thinking of the same issue. When lyrics are copied with the edit menu commands, they are duplicated in the Edit Lyrics dialog box. This is convenient because it allows you to change the words in one place afterwards while not changing them in the other. Copying with ctrl+shift+click does not duplicate them. This can be convenient when you want to be able to change the words in one place and have it affect both. Consolidating the two copying methods could lose this very important functionality if not done well. I'm not sure off-hand what the ideal solution would be.’
My comment was not intended to address the lyrics issue as such. You said: ‘The second biggest thing that comes to mind is lyrics. This probably could be handled with a setting, but it would be a slight reduction in functionality (speed).’ My suggestion was aimed at the second sentence. I presume you meant that it would be a nuisance to have to change the settings depending on the desired result. Having named sets of settings would make this easier.
As for the lyrics themselves, the functionality provided by the different copying methods is another excellent example of how not to design a program. No one could ever guess that these methods provide this functionality. And being able to guess what to do is an important consideration in making a program easy to learn and use.
I seldom use lyrics, and have never tried to copy them along with the music. But here’s a suggestion for an intuitive mechanism: a checkbox in the ‘Copy Measure Items’ dialog (or elsewhere if this is not appropriate), labeled ‘Duplicate lyrics’.
By the way, although we may not always agree with Tyler’s views, I’m sure we greatly appreciate his contributions to this forum, which are often above and beyond the call of duty.
Mike Dallwitz | | Back to Top | |
|
Mike Dallwitz
Registered Member
Date Joined Apr 2003
Total Posts : 60
| Posted 12/28/2003 6:50 AM (GMT -6) | |
Mike Dallwitz said:
(4) Inserting via the clipboard doesn’t preserve the ‘Show On’ settings of measure expressions — they are reset to ‘Show On All Staves’...
Peter Thomsen said:
Imagine that your measure expression is set to display "in staff 7 only" and that you copy it to a document containing only 2 staves.
If the staff assignment - "in staff 7 only" - were transferred to the new document, the expression wouldn't display at all in the new document. You wouldn't be able to edit the expression (and e. g. set it to display in staff 2).
Expressions assigned to a single staff are not assigned to a staff number, but to ‘This Staff Only’. There is no reason why these expressions couldn’t remain attached to the measures from that staff, wherever they are copied, and with all copying methods. This already happens with smart shapes that are assigned to measures (for all copying methods), and with measure expressions that are copied by dragging within a file. Expressions assigned to ‘All Staves’ present no problems. The difficult case is expressions assigned to ‘Staff List’, but it should not be too difficult to devise a better method of handling this than the present one.
Peter Thomsen said:
Finale's recent behavior (= resetting the expression to "show on all staves") at least allows you to access the expression and edit its assignment.
Yes, this is better than nothing. But when copying between files, it happens only with ‘copy to clipboard and insert’. It is a rigmarole if you want to ‘copy and replace’ between files.
Mike Dallwitz | | Back to Top | |
|
HOMR
Handsome gent
Date Joined Aug 2001
Total Posts : 227
| Posted 12/28/2003 8:07 AM (GMT -6) | | Okay, this is getting annoying. I don't post a lot around here, but I gotta jump in. Time to point out the obvious.
Dick said...
Sorry Tyler, but I think you are missing the point here. The point is that if I say "copy everything" that is exactly what I want to do.
Dick, you’re missing the point. When most people go to copy, they don’t go look at that setting first… they just do it. I want finale to do its best to do what I intend, not be completely anally literal and screw me into more work because of semantics. Do I want it to copy clefs? Not most of the time. Do I want it to copy all measure attributes? No, hardly ever… Do I want it to copy staff attributes? Never. Should the command be changed to “Copy Everything EXCEPT clefs, not all measure attributes (but some of them!), and leave the staff attributes alone..”? Hmmm… Or how about, “Copy MOST things.” Yeah, as soon as I read that I’m going to be confused and paranoid and have to go look at the manual to figure out what the hell that means. So the program is 97% of the time guessing correctly about what I want to copy without me going to some menu to correct the problems…. yeah, that’s worth complaining about. And hell, rather than debate the reasons Tyler gave for why the default behavior should be as it is, let’s just call the guy evil – because naturally, how would he have any idea about the needs and interests of the majority of finale users after only working in technical support for years and talking with thousands of us. A question for you… how many new users to finale do you think know to go look at the mass edit menu when trying to copy and paste? How many casual users? Why on earth should they have to?
Zuill said...
Ditto. Tyler, if you are speaking as a representative of Make Music, it's time you inform them that they need to fess up and admit the problems. Dick is right. We are far too intelligent to accept your chatter. Enough is enough. I hope others on this forum speak up.
Zuill, I’m speaking up. I’m tired of your chatter. All of your responses to Tyler have seemed like challenges, and now you’re being outright insulting. Your very first post on this thread called the mass edit tool worthless, and that’s clearly a ridiculous assessment. What do you think these quotes from Tyler meant?
Tyler said...
Copying within a document is pretty decent as long as the normal method is used (ctrl+shift+clicking). Since that's not possible between documents, we run into these limitations.
This is where the limitations are coming into play, and this is an area we'd like to address.
I agree that it can make it unintuitive to those learning the program, and we'd like to improve this.
The 5th item does sound like a bug. Generally speaking these limitations are problematic when copying between files but don't pose as much of a problem when copying within a file
Please feel free to send your question in to our technical support department along with a request for the documentation to be updated with an actual discussion of this subject.
No, that's not design, that's a bug.
I’m not sure how many more times Tyler should have to admit that there are flaws in the design before you accept it. He’s told us that Coda wants to fix it. Are you calling him a liar? If so, on what grounds? | | Back to Top | |
|
Mike Dallwitz
Registered Member
Date Joined Apr 2003
Total Posts : 60
| Posted 12/28/2003 9:23 AM (GMT -6) | | HOMR said:
I want finale to do its best to do what I intend.
I’d rather it did what I intend. But as that’s probably different from what other users intend, I’d settle for it working logically and consistently.
Do I want it to copy clefs? Not most of the time.
Yes, almost always.
Do I want it to copy all measure attributes? No, hardly ever.
Yes, always.
Should the command be changed to … “Copy MOST things.” Yeah, as soon as I read that I’m going to be confused and paranoid and have to go look at the manual to figure out what the hell that means.
As soon as I read ‘Copy Everything’, and found out that it didn’t copy everything, I got confused and paranoid and had to go look at the manual to figure out what the hell that meant. And the manual didn’t tell me. So I had to spend hours, if not days, trying to figure it out.
| | Back to Top | |
|
Tyler
Registered Member
Date Joined Mar 2001
Total Posts : 3586
| Posted 12/28/2003 1:43 PM (GMT -6) | | "What about when I am copying to another document, which is what I was doing? Is there hope for measure expressions being copied to same staves they were in originally, or do you say, it is just better to use note expressions?"
No, I'm sorry there isn't a simple way to do this. I apologize, I misunderstood that you were talking about copying between documents. Note expressions can be a good option, but of course if you are extracting parts and need staff lists, this won't be very effective.
"I’d rather it did what I intend. But as that’s probably different from what other users intend, I’d settle for it working logically and consistently."
There's more to keep in mind in terms of consistency here. First of all, I'd like to clarify that we're dealing with only one issue here, and that's whether the basic, out-of-the-box mass mover copy (ctrl+shift+click) should or should not include clefs in absolutely every situation. We aren't thinking about copying between documents or anything to do with the Edit menu copying methods (those are a given, they need improvement). When a user first picks up the program and goes to copy music, the first action is never to go look at the MassEdit menu first and make a selection. So we are talking about what should happen by default. Finale is consistent in this sense - it always copies and leaves the same things. With something as common as copying, it's very easy to remember that when I copy from a treble clef part to a bass clef part, the treble clef staff attribute of the line does not come along. In talking with tens of thousands of people about Finale, never once did any of them complain that they couldn't remember they wouldn't have to change the clef back after copying the music. What can easily be forgotten is that when copying music that contains clef changes, the clef changes are not going to come along unless one takes a second to check an option for their inclusion. In this situation, the usual desire is to have the clefs be included. So the question then becomes, is it better to design the program to include clefs in these situations and thus add a level of seeming inconsistency? Actually it might be, and maybe we should consider that option as well (although this gets sticky quickly when you think about copying measures following but not including a clef change). Another thing to keep in mind in terms of consistency: there are hundreds of thousands of users of our products who are used to the programs understanding they don't want clefs copied when going from one staff type to another. Changing this so that all clefs are copied all the time would make this operation inconsistent with their expectations. And it would render copying music nearly useless in a program like NotePad which lacks a clef tool - unless we designed it to behave differently in NotePad which would in turn introduce another inconsistency. And an inconsistency that to a huge majority of our customers offers no benefit and causes inconvenience is a problem for us as a company.
There has to be a trade-off between complete consistency and ease-of-use/speed. Take note duration selection for example. There have been a few programs that have used 1 to represent a whole note, 2 a half, 4 a quarter, 8 an eighth note, etc. Intuitive. But in use it doesn't turn out to be very convenient, particularly for people not using a number pad. Because the operation of putting in notes is such a common one, we opted to favor a more convenient system at the cost of losing a little bit of learning ease. But it has saved a ton of time for Finale users at the cost of a slightly more painful first 30 minutes with Speedy Entry.
"Do I want it to copy clefs? Not most of the time.
Yes, almost always."
We're not seeing the opinions of a good sampling of our users on this forum. I suggest that an overwhelming percentage of them would vote for the current behavior as opposed to the clefs copying by default in all situations. And I say that based on my unique perspective of having worked with tens of thousands of them. We keep records of the feature requests. Before this forum thread I don't recall receiving this request.
"Do I want it to copy all measure attributes? No, hardly ever.
Yes, always."
The first one that comes to mind that isn't copied is "Begin a New Staff System." In my music that would definitely be a hindrance to have that copied, so I'm personally glad that Finale doesn't bring that one. It's tough for me to comment on customer files I've seen since this feature isn't widely used.
"As soon as I read ‘Copy Everything’, and found out that it didn’t copy everything, I got confused and paranoid and had to go look at the manual to figure out what the hell that meant. And the manual didn’t tell me. So I had to spend hours, if not days, trying to figure it out."
But aren't there some things you wouldn't expect it to copy, even though it says "everything?" Things like the number of staff lines a staff has, or the tablature notation from a tab staff when going to a normal staff? In every situation I can think of, when copying from a normal staff to a tab staff, the user doesn't intend for the notes to be copied over but for them to be converted to numbers. Here the program guesses correctly about what's wanted virtually 100% of the time. In the case of converting treble clef notation to bass clef, it's probably something like 95% of the time. I understand your frustration with the manual, and if it wasn't clear enough, please send a request to winsupport so they can forward it to the documentation editor. I do agree that better explanation could help with this, but I don't think that changing the program so that it is less convenient for almost everyone is the answer.
"Under HOMR's system of logic I guess the next time I order a burger with everything at Wendy's, I should expect that sweet young thing behind the counter to know that I actually want everything but onions."
But one couldn't argue that 95% of the time everything but onions is desirable. You rely on Finale guessing what you want in many, many situations. You rely on it knowing that you want a measure of sixteenths to have more space than a measure of quarters. You are probably happy that it guesses you want a treble clef for your trumpets and a bass clef for your trombones. There are tons of instances where Finale makes appropriate guesses to save you time. And I promise you that every indication we've received is that the fact that clefs don't copy in every instance by default has on the whole saved people time.
"1. There are problems that have been around for a long time, and instead of defending the problems, I was asking that he encourage Make Music to let us know what they are so that we don't keep asking about why it doesn't seem to work properly."
I haven't been defending problems. There is one issue here that I believe I have a unique perspective on because of my position, and I am arguing that the proposed change would be extremely unpopular and problematic. As for the actual problems with Edit menu copying, I agreed that there should be a discussion of this in the manual and I suggested that you send a request for this into winsupport. | | Back to Top | |
|
Mike Dallwitz
Registered Member
Date Joined Apr 2003
Total Posts : 60
| Posted 12/28/2003 6:13 PM (GMT -6) | | Tyler said:
But aren't there some things you wouldn't expect it to copy, even though it says "everything?" Things like the number of staff lines a staff has, or the tablature notation from a tab staff when going to a normal staff?
Tyler, I don’t think anyone has a problem with that. If you order a burger with everything, you don’t expect to get ice cream on it. The confusing thing about ‘Copy Everything’ is that it is linked to ‘Copy Entry Items’ and ‘Copy Measure Items’, and doesn’t have the same effect as checking everything in the those options.
Here’s a possible solution, which wouldn’t alter the default behaviour of copying. Change ‘Copy Everything’ to ‘Copy Default Items’, and, at program startup, have those items checked in ‘Copy Entry Items’ and ‘Copy Measure Items’.
I think that this is a relatively minor issue, because you can easily do what you want once you understand how it works. My major concerns are those that I listed as points 1-5 in my post above. The deficiencies and bugs that relate to copying between files are particularly troublesome, as there are no easy workarounds. (I think that you agree with me on that.) Also, I doubt the wisdom of obtaining functionality via the inconsistent behaviour of ‘insert’ vs ‘replace’, and ‘copy via dragging’ vs ‘copy via clipboard’. (I think that you disagree with me on that.)
Mike Dallwitz | | Back to Top | |
|
Tyler
Registered Member
Date Joined Mar 2001
Total Posts : 3586
| Posted 12/28/2003 6:51 PM (GMT -6) | | | "Here’s a possible solution, which wouldn’t alter the default behaviour of copying. Change ‘Copy Everything’ to ‘Copy Default Items’, and, at program startup, have those items checked in ‘Copy Entry Items’ and ‘Copy Measure Items’."
I'm not opposed to finding a more suitable name for "copy everything," as long as it doesn't create unnecessary confusion. Something like "Copy Default Items" or "Standard Copy" might work - please feel free to write winsupport with that suggestion so it can be tossed around. I'm not sure it should have any effect on what's selected in the Copy Entry Items and Copy Measure Items boxes though. My reason is that when a person goes to those boxes, the most common reason is to select a single element as opposed to turning off a single element. It would in effect be adding an extra step for most visits to those boxes. What about "Copy Default Items" along with proper documentation for what's not default?
"The deficiencies and bugs that relate to copying between files are particularly troublesome, as there are no easy workarounds. (I think that you agree with me on that.)"
Yes, I completely agree that changes are needed in the program to deal with these issues.
"Also, I doubt the wisdom of obtaining functionality via the inconsistent behaviour of ‘insert’ vs ‘replace’, and ‘copy via dragging’ vs ‘copy via clipboard’. (I think that you disagree with me on that.)"
Guess I'm not an effective communicator. I don't disagree with this. My concern is that because there is current functionality that exists because of the poor design, we have to be careful in any redesigning we do. There are plenty of Finale users who have become accustomed to working with the quirks to achieve good results with a lot of speed, and in making the system more consistent and intuitive we could make some of those people angry. Ideally all of that functionality would have been originally created in a sound system. Obviously features can't disappear going from one version of Finale to the next, at least not without a suitable replacement. Don't get me wrong - I can't think of any convenience in the current system that couldn't be approximated well enough in a new design to more than make up for what would have to be lost. I was just noting that it wouldn't be quite so simple as making the two methods behave identically to one-another and leaving it at that. | | Back to Top | |
|
Jim Coull
Registered Member
Date Joined Jun 1999
Total Posts : 2723
| Posted 12/28/2003 8:32 PM (GMT -6) | | Speaking of inconsistent behavior, does anyone else have a problem with the apply articulation dialog box not selecting the "notes within range" radio button when a range of notes is selected? This has been around for quite some time and is an inconsistency within Finale. All the other dialogs that contain options under radio buttons that I have come across automatically select the appropriate radio button when a range is selected except the apply articulation dialog. This inconsistency has burned me several times on my latest project because I can't seem to remember that Finale does not react the same here as it does elsewhere. I can usually fix things with an undo, but it is still a pain.
To see what I am talking about, do the following: (Finale 2003a and earlier; I'm on a Mac and don't have 2004 yet)
Select Mass Edit and select a range of measures
Go to Change Note Durations and click on a range of durations (the "change selected" radio button is automatically selected)
Select Mass Edit and select a range of measures
Go to Apply Articulations and select a range of durations (the radio button for "all notes" stays selected)
It seems that there are a few other places where this happens, but I can't bring them to my aging mind right now.
I am not a programmer, but this problem would seem to require an uncomplicated fix. I reported this bug ("feature?") way back in the dark ages and it still seems to stick with the program. It could be that I am the only person that this bugs, but if consistency within the program is a goal for the programmers, this seems like an ideal place to start. Of course, that's just my always humble opinion.
Jim Coull
PS I am fine with the way the copy features ("bugs?") currently work, but could easily adapt to the suggestions others have made. However, IWBNI MakeMusic would include a separate README file that documents changes in the program that affect tools, features, etc. that have been left unchanged for years. Tyler is correct in his statement that many of us have adapted to the quirks of the program and would have a rough time of it if many or all of them were changed without proper documentation. And speaking as one of the old guys, I would much prefer to have a relatively short text document that I could print out and keep by the computer that shows those changes instead of having to wade through the online docs everytime something works differently that it has for the past several years. | | Back to Top | |
| 45 posts in this thread.
Viewing Page : 1 2 |
| Forum Information | Currently it is Tuesday, December 19, 2023 6:51 PM (GMT -6)
There are a total of 403,820 posts in 58,165 threads.
In the last 3 days there were 0 new threads and 0 reply posts. View Active Threads
|
Forum powered by dotNetBB v2.42EC SP3
dotNetBB © 2000-2023 |
|
|