Making parts

• Sep 4, 2019 - 12:20

I have written something for Flute, Clarinet and Piano trio, and now comes the time to make the parts. I read the manual - it says: "Parts and score are "linked", which means that any change to the content in one will affect the other, but changes to the layout will not." I understand the idea; I guess that "linked" (no real specific meaning) means that there is only one data representation of the "notes" (content), and that changing notes in either the score or the part affects both. But I think it would help if the manual was explicit about this.

But then I need to understand exactly what is "notes" and what is "layout". Is there a complete definition somewhere? (There must be some programmer notes, at least.) In particular, the following all seem to be a bit borderline:

  • Cues in the instrument parts
  • Enharmonic spellings (I'm showing the Bb clarinet in concert pitch on the piano score)
  • 8va signs (apparently you are not supposed to use them for flutes
  • Bits of text that should appear in one place but not the other

Grateful for suggestions. In the end I realise I may have to separate the parts, and then look after copying any minor changes.

Comments

• Sep 4, 2019 - 13:41

Cues, ottavas and texts are all content and as such linked between score and part.
Concert-pitch or not, multi measure rests, positions, visibility, system breaks, page format and orientation is layout and as such not linked.

Reply

• Sep 4, 2019 - 18:32

In general, someting you physically see in the score is has to exist in the score and the part as separate elements, but most elements are linked so certain changes to one affect the other. By changes, I mean, the settings you make in the Inspector, manual adjustments you using cursor keys or dragging, etc. There is a master list of properties that controls whether changes to that property are linked or not.

Layout mostly refers to the position of the element on the page. So dragging the element, changing its offset with the Inspector, etc. These changes are not linked. But changes that affect the "meaning" of the element usually are. So, changing the text of chord symbol, or the pitch of a note. Enharmonic spelling is normally linked, but there is a special command Ctrl+J to change the enharmonic spelling in the current view only.

Cues are notes, so the important properties of the note - duration, pitch - are linked. But stuff like its overrides to size or color or visiblity are not. So cues exist in both score and parts, but if you don't want to see them in the score, they can be made invisible (someday we may provide a facility to do this automatically). Text you want in a score but not the part or vice versa can be handled similarly - it will be present in both, but you can make visible in on one.

Reply

• Sep 5, 2019 - 10:25

Thanks for the replies, both of which are very helpful, even though neither addresses my question, which was: How do I find out exactly which aspects of the score are regarded as "content" and which as "layout". Marc managed to repeat my question, sort of: " There is a master list of properties that controls whether changes to that property are linked or not." Well, where is it?

But it looks as though "visibility" (which is diagnostic of kludging) is the key, and I think I can see how to deal with my current score. Two other points:

About the enharmonic spellings: the handbook says of Ctrl/J: "This alters the spelling only in the current mode." How would I know this is something to do with parts? And I was reading the other day about using 8va in the score for woodwinds, but not in the parts. So really that should be separable.

More basically, if the internal representation keeps two copies, one for the score and one for the part, why not "link" in one direction only. Changes to the score affect the part (as they naturally should), but then any specific changes in the part do not affect the score. There may be some obvious problem I haven't thought of, but I wonder...

Reply

• Sep 6, 2019 - 19:58

Thanks! That answers my question, though the format is rather opaque. It should be rather easy to produce a human-readable list: each entry identifies the property code and also the dialog box label, so given a list of the dialog boxes and their constituent entries in the list:

foreach (dialog box) {
　show dialog box name
　foreach (property)
　　show(name and linked/not)
}

I count 62 "linked" and 189 not, so most properties are actually independent. I think the handbook could be clearer and more explicit, but I've forgotten the procedure for suggesting things like this.

Reply

• Sep 5, 2019 - 12:40

Actually, Ctrl+J is not about parts specifically, it's about transposition (concert pitch in vs off).

As for layout vs content, I thought I explained that. Layout has to do with the position, since, and other aspects of the physical appearance. It's not a hard and fast distinction, which is why we can't provide a precise definition.

The list of what is linked or not is related but not the set question, some things that couldnbe considered layout might still be linked or some content might not. That layout/content distinction is just one consideration. As for how to know what is linked, easiest is to just try it. We try to do what makes the most sense most the time so people don't actually have to think about this too hard. So we don't document it anymore than we document then precise algorithm for determining measure widths.

Reply

• Sep 6, 2019 - 20:06

Well, I think this is an abysmal approach. We won't tell users too much, because they prefer to wade around, guessing. Musescore is supposed to be open: that is in the end its biggest virtue. Being open means that anyone using it can suggest improvements. Perhaps what you mean by not "documenting" the algorithm for bar widths is that ultimately some of it is buried in code, not that that is a good approach either.

Sorry, I can't understand the first sentence of the second paragraph.

Reply

• Sep 6, 2019 - 20:17

Well, itis open, you are welcome to look at the source to learn how it works that day. But we reserve the right to continuously make improvements. And having to stop and document every last detail of all this would mean never getting anything done.

So, I don't see what's so problematic here. Like I said, for both linking of properties and about a thousand other things in MuseScore (like, learning the default stem direction rule, or the algorithm for placing accidentals, or the value of default space between a note and its dot, or default spelling of the notes between F and G when entered via MIDI in the key of Bb, or ...), just try it and see for yourself. Or are you volunteering to write up documentation for all of those things, and promising to update that documentation for each and release in perpetuity?

Regarding the sentence you said you didn't understand - typo, "set" should have been "same".

Reply

• Sep 12, 2019 - 16:06

The other examples you give are all things where there is instant feedback. I remember talking about the "spelling" algorithm, and I think incidentally that it has become a lot easier to make F-flats for example. But I jiggle the note up and down until I get what I want. With making parts I have to decide when or whether to export the parts and edit separately. And for this every little extra I understand about what is being "linked" or not really helps.
I made my parts (flute and clarinet); because of the piano solo in the middle, I used "hide empty staves" on the Fl and Cl, but had to add kludge notes (invisible) to prevent separate bits of each from being hidden. That's OK, but then the ("linked") parts won't work, because the kludge notes prevent multibar rests from working. Of course I've ended up making a few small edits in the parts, which I either have to add manually, or reexport and tidy up. Generally I am very impressed with the improved default layout in ver. 3 so I might go for reexport.
I don't really understand your presumably rhetorical question about perpetuity. I just think that a neat list generated from the "linked" property would be useful.

Reply

• Sep 12, 2019 - 16:22

Maybe if you posted a score and a real world example of something that you are having trouble figuring out, we could assist better. Generally speaking, there should hard;y ever be reaosns not to use linked parts, nor should there be cases where it would not be trivially simple to see if a change linked or not.

As for my comment about perpetuity, the point is, the list is ever-changing to better reflect the realities of how people use the software and the consensus that develops over time, and there are all sorts of cases not covered by it, because not everything that is linked is captured by the idea of a "property". For those who are curious enough to ask here, but not quite curious to simply try for themselves and see, there is the source code. Or, someone could choose to take the trouble to document this and pledge to update it in perpetuity, as I said.

Reply

• Sep 12, 2019 - 17:03

I am talking about a real-world example. I hesitate to post the score, because it is not yet even road-tested; and in any case I thought I already explained why I cannot use the linked parts. I believe I have "figured it out", but I might have figured it out wrong, in which case please correct me. And anyway the logical process of deciding not to use linked parts is more direct than getting you to work out from the score why I made the decisions I did. So again:

I have written a trio, Flute, Clarinet, and Piano; I have the piano score (full score, using "small staff" for Fl and Cl). I think it is easiest to read with minimal staff layout changes (I have suffered Rutter/Oxford scores), so I want always three instruments, except for a 16-bar piano solo in the middle. So I use "hide empty staves" on the Fl and Cl. But I do not want to hide Fl or Cl separately, and each has 4-8 bar rests. So I had to add kludge notes (invisible) to prevent them from being hidden. But on the parts I want to use multibar rests, and the kludge notes prevent these from working. Therefore I have to export the parts. I am not complaining about this; as I said, relayout is amazingly simple, but on the other hand I cannot see that my case is exceptional. But I will add a (rather simple) feature request which would solve this particular case.

You say that it should be "trivial" to check if a change is linked. Well, of course, if every time you make any edit you just go off and look at the relevant part. You think this is a plausible strategy? (Sure, one leaves part generation to the end, so there are only minor changes, but even so...) One thing I noticed from a cursory glance at the source Jo-Jo supplied was that the 'text' on a glissando is not linked. IIUC, this means that if I decide after making the parts to add "gliss." after all, I have to remember that it won't yet be on the harp part. (And Jo-Jo also says that not everything that is marked as "linked" even gets copied to the part; I can't imagine what that could mean.)

Again, of course I understand that the list of "linked/not" properties changes, which is why I wrote a pseudocode program to generate a current version. If I had spent three months working on Musescore code I would hope to be able to turn it into real code in around 20 minutes, but I haven't.

Reply

• Sep 12, 2019 - 18:14

You mentioned a reason why you believe you might not be able to use linked parts, but without actually working with the score, it's difficult for us to advise on alternatives. Not sure why "road-testing" your score should be a prerequisite to our being able to help. For example, most likely an extra staff with no real notes on it but just to use as a placeholder for the passages where you don't want the otherwise empty flute staff hidden in the score would work (and either another for clarinet, or just use the same staff for both, changing instruments where needed).

It's been suggested a "don't hide this measure" facility would be a nice addition, could be something you add from the palette or maybe in the staff list in measure properties.

You shouldn't need to check parts "every time" you make a change. The majority of changes are obviously linked or not, no need to check. When in doubt, check once and now you know about that change type goign forward.

Text on a gliss probably should be changed, rather than document the fact that it currently is not, is it not better to just submit a bug report so it can be fixed?

Reply

• Sep 5, 2019 - 12:42

Many if not most layout changes to the score should not affect parts. Consider a dynamic moved to the left of a note now the staff to avoid a collisipm with a note on the staff below that won't exist in the part (because it's for a different instrument). Orntebdact that.number of measures per system will different so layout adjustments based on horizontal space won't make sense. And tons more similar cases.

Reply

• Sep 17, 2019 - 13:54

Especially in crowded scores customisation of the beaming is sometimes necessary
to avoid collisions with elements belonging to other staves or to prevent the clutter of
stavelines shining through the beams. (wedges)
Custom positions of beaming are linked. But propagation in the part seems a bit illogical in
this case. (No big deal of course. Apply 'reset shapes and positions'.)

Reply

Do you still have an unanswered question? Please log in first to post your question.