Copying all layout information to parts

I just ran into this. I thought the layout information would be copied into a newly created track. I understand that layout changes in one part or in the main score don't affect existing parts, but why not for a new part?

I seem to spend hours correcting and re-correcting slurs. Of course, if I were in the engraving business, I'd go through it once for the main score and once for the parts and be done. But no, I am a composer who often tweaks his scores and so I get to do this over and over.

I've heard mention of a new layout engine in MuseScore 3. If the slurs came out nicely by default, the problem with parts would be less of an issue.

I know it would be difficult, but the ideal implementation of linked parts would be to allow any and all settings to be inherited at the user's discretion; both the global settings (Style > General, Style > Text, etc.) and the specific ones (stem directions, offsets, etc.). I realize the GUI for this would be challenge.

There is very little chance that specific manual adjustments you make to slurs in the score will relate to the parts at all. Consider, the part might be transposed so we might have totally different notes; also different number of measures per line so the note spacing may be totally different, and indeed, the slurs might break between systems at different places. Plus the position of other elements like system text etc might create conflicts in the parts that don't exist in the score or vice versa. Basically, if we lioterally kept the same manual adjustments in the parts, it would probably look worse than the default in most cases.

But indeed, better default layout of slurs would be a very nice thing.

There is very little chance that specific manual adjustments you make to slurs in the score will relate to the parts at all. Consider, the part might be transposed so we might have totally different notes; also different number of measures per line so the note spacing may be totally different, and indeed, the slurs might break between systems at different places. Plus the position of other elements like system text etc might create conflicts in the parts that don't exist in the score or vice versa. Basically, if we literally kept the same manual adjustments in the parts, it would probably look worse than the default in most cases.

Marc, much as I respect you and your opinions, I have to strongly disagree in this case. You say "very little chance" and "...look worse ... in most cases." In the scores I have worked with and, in fact, the score that inspired my comment, I find exactly the opposite to be true—creating a part using the default layout creates a much worse layout.

Do you have any evidence for your claims? Here's a test: take any score in which layout adjustments were made. Create the parts for the instruments. Now, create separate files for each instrument and copy the music for each instrument to its corresponding file. In each case, count the number of fixes you have to make to correct layout problems.

I just tried this test for the part for which I was tearing out my hair. For the instrument copied to a new file, I had one case where a slur ran into the staff below it. That was my only correction on an 11 page score. When creating a new part, on the other hand, I have dozens of corrections to make, all painfully familiar because, in fact, the adjustment I made in the main score is actually exactly the same one I'm going to make in the part.

If your argument were correct, the you could make it as well any time someone adjusted the space between staves or increased or decreased the stretch or added a line or page break. If there is "little chance" that the score will come out right and if it's likely to "look worse", why not just reset all the layout in modified areas back to default? The reality is that I often add breaks and change stretch without having to re-do all my adjustments (maybe there's one or two).

I would like to see a score in which the number of corrections needed after resetting everything to default offsets are fewer than the number needed if the current offset are copied. And if you have to search hard to find such as score, you've lost the argument anyway.

How would you know the default is much worse? You've never seen MsueScore attempt to reproduce the manual adjustments from the score into the parts. And for good reason - as I said, there is almost zero chance it could possibly work. Consider the most basic aspect of this - there is almost zero chance the actual *length* of the slur will be the same in both score and parts, because the measures will almost always be formatted differently. The measures in the score are normally wider by defaut, because they also need to be spaced according to the notes in the other parts. Although sometimes you might deliberaltey insert line breaks into the parts for readability, which would make the part measures wider. So if we reproduced the manually adjusted slur precisely, your slurs would all be too long or too short in the parts. And correspondingly, all your careful adjustments would just look wrong. You really wouldn't want manual adjustments copied literally - it would end up looking practically randpom, because the *literal same adjustments* will almost never be correct.

You say you need to make "exactly" the same adjustment in part, but my point is, it's not "exact" at all. It's completely relative to the individual spacing requirements. It might seem "similar" in some abstract way, but the *specifics* would virtually never work.

OK, we must be talking about two different things, because nothing you say makes sense relative to what I'm talking about.

Let's take a slur, as this is my number 1 problem. My assumption was that a slur is stored based on anchoring start and end positions, with offsets for each of those positions. When I stretch a measure (in any of various ways), what I see is that the slur stretches to accommodate the shifts in the starting/ending anchor positions. The offsets, however, appear to remain the same.

How would you know the default is much worse? You've never seen MuseScore attempt to reproduce the manual adjustments from the score into the parts.

Hmmm... I thought I said I had emulated this by creating a part manually (i.e. copying to a new file with a single instrument) and then verified that the default is much worse. I can format the new file to look exactly like the part—same staff spacing, same scaling, etc. I just leave the actual music unchanged and then count how many fixes each needs.

So let's see if I can understand. I create a measure with two notes and a slur between them. I add an offset of 1sp to the start of the slur. I then somehow cause the measure to stretch, increasing the distance between the two notes. My assumption is that the data defining the slur has not changed—the display system looks at the slur definition and the actual location of the anchoring notes and draws the slur properly. Perhaps you cache some of the display calculations for speed—that's fine. When a part is created, what seems to happen is that the slur anchors are kept but the offsets are reset. What I'd like is for the offsets to be retained. If there are some cached display calculations, they have to be re-done anyway.

Obviously, if MuseScore insists on creating a part by copying the exact length of the slur, it would be a problem, but I find it difficult to believe that my only choices are an exact copy (including length) or a completely reset copy.

It's possible that your comments are based on a broader view, for example, copying all the style information (everything in Style > General and Style > Text). I'm not convinced that would be a horrible thing, but 99% of the corrections I made are to slurs and dynamics. I'd be happy if the elements in the music would be copied with their individual values (the values that appear in the inspector which are not dependent on the length of the measure).

Hoping for some clarity. I must be missing something. If you still don't get what I'm saying, I may need to look at the code to see what's going on.

OK, I get how you say that copying manually would be similar to having the info copied to the parts automatically. But in fact that *doesn't* produce good results in a great many cases.

All I can say is that while sure in some very simple cases it might happen to work, in many more complicated real world cases it would be non-sensical. I guess it might be subjective to say whether it looks worse than no adjustment, but in any case, starting from a good predictable set of defaults usually makes for a simpler workflow.

The simplest example is one in which the line break happens in different places. How could the same adjustments possibly make sense? Or consider an adjustment in which the goal is to avoid something on the next staff - like a slur beneath the flute staff adjusted to avoid a note on a ledger line above the clarinet staff. On the flute part, that clarinet part isn't even present, so how could that adjustment possibly be relevant? Also, remember it isn't just overall measure width that changes from score to part; it's often the note spacing *within* the measure that changes, due to notes on other staves. So merely stretching a measure won't show the same effect.

The simplest example is one in which the line break happens in different places. How could the same adjustments possibly make sense?

And yet I often add line and page breaks as a last step to getting a part ready and I rarely see many problems. This is my reality vs. your speculation. The problems caused by bad slurs far outnumbers the number of problems coming from line/page breaks.

But in fact that *doesn't* produce good results in a great many cases.

Sorry, I see no facts, just speculation. I've tried doing my separate file experiment on a number of other parts—so far, the results are much better in every case. I have yet to see a case where retaining the slur/dynamic/etc offsets is worse than resetting them to default.

The scale of the slur problem is so large, that I would happily live with any of the other drawbacks. It would save me hours of work.

I thought I'd pull a score out of the MuseScore repository and put up a comparison of the number of corrections needed in each case, but it looks like a lot of people don't bother with slurs or phrasings. This might explain why the whining is limited. :-)

You don't have to believe me. Give it an honest try with a good score with a lot of slurs/phrasing. Count the corrections you would make to the score in each case. I suspect you will be hard pressed to find anything worse than the current approach used for parts. Until you do the comparison, you are just guessing.

A score with little phrasing won't present as much of a problem. Also, the problem is exacerbated by the abysmal handling of slurs—when that goes away, the problem will diminish (although my vote would be to continue retaining any offsets when creating a part).

As I said, it may or may not literally look worse - that's subjective - but if it doesn't look perfect, then linking the properties won't make sense. And even *starting* with something other than basic defaults introduces an extra step of needing to reset to get a clean slate before further adjusting. Well, you don't "need" to, but to me it would be the first step in my workflow.

I'm not near my computer right now, but if you really still need to see examples I'll try to post when I can. Really though it isn't hard at all to find cases where keeping the same adjustments just doesn't work. I'm not guessing, I have much experience with this and played around more just today to make sure things hadn't somehow improved. They haven't. I don't want to quibble about which of two unacceptable layouts is worse than which - do you at least accept it often is not acceptable to simply link the adjustments? That further adjustments will often still be necessary?

I have to agree with Marc on this one. Scores and parts are very different documents, and serve very different functions. There is no way I would either expect or accept the same layout in a part that I would require in a score.

Let me clarify something: while I wouldn't be opposed to a system where some or all of the style/layout settings were linked from the main score to the parts, I recognize that not only would it be a difficult interface to program (the GUI would need all sorts of tri-state toggles: on/off/inherit) and linking individual elements would be really confusing without a system that could highlight which elements were linked—and even then, it might lead to unwitting errors.

So let's drop that. Let's limit the discussion to the initial creation of the part. And even further, let's limit to style information in specific elements (notes, slurs, dynamics) and not any of the global style or page layout settings.

Marc, you made statements such as "very little chance" and "...look worse ... in most cases." These statements may have been referring to an approach in which settings were linked. However, you also seem opposed to the more limited approach of just copying (not linking) the current set of adjustments.

Let me propose further that this be an option—those who like to start with all adjustments at default values can create the parts this way. Those (like me) who have scores where copying the adjustments would save them a lot of time could do so.

So now it's just an argument as to why I shouldn't be allowed to have the workflow I want—one that I know will save me hours of time. (Of course, someone would need to code that option—and that someone might be me—but I want to make sure that the rulers of the MuseScore kingdom wouldn't actively oppose adding such an option).

Let's consider my current composition: a work for flute, clarinet, cello and piano. The piano score actually contains all the instruments, with the flute, clarinet and cello staves in smaller scale. I also have a piano reduction in the main score. So when I create the piano part, I actually want to include all the instruments except the piano reduction. This not only means correcting layout errors in four instruments, it means that if I edit the main score (yes, I often tweak scores after having musicians play through the parts), I have to recheck the piano score, remembering where I made the changes.

Because the piano score looks so much like the main score, there will be almost no collision problems due to removing the piano reduction part. If I could create a part by copying the adjustments in the main score, I would probably only need to check line breaks. If I modified the main score, it would probably be faster to delete the piano score and regenerate it—something I wouldn't even try in the current workflow.

I tried simulating what the piano reduction would look like if it could be generated by retaining the adjustments. I had only one slur collision I had to fix.

My new simulation procedure involves copying the score to a new file. In the original score, generate the parts and save the style information for one of those parts. In the copied score, apply the style information and save the file again. Then, using this file as a base, create simulated parts by removing the instruments that aren't used.

I have been told that this will lead me to total layout disaster. Let's check. The following two images are screen captures of the Flute and Piano parts. The top version is the simulation of what the part would look like if the layout information were retained. The bottom version is the version generated by using File > Parts...

I put a fat, red asterisk every place where I would need to make a layout fix in either version (I only included the first three pages of the piano score). The clear winners are the versions that keep layout information. Contrary to claims here, the version that retains the adjustments has few problems, despite a change of staff scale (in the flute part), changes to measure widths, note alignments, etc.

By the way, I just noticed I missed a big slur problem on the first measure of the second page of the piano score. The top version shows the correct slurring, so add another asterisk on the bottom. Plus I missed a text collision on measure 1 of the piano score (the problem is only in the normally generated part, of course).

I always seem to miss some edit problems, another reason why I'd prefer to make them all in one place and once, rather than over and over.

Looking at these results, I am completely mystified as to why there would be any opposition to this option, particularly if it were the user's choice.

The simulated approach is actually so much faster that I'm considering adopting it until such time as the option for copying layout adjustments is provided (if it ever is) or a better layout engine appears and the need for tweaking vanishes.

All I can say if my experience is very different. When I copy/paste manually adjusted slurs, they often look bad enough that they might as well have not had the adjustments applied - I have to remove them and start over. Apparently your experience differs, I can accept that.

Anyhow, the real solution here is to have better default slur layout. If, after re-evaluating this with real world use cases with that improved layout in place, we can then revisit the decision over whether manual adjustments make sense to preserve at that point.

So now it's just an argument as to why I shouldn't be allowed to have the workflow I want—one that I know will save me hours of time.

I am a very strong supporter of that general point of view--give the users as much control as possible--but as Marc has pointed out on a number of occasions, there are times/issues when that added control would require an additional level of coding complexity that is too high to be practical except for very common use cases. Since I do not write code, I don't know if this is one of those instances; you do write code so perhaps you could evaluate this feature request on that basis.

In general, I think more people want to be able to un-link the parts--or at least certain elements in them--from the score than want to add elements to the list of those which are already linked. I know I want that ability on occasion, and I know Marc has discussed the possibility of looking at that seriously for future versions.

Anyway, as stated, I support your 'right' to prefer your own workflow, but I do find it quite unusual, to say the least. Mine follows the standard process used by publishers of any type of printed work. The key difference between your method and the standard one is that we do not export parts, or attempt to refine or correct the layout of the score until the music content is finalised and no further major changes to it are envisioned.

There is absolutely no point in making fine corrections such as slur shaping and element offset when you know there will be futher revisions to the content which will force you to do those fine corrections all over again. Just ignore it. Professional musicians hired by a composer to test-play a piece can work from uncorrected proofs, and in addition they will see things with their fresh eyes that you might miss and mark them for you. You can then add those corrections to the corrections you've marked in the score, correct the score file in MuseScore, and save it under a new revision number. Then you can delete the parts exported from the earlier revision so that you can export new parts from the latest revision.

At that point, you can start the formatting, make-up, and final refinement process, going through the score once, and through each part once. Yes, you will need to print proofs for two additional rounds of proofreading before publishing the final edition, but those final proof rounds rarely if ever turn up anything so major that it would require a wholesale remake of the score and parts. At that point, you'll be correcting a single pitch that slipped, or fixing a misspelling in a staff text or lyric.

I'm an amateur composer. So far, no one is paying me for anything nor do any of the musicians I work with ask for money.

I am not an engraver, and the workflow suitable for an engraver is not the workflow I use. Pieces I considered finished have been re-opened as I received feedback from new players. As I do this for fun, I can choose whatever workflow suits me.

In the particular composition that I posted, the full score (with piano reduction) is so close to the piano score, that it seems insane to repeat all the edits over again. And the piano reduction can be converted to a piano part with one or two tweaks—if the adjustments are preserved. The other instruments also come across with almost no problems—far, far fewer than when the adjustments are reset.

As I have no idea when a better layout engine might appear, I will probably go with my workaround. I lose the benefit of linked parts, but the time savings and reduced hair pulling are worth it.

I may also look at cloning my own version of 2.0.3 and seeing if it's reasonably easy to change the way it works. Even if the code changes turned out to be simple to implement and maintain, I don't get the sense the MuseScore team would support it.

The OP seems to be strangely missing from this discussion. He seemed to want the same feature, so there's at least two of us! :-)

By the way, in one of my long messages, I dropped all requests for linking anything. I just want the initial adjustments copied.

It should actually be pretty easy to copy manual adjustments. Give it a shot. I'm just one developer, and while I'm skeptical based on my own experience, I'm willing to be convinced.

I thought it might be easy. I'll get on IRC and ask how to clone 2.0.3 (why that version? Because I want to use it and it seems a safer place to start to get a version I can use for "production" work). I can then branch the master release and put any changes for anyone who wants to give it a try.

I am not an engraver, and the workflow suitable for an engraver is not the workflow I use. Pieces I considered finished have been re-opened as I received feedback from new players. As I do this for fun, I can choose whatever workflow suits me.

Yes, certainly, and while it's hard for me to understand why someone would want to work like that, I support your right to choose your own methods of work. ;o)

As for reopening a 'finished' score (in your case, based upon feedback from new players), this is a common occurance in the world of textbooks, standard 'backlist' musical editions, and anything else with a long publication life. Publishers often produce revised editions of previously published works, but when an editor takes on such a task, he knows in advance that most (if not all) of the layout and graphic work done for the first edition will have to be done over again. As a matter of fact, new editions of a previously published work are often redesigned to give them a new 'look', since graphic fashions change over time and the publishing industry is not immune to the vagaries of the taste of the marketplace. It's part of the publishing game. You might be comforted by the thought that in the old days, the typography had to be done over from scratch, but today with digital technology we can at least re-use the basic 'keystrokes' for the content, instead of having to re-do the input.

BTW, in case you weren't clear on this point, a 'second printing' is not the same thing as a 'second edition.' A second (or third, or fourth...) printing will include corrections of 'typos' noticed since the first printing was published, but it will not contain major revisions. That's the distinction.

There are advantages in using the tried-and-true procedures used by professional publishers, even for an amateur composer or author. Consider that those procedures are the result of several hundred years of hard experience. ;o)

I totally get the need to revise existing work, whether based on feedback from a rehearsal or the desire to re-orchestra it or whatever. I don't understand, however, the relevance of this. After all, the parts are *already generated* at that point. So even if you decide to change some slurs, or some notes covered by a slur, since the parts are already generated, any facility to automatically copy manual adjustments to parts *at the moment of generation* would be irrelevant here. Since the parts are already generated, you'd still need to make the adjustment to both the score and the part (actually, though, I seldom bother in the score unless it's for publication - not worth the effort).

My approach so far has been to revise the main score and then re-edit every one of the darn parts. In the frenzy of creativity, I may not clearly remember all the places I've touched, so I have to look at the entire thing. I always seem to miss some of the darn slurs or fail to reposition a poorly-placed crescendo.

When I can copy the adjustments with the part (as tested by my workarounds), it can be faster to just delete the part and re-generate. When the entire piano reduction shows up with only a single collision, it's a no-brainer. So far, other parts are also needing only a few or no changes.

When the adjustments are transferred I find myself focusing on line breaks and major collisions--a lot of the problems I would be looking with standard parts are simply not an issue.

@Recorder485: Thanks to taking the time to explain all this, but it's all irrelevant. I am not a publisher of textbooks, music or anything else. The workflow needed by a publisher is not a workflow I want to adopt.

Interesting story: Along with being a professional software engineer, I am also a professional graphic designer. When I worked on the program for a major conference by a Fortune 500 company, the process I inherited was one in which every session change required a manual re-layout of the entire document. As a programmer, I was able to add code and rules to Adobe InDesign so that I could feed the raw session data to the tool and have it generate a fully laid out document.

The net result was that there was less hesitation to make needed revisions or to try to batch them in large blocks. Everyone in the team could look at an up-to-date online version of the document at any time.

If you want to live with the procedures developed over hundreds of years of not having computers, be my guest.

Well, that is interesting. My company did mostly book, magazine, and advertising, but we also did corporate work for outfits like GAF and Deloitte, Haskins, and Sells so we dealt with corporate style sheets regularly, and I know what you mean about 'inheriting' something that doesn't work the way you'd prefer. I was never a real programmer (and those machines were hardware programmed, anyway) but if there's anything I hate, its repetetive, useless work. So I taught myself to bully the hardware into doing things the manufacturer claimed were undoable. What we would today call a 'workaround', IOW.

I recall one very complex weekly schedule for GAF that, if it had had to be produced in paste-up, would have taken many hours to assemble, and this had to be re-done every month. So I 'wrote' what I guess could be considered a sort of algorithm, consisting of typographic formatting mixed in with sequential tab and reverse lead commands that would force the type into flush-left/top-aligned/row-balanced multiple columns and create scotch rules built up out of stacks of 12-point underscores set on 0.5-point leading. Probably took me two days to do it the first time and I burned through an entire 150-foot roll of 8" photopaper printing trial after trial until I got it right...but after that I could plug in the content changes each month and print out the whole table ready to lay onto a mechanical in one piece, all in about 30 minutes. Of course, nobody but me could make any sense out of the 'code soup' on the screen when that template was called up off the 8" floppy; the manufacturer stated flatly that it was impossible for their machine to produce that and my lead typographer said it made her head explode just to look at it.

As to me living happily with the old ways of work, I do so only when I see no better alternative on the horizon, and for now, for music publishing, I don't (although I remain hopeful). Page makeup affects and to an extent controls everything in a printed document, and it is even more critical in music than it is in books or magazines. In books, we can 'cheat' by shortening facing pages by one line (or, rarely, two) to avoid orphans; in magazines we can sometimes get that critical extra line into a column by fudging the height of a photo. Those things are relatively easy to program as there aren't that many rules and even fewer exception cases. (And in fact I did 'program' page makeup for books--more or less the same way as described above--long before real software programs existed.)

But in music, there are more rules and a good many more exceptions to each, because a single musical edition (for a full symphony orchestra) might be addressed to as many as 25 or 30 different types of 'readers' and they don't all have, by any stretch of the imagination, the same needs. Thus the rules for scores are very different to those for parts, and the rules for flute parts are different to those for cello parts. I would be quite happy if someone (you, perhaps?) could create a UI that would give me control of all the parameters needed to generate scores and parts in the various different formats and layouts required. But that's a very tall order, it seems to me. Just to give you an idea, here is a condensed description of our house style rules.

Scores should have smaller scaling than parts. Unlike instrumental players, conductors have the score on a desk directly in front of them, so they can read smaller staves and notes. They also have a free hand to turn pages whenever they need to, so layout of pages is less finicky in scores than in parts. All that said, it is highly desireable to keep the number of page turns to a minimum. In a large orchestral score, there will often be only one system per page. If the scaling is set too big, each page might contain only three or four measures, requiring the conductor to turn pages much too often.

The primary goal with parts is to make the players' lives as easy as possible, and the two most important ways to do that are to make the parts readable and to ensure that page turns don't require the player to stop playing. Most instrumentalists can rarely play with one hand while turning pages; and most need to have the music stand 24-30 inches away from their eyes. For cellists, bassists, percussionists, and a few others, the average distance is over 3 feet. All this needs to be taken into account in designing and laying out the parts.

Our standard scaling for scores is 1.275; for parts it is 1.625 and for cello, bass, and percussion parts it is 1.750.

In scores, staff and system spacing is adjusted to make the best use of the page size chosen; a standard size score can contain as many as 15 staves in three systems on a page but no more. For scores too large to fit a full system on standard 8.5x11, we print on larger paper rather than shrink the music down to the point where it becomes unreadable. Conductors' desks can handle these oversized books; that is what they are designed for.

In parts, staff spacing is set to put no more than 11 staves on a single page; 10 is preferred but we will squeeze in the extra staff if necessary to accomplish good page turns.

So, to really nail this you would have to include rules for fingering for all the different instruments so the page-makup algorithm would 'know' when a player could free up a hand for a page turn (ie: a soprano or tenor recorder player can turn a page while playing an "A"; an alto or bass recorder player cannot). You'd also have to include a list of which parts need to be scaled slightly larger than others because the players' music stands are too far away. And for your own particular complaint, slurs and hairpins (which I, as a producer of Baroque music, don't deal with very often), you'd want to define exactly how you want them placed under all conditions of stretch, scaling, and musical font choice, and for that, I'm guessing you'd need to define offset in relative terms rather than fixed units.

Finally, I think it would be a good idea to create some sort of 'lock-pitches' or 'lock-notes' command, so that a note cannot be inadvertently altered by a slip of the mouse or a careless keystroke while reaching for the copy-stand where you've got your marked-up corrections. Something along the lines of an 'Are you sure?' popup would be great.

If you could do all of that, and everything else involved which I haven't mentioned or thought of yet, it would then be possible to make all revisions to a piece in the score itself, and then regenerate new revised parts automatically, and dump the old ones. I would love that, but, as I say, it sounds like a pretty tall order.

@Recorder485: Hi! Thanks for a fascinating write-up. I got one useful tip—some musicians may need a large scale because the music will be further from them. I hadn't thought about that.

As I am not a music publisher, I only have to worry that the parts are "good enough" for the musicians I work with. I do have one musician with poor vision, so I scale his part larger. As I have been writing a lot for wind quintet, I can usually find a few empty measures near the end of a page to insert a page break. My pieces are short enough, however, that the musicians just tape them together and don't bother with page turns.

I can make all these adjustments very quickly. Finding and correcting bad slurs, however, takes up a lot of time. I also need to fix various other collisions. The musicians can forgive a slur not done to the highest engraving standards, but a slur that obscures a note is obnoxious.

Now let's look at my latest piece, my first ensemble work with piano. The main score looks just like the piano score except without the piano reduction. Removing the piano reduction has little effect on the length of most measures. The staff sizes and spacing are exactly the same. There would be very little need of fix-ups if I could copy the adjustments to the parts—so few, in fact, that it would be easier to delete and re-create the part after any major edits than to try to fix it.

Now, let's look at the piano reduction. It has most of the notes in the other staves, so it pretty much controls the measure size. Since I set the grand staff size and spacing the same for the main score and the piano reduction, the line breaks are exactly the same and most of the collision problems will be the same. There is a possibility of a collision from one grand staff to the next, but I found only one actual case.

None of this may meet the highest engraving standards, but it's good enough for me and my musicians. In fact, by copying adjustments made in the main score, I'm less likely to miss a fix to a part. My eyes get a little fuzzy after doing a lot of proof-reading and I'm always finding something I missed earlier.

If I were ever to try to get my music published, I would let the pros take care of the editing, engraving and proof-reading. It's not a business I want to be in.

My eyes get a little fuzzy after doing a lot of proof-reading and I'm always finding something I missed earlier.

Heh, heh. Welcome to the club. That happens to all of us, and not just because the eyes get fuzzy. The brain stops registering what the eyes actually do see and starts reporting what it expects to see. This is especially problematic when the person doing the proofreading is the same person who did the input.

Big firms always have separate proofreading departments (or large lists of dependable free-lancers), and they work (or used to, anyway) in teams of two: one person reading aloud, spelling out all questionable words and speaking every item of punctuation; the other person listening while following along in a second copy of the galleys. After 10 or 15 minutes, they swap. This whole process is done several times, too: once for the first galleys, a second time for the 'corrected' galleys, and then again for the page proofs. Today with automated page make-up and end-to-end digital handling of the content, many publishers skip the galley stage and proofread from page mock-ups as soon as the author's 'MS' (read: 'WP file') has been formatted to the book designer's specifications.

But 'typos' still find their way into final printed copies. That's just the way it is. ;o)

But I do have a question for you. Well, two, actually.

1. As a composer, why do you feel the need for a 'piano score' that is distinct from the 'main score?' This is unusual. If the keyboard player will also be directing (as continuo/harpsichord players do routinely), the normal procedure is for him to play from the full score, which will have either a figured bass line on the bottom staff, or a full keyboard realisation written by a specialist editor or the composer himself. OTOH, a keyboard player who is not charged with conducting the ensemble will often prefer having just his own part, because there are less pages to turn and it's easier to concentrate on what he has to play if that's all that's facing him.

2. As a programmer, do you have any comments on how much of these diverse layout requirements could be reliably automated? I am presuming here that the tool would be structured to prompt the user for a decision when it encountered something insoluable because all available solutions broke at least one rule.

@Recorder485: My wife is a technical writer. She tells me they sometimes read things backwards to find errors.

Answers to your questions:

1. While I have played the piano (passably) for almost 50 years, that makes me no expert on music, music terminology, engraving, etc. (as I am sure is glaringly obvious), so I probably used the wrong term. This piece is the first ensemble work I've written that includes a piano. I would probably have handed the piano player just the piano part, but when I looked for examples of sheet music that included the piano, almost every example I found seemed to include the other instruments (in small scale) in the piano part, so that's what I did and that's what I was calling a "piano score". I have a specific set of musicians in mind for this piece, and if they take it on, I would be happy to defer to the piano player as to what form she would like the piano part. There are some fast and furious passages that the piano player would much prefer not to have to turn a page on, but then, that's true with piano music in general and the reason why there are page turners and, now, electronic scores that can be paged with a foot pedal.

2. As a programmer, I believe that all musical layout requirements can be reliably automated. But it's difficult. You start with a group of master engravers and master programmers. The programmers then have to get the engravers to provide objective criteria for every engraving decision they make. The elements in a publisher's style guide are probably the easiest to capture. You need efficient collision detection and this is an area in which a lot of work has already been done. You feed a lot of scores in and compare the computer's layout to that of the professional human engravers. Where the computer chooses a poorer solution, the programmers have to extract from the engravers how they arrived at their solution (Sample dialog: "Well, it looks prettier this way." "Why does it look prettier?" "I don't know, it's just more balanced." "How do you determine that it's balanced?" "If you squint, the areas of black sort of blend into a nice even gray." "What shade of gray is 'nice'?" Etc.) If the programmers can turn subjective criteria into objective ones, they can program them.

Another issue to consider is: can you make it efficient? No one wants to wait for 5 minutes after entering a note before the program is ready to proceed. If you can't make it efficient, one solution could be to have a separate pass that batch-beautifies the entire score. It t would still beat doing it by hand.

And is there just one right answer? Not really, so a perfect layout system would also have to accommodate allowing users to guide the layout (perhaps even with a rule like "flute parts need a larger scale" because the flute player has vision problems).

I have no idea what approach the MuseScore developers will use for the enhanced layout features of MuseScore 3.0. My expectations are low--it's a really tough problem. My suspicion is that they will add some sort of collision avoidance, but I have no inside knowledge. Ask Marc.

Indeed, some forms of collision avoidance, but also some optimizations that allow us to get tighter spacing in places where we currently try *too* hard to avoid collisions. See https://musescore.org/en/user/101731/blog/2016/05/01/musescore-3.0-unde… for more information.

I'm not really sure how far it will go either, but slur layout is actually pretty much #1 on my list of things I'd like to see improved as well. Basically, we only look at the end point right now, and completely ignore the interior notes. The new data structures and algorithms that are already in place would in theory give us a starting point for smarter slurs, but we don't have a handle on the math involved in figuring out how to break a slur into the box-like "shapes" that we need in order to hook into the new layout code.

My guess is doing something where we automatically adjust the height of the slur to avoid interior notes would be relatively easy once we work that out, but I still anticipate people would sometimes want to override this to instead adjust the endpoints (moving them further from the notes) to avoi too-curved slurs. It's definitely an art, and I don't see us really mastering that any time soon.

Just off the cuff a little about my experience with a score and parts. This one is for orchestra (not composed by myself): 6 Parts for wind and brass, 5 for the usual strings. I am just done "beautifying" the parts. Having this thread in mind I was very surprised how FEW slurs there were that needed adjusting. It works better than this thread might make you believe. I know this depends on the music. But even so I was surprised.

As a second thought: I do think that maybe some of the adjustments to formatting would be nice to see automatically copied into the parts. I am thinking of slurs and stem direction.

In other words: Markings for dynamics, tempo, articulation, voltas and most others would be default in the parts, but slurs and stem direction would follow the score. You will say that this does not guarantee correct slurs in 100% of cases because the stretch of the slurred group may change very considerably from score to part.

However the bulk of slur-adjustments comes in convex groups of notes where the default slur gets too close to the "protruding" notes in the middle of the group. In this case the distance that the middle of the slur needs to "travel" to get out of the way depends little or not at all on the stretch. The chance is pretty good that the slur will look acceptable when it looks ok in the score. Stem directions are included in this because sometimes in slurred beamed groups that are close to the middle staff line the easiest way to fix a slur is to break the rule and turn the stems around converting convex to concave. And in groups with no beam it might still be more readable to turn all stems under the same beam in the same direction rather than to follow the stem direction rule closely (this is case by case).

Another thing nice thing to have would be a sort of asymmetry: Corrections to the score appear also in the parts but not vice versa. So that one can add bowings or fingerings (or even extra dynamics for clarity) to parts without having them appear in the score where they mainly just clutter up an already complex appearance and need to be set to invisible.

Actually, with my music, a lot of the corrections I make to dynamics (and other elements in the Lines palette) and any text in the main score tend to translate well into the part. I usually don't alter the articulations.

As for the slur adjustments, if you modify the slur by increasing the curvature so that it clears the offending notes in the middle of the phrase, you will have a slur that is actually very sensitive to the stretch.

Here's an example. We start with a passage that's MuseScore handles poorly:

Here are two types of corrections. In the first measure, we correct by only moving the center of the slur. The slurs created this way are ugly to begin with. In the second measure, we correct by moving the entire slur, as is, up or down enough to clear the problem notes.

Now let's scrunch down the measures (as might happen when music in a score gets turned into a part):

The first measure looks even worse now. The second set may not win any beauty contests, but at least the music is readable. In measure 2, the slur for triplet number 3 comes closer to the middle note in the version with less stretch than in the version with more. With a little bit of fiddling, I was able to redraw so it looked decent in compressed and expanded forms. The fourth triplet may be as good as it can be (and still be stretch-independent).

Again, no claims that these would pass any engraver's muster.

Actually, the usual way difficult slurs like that are handled is to flip the slur to the beam-side of the triplet.

The last three triplets had the slur flipped by selecting it and then hitting 'x', and then I moved them down enough to clear the '3' using the edit handle.

I don't see why the program can't do that automatically. I would guess it's probably just an oversight.

I prefer version 2 from post #28 or else a mix of of version 1 and 2: 50% shift of the whole slur and 50% curvature (measured in number of times I hit the arrow keys) often looks quite good, though for this extreme example there is no perfect solution. If you look through printed music you'll easily find lots of examples for both of these solutions, especially the second (shifting the whole slur away from the note group)

Two reasons I don't like the slur on the beam side:
- It looks like the triplet bracket in older music (now illegal but not so long ago very widespread).
- I find it harder to read quickly (I am thinking sight reading). One expects slurs on the side of the heads, not the stems (exception: very long slurs).

@Recorder485: I use the flip method as well, when it looks decent. I don't like the look in this case.

The reason the program doesn't do this automatically is not an oversight. It's a difficult feature to implement and something that will be worked on in 3.0. The current algorithm, as Marc mentioned, looks only at the first and last notes in determining how to draw the slur. It takes a lot of extra work to calculate a slur that avoids all the notes or even the "3" on the beam side.

@azumbrunn: The trouble with increasing the curvature by any amount is that it reduces the odds that the slur will survive any layout changes.

This is not a problem if you are an engraver, but it is a problem if you are a composer like me who tweaks his music a lot and maybe not always in the most efficient order. Example: you get through cleaning up all slurs and then realize you have an awkward page turn. Fix the page turn and you may have to fix the slurs once more--but flatter curves are more likely to survive.

Re: flipping slurs on tuplets - as mentioned, it makes sense only "sometimes". So indeed it's not an oversight that we don't do all the fancy checking and calculation that would be required to determine when it makes sense; as mentioned before, the algorithm is actually based entirely on the first and last note. Taking the interior notes into account would be nice indeed, but it opens a whole new can of worms that thus far no one has been up for tackling.

Okay, thanks. Understood.

Since this mostly seems to be about slurs, should we rename this to "Implement collision avoidance for slurs"?

By the way, here's a glimpse inside how LilyPond thinks about it: http://lilypond.org/doc/v2.18/Documentation/essay/automated-engraving

The OP says "A particular case is the collision that occurs between dynamics and hairpins requiring almost systematic adjustment of the hairpins and dynamics whenever the start (or sometimes end) point is the same and there is no suitable alternative anchor for either." so, no, this is not just about slurs and it would not be appropriate to rename this topic.

In my own case, slurs are about 90% of the problem and dynamics are about 9% (OK, that's what it feels like!).

Perfect layout would probably solve the problem for the OP. It would be for me. Boy, I have to try LilyPond again—I'm not sure what the problem was last time I tried it, but if it could do a "good enough" job, I'd use it for the final printout.

There is already a separate issue for dynamics / hairpins - see #81121: Dynamics and Hairpins overlap. Also a separate issues already exists for better slur layout - see #9334: Slur sometimes placed poorly.

But in any case, there are really *three* totally spearate issues here:

1) better automatic layout for slurs
2) better automatic layout for cases where a dynamic and hairpin are on same note
3) a way to have manual adjustments in score propagate to parts

I think everyone agrees 1) would be good, although it's quite complex. 2) is also a no-brainer I think (although really, I think most of the cases where people are seeing issues it is because they have not really added the markings in the msot apppropriate way to begin with). 2) has a pending PR but it probably should be reworked to use the new "shape" facility.

This particular issue - the one this thread is about - is #3, and it's the more contention one, as there are definitely different schools of thought on the extent to which manual adjustments *should* be linked between score and parts. No doubt having a way to get that effect for the people who want it would be good, but it is equally important to preserve the ability to keep them independent for the people who prefer that. So it's related to the whole issue of how to control what is linked and what isn't - a much bigger issue, really, than copying manual adjustments.

A few comments on #2: dynamics and hairpins on same note. I never do this. My dynamics (and hairpin) problems are:

• Collisions with notes.
• Dynamic and hairpin too close when placed on adjacent notes.
• Aligning hairpin with dynamic when one but not the other has to be adjusted.
• Dynamics to close to bar line

A lot of the fixes in the main score also work in the part.

Layout is layout. If you improve layout to where no adjustments are needed, the parts won't need them either. If #2 said "better automatic layout for dynamics and hairpins", I would be happier as fixing the specific case cited wouldn't help my scores at all.

Probably worth starting a new forum thread to discuss your concerns here. Some of these I think I understand, others I don't. Some are already improved for 3.0, others could potentially be. And some of them seem like cases where you definitely *don't* want adjustments shared between score and parts (eg, the concern about dynamics too close to dynamics is virtually never an issue in the part, and any adjustment made to the score to avoid the through-the-system barline would look wrong in the part).

I've been working with a copy of MuseScore 2.0.3 and have made a small revision for "spanners' (slurs, hairpins, other lines). This version is just an experiment and only for my use at the moment. Here's an example that compares the current Part extraction results to the modified result. None of this is for intended for maximum engraving goodness nor am I claiming that this is close to prime time (I'm not saving anything that I would be upset to find corrupted later).

MASTER SCORE

NORMAL PART CREATION RESULTS

MODIFIED PART CREATION RESULTS

I don't quite understand why it should be a mistake to put a dynamic marking and a hairpin on the same note. There are plenty of examples, printed and handwritten, where you find something like a dynamic marking on a note followed at the narrowest possible distance by a hairpin, i.e. the hairpin starts closer to this note than to the following. Clearly this means that this note is already part of the crescendo or diminuendo and it makes musical (if not software-) sense to anchor it there. Look for examples in voices that move in large values.
Practically it makes little difference--you'll adjust the hairpin either way in these circumstances (only maybe for the way forward with MS 3 it may matter what the standard input procedure is thought to be).

Probably worth starting a new forum thread to discuss your concerns here. Some of these I think I understand, others I don't. Some are already improved for 3.0, others could potentially be. And some of them seem like cases where you definitely *don't* want adjustments shared between score and parts (eg, the concern about dynamics too close to dynamics is virtually never an issue in the part, and any adjustment made to the score to avoid the through-the-system barline would look wrong in the part).

On my TO DO list is a pile of MuseScore bugs to report (some, maybe most, may already be on the issues list).

I keep being surprised how different our experiences are. One possible reason is my terminology: I tend to use dynamics to mean all dynamic markings, whether "p" or hairpins.

So when you say "dynamics too close to dynamics is virtually never an issue in the part", you may not realize I am talking about a hairpin followed or preceded by a "dynamic". The problem is worse as the notes in question get closer together. In a large score, alignment with notes in other parts may keep notes more separated, so actually the problem could be worse in the part than in the main score. I created a little example and the problem occurred (and looked identical) in the score and part:

You are right about "any adjustment made to the score to avoid the through-the-system barline would look wrong in the part" unless the part has more than one instrument in it, in which case retaining the adjustment might be useful.

Update: I just looked at the issue for dynamics and hairpins overlap. Maybe the fix for that will also fix problems when hairpin/dynamics are placed on adjacent notes?

Re: placing dynamics and hairpins on same note: yes, sometimes that makes sense. In "most" cases, though, the hairpin would start with the *next* note, and end with the note before.

Again, though, further discussion of additional specific collision cases is best done in the forum with spacific examples attached. but for the record, it was a typo when I said "dynamics too clsoe to dynamics" is not normally an issue in parts - I meant "dynamics too clsoe to barlines". This is normally only an issue in scores, where barlines are drawn through the staves and hence horizontal offset might be needed.

Hmmm... Note stems aren't independent? Sounds like a bug for the very reason you point out. You said "some layout, such as..." Are there other elements you've had a problem with? Those should be fixed as well.

After working with Sibelius, it's clear (to me) that the only reasonable solution (for the user) is to have automatic layout. But for that to work, all layout needs to be independent.

Default note stems are independent, only manual overrides are not. So as long as you don't override defaults without giving consideration to how it will affect transposition, all should be fine. I produce transposed parts from concert scores quite often and have no difficulties at all.

Better automatic layout is being worked on for 3.0 already, as is the ability to have multiple parts from a single staff.

As I said "multiple parts from a single staff" is being worked on for 3.0. In case it wasn't clear, this means parts from different voices. It is at least partially implemented and in place already in the nightly builds.

@TinyTrouble: You say you haven't seen a feature request for combining parts, but actually there's a thread I started which goes into long and boring details as to how this could be done (see https://musescore.org/en/node/107781). Anyone writing orchestral music needs this and I don't know of any software that handles the problem dynamically (perhaps Dorico?)

Sibelius does a pretty good job of a batch merge, including adding the labels 1, 2 and a2 (or variations of the same). This gets you only part way, though, and is not dynamic.

If you think this is a simple problem or that it can be handled by just dealing with voices, you should first do a detailed read of my post.

The odds that MuseScore 3 (or 4 or 5) will do a "proper" dynamic merge of two instruments in an orchestral score is, in my opinion, about 0. "Proper" means that it meets the standards that I am familiar with—Marc may know of some changes in standards. Perhaps a merge of parts as two voices is now acceptable, but I haven't run into any examples.

Probably best then to download a nightly build, try out the new voice-to-parts feature that is already in place, and give your feedback on that in the Technology Preview forum. Best to keep this particular thread focused on the issue at hand, which is about something else.

Interesting to know you are deliberately wanting to have two different transpositions of the same staff. Could you please comment in #62416: Changes to staff transposition (and other properties) not reflected in linked parts? We were considering fixing this by simply forcing all linked staves to have the same transposition, but maybe a more flexible system would really be preferred.

Right now, though, there are a few different issues being discussed here, and it is going to be confusing to keep everything straight, especially as some issues get fixed but others remain.

Let's keep the discussion in this thread focused on the original issue, which is what happens when you first generate linked parts: what information should be copied to the parts and what should start out back at default settings.

There is a totally separate issue of which adjustments made *after* linked parts are generated should be automatically duplicated in both score and parts. Although these might be related in some conceptual way, they are really two different questions, and it is quite possible to address them independently. Best to discuss this separate issue in #25248: Add ability to explicitly break links between linked staves/parts or perhaps in a thread in the Technology Preview forum, such as https://musescore.org/en/node/73841.

Is this what you had in mind? #232536: Allow different transposing instruments on one staff

Relates to #311174: [EPIC] UI/UX issues and suggestions

For fully working solution see my comment in:
https://musescore.org/en/node/316640
It is done by manual editing of mscx file, but its work and save me hours of (duplicate) work