Chord Changes are Staff text, not System text
3.0, maybe 2.0 too
I cannot see a way to create parts and have the Chord Changes/Symbols flow through to the parts. Rehearsal Marks and System Text flow through, but Chord Symbols are attached to a staff. This does not make sense, at least not to me. In what score would different staves have different chord changes? Maybe some extreme avant-garde jazz piece, but even then, there are ways to write the chord symbols as compound chords. I most certainly want the chord changes to flow through to all the parts rather than to none of them. There might be parts, like drums/percussion, where they are superfluous, but they cause no harm and it's easier to Select All of Same Type and delete them for the few parts that do not want the chord changes.
Additionally, I just created parts for a score that contains chord changes in the top staff. That top staff's part contains the chord symbols, as expected. But there is inconsistent behavior: When I make delete a chord symbol in the part tab in MuseScore, that chord symbol is deleted in the score tab too. But when I add a chord symbol to the score tab, it does not flow through to the top staff's part tab. It seems that the problem is that deleting chords is synchronized across the tabs, but adding them is not. That strikes me a a clear bug, but I'll wait for a response to this as a whole before I submit anything official.
Comments
Chord symbols indeed attach to staves, not systems.
In reply to Chord symbols indeed attach by Jojo-Schmitz
In the UI, Rehearsal Marks seem to attach to a note, in a staff, but they auto-move to the top staff, and when you create parts they are clearly treated as system text. It seems to me that chord symbols should act the same way. Different chord changes across staves is extremely rare, if it happens at all.
In reply to In the UI, Rehearsal Marks by sideways
Problem with that idea is that chords may be different for different instruments, depending on transposition.
In reply to Problem with that idea is by Isaac Weiss
That is something I had not considered. Though doesn't a transposition feature in MuseScore handle that? Or shouldn't it? I haven't dealt with transpositions in MuseScore yet. I thought that each staff had a transposition property so that in the score it was untransposed, but the part was properly transposed for the performer. Isn't that how it's supposed to be? I don't want to see a transposed staff mixed in with a bunch of untransposed staves. That would be a difficult score to read.
I'm reverting to a separate .mscz file for each part instead of using MuseScore to generate my parts for me. So this is not a big priority for me at the moment. There is the bug regarding adding and deleting stuff across scores and parts that I mentioned. I'll try to post that as an issue and leave the feature change stuff alone for now.
In reply to That is something I had not by sideways
"I don't want to see a transposed staff mixed in with a bunch of untransposed staves. That would be a difficult score to read."
... That's just the way reading scores is. You can turn it off with the Concert Pitch button, top right, but most of the time scores have all the staves transposed respectively.
In reply to "I don't want to see a by Isaac Weiss
Even in today's computerized world? I guess that's why I'm not a conductor.
As a side note, this clears up something for me: how to get different staves to display different time signatures. I know that sounds backwards, but I backed into the concept.
It still seems to me that chord changes should be treated like rehearsal marks in terms of flow-through to parts. If a staff is transposed, then transpose the chords - MuseScore knows how to do that already in its existing Transpose feature. That strikes me as the ideal way to do it, and it's not outside the realm of other current functionality.
In reply to Even in today's computerized by sideways
Setting aside for now the transposition issue, I brought this up some time ago:
https://musescore.org/en/node/31261
The context that I was considering was in the form of a pop song book, where routinely the chords are shown at the top of every system even though the top staff in the system might change between systems (it might be a vocal line, or a piano, or a guitar).
In reply to Even in today's computerized by sideways
Here's an example of when you have transposing instruments and each one has the chords different:
![chords transposed.png]( "chords transposed.png")
In reply to Here's an example of when you by Isaac Weiss
Isaac, I have never seen a score like that with chords for each staff, much less different chords. I tend to think of chord changes only in the context of pop/jazz/rock music. I think the example that Marty provides is my same train of thought. I don't want to see (and I certainly don't want to have to create and maintain) chord symbols on every staff. I see them as system-level guides, like Rehearsal Marks. It really is a sensible way to do things for a lot of popular music.
If there really are two equally important ways to do this, it might be appropriate to separate System vs. Staff Chord Symbols.
In reply to Isaac, I have never seen a by sideways
The reaosn you don't see scores with chords for each staff is that chords are normally only given for the instruments that actually need them - rhythm section instruments (except drums) and normally at msot one improvising soloist. and it's pretty much universally true in published music that each of these staves gets its own set of chord in a score. I've been conducting from scores for decades and can't remember ever encountering an exception. Chords are virtuallt always attached to each staff that uses them; they are not normally added just at the top like rehearsal marks. Not that it couldn't ever make sense for someone to want to do that for some unusual special purpose, but it is not the case that there are two different standard.s There is pretty clearly just the one - chords attached to each staff that uses them.
In reply to The reaosn you don't see by Marc Sabatella
As I said, I am not a conductor. Yet several MuseScore users on this thread seem to feel that System-level chord symbols are a good idea as an option. Why is that? I think that from a songbook point of view, if you want to include more than just a condensed piano/voice pair of staves, it makes sense. Or if you want to use the voice part as a lead sheet without creating a separate score. In a song book, the chords only appear once. Now you might respond that there is only one instrument that uses the chords in a song book, the piano, not the voice, but that's debatable if you think in the context of a lead sheet.
And why does each stave in a score have its own chord changes? Is it because it's useful to the conductor? Or is it a function of printing presses pre-computers, where if they wanted to print the chords on the part, it was easier to do so in both the score and the parts? In other words, is it done for the conductor or for the publisher? I am not a conductor, but if I'm reading a score, I only need to see one set of chord changes. The chords in the other staves are simply distracting and might force extra vertical space between the staves.
If there is demand for change, then change will occur. So if more people want this, MuseScore will consider adding a feature. At the moment the support is limited, as it apparently was when this issue was raised previously. Maybe some day that will change. For now, I don't expect that this discussion has anywhere to go, unless more users jump on the System-Level Chord Symbols bandwagon. I'm having other issues with MuseScore's auto-generated parts, one of which is a major bug, as mentioned in the initial post, so I'm abandoning that for manually created parts in separate files. As such, none of this affects me now. Thankfully MuseScore makes it easy to select all the chord symbols, and copy/paste them once, not one a a time. Unfortunately, rehearsal marks don't do that, and must be copied/pasted one at a time.
In reply to As I said, I am not a by sideways
Not sure what you mean by a "songbook" in this context, but if you mean something different from a "score", then indeed, you wouldn't normally want or need chords on each staff, because in normal published music, individual parts are not printed from what I think of as songbooks - only from scores. So including the chords over the top staff only is completely sufficient, because there will be no individual parts. Again, though, sure, I can see how eople working in contexts other than traditional published music might want a system-attached chord symbol for some unusual special reaosn, so some day a feature might be added to all it. Again, I'm just explaining why things are as they are in the world, not telling they that they must always be that way. but music really is published the way I am describing and the way MuseScore supports.
As for why each staff in a *score* contains chord symbols if the part does, it is for the same reaosn that each staff contains *notes* or *dynamics* or *aritculations* if the part does: the point of the score is to show what all the parts contain. The conductor wants to look at the 2nd trombone part and know what that 2nd trombonist is looking at. If there are notes and rests in the part, they should be in the score. If there are dynamics in the part, they should be in the score. If there are articulations in the part, they should be in the score. And if there are chord symbols in the part, they should be in the score. The only things thsat are *not* duplicated on each staff are the things that by definition must be included on all parts and be identical on all parts - eg, tempo and rehearsal markings. Chord symbols are generally *not* on all parts, and because of transposition they won't be the same on all parts that do include them, so a conductor wants to know who has them and who doesn't and what they actually say. That is why it has been done this way for as long as scores using chord symbols have been published.
As for ther bug you allude to, you might wish to start another thread and attach a score and precise steps to reproduce - I'm not aware of any bugs involve parts and chord symbols. In particular, adding and deleting chord symbols to any staff in the score links to the part works exactly as expected in all scores I have tried.
In reply to Not sure what you mean by a by Marc Sabatella
I just created this issue:
https://musescore.org/en/node/124961
The other major issue I have with parts is also filed as a bug here:
https://musescore.org/en/node/124831
In reply to I just created this by sideways
To be clear, then, so you are talking about bugs in unreleased experimental nightly builds? I thought you were talking about actually using the software, not just testing builds. I can't reproduce any the problems you describe using released versions of MuseScore.
When discussing experimental builds, it's best to use the Technology Preview forum, BTW.
In reply to To be clear, then, so you are by Marc Sabatella
Yes. Excuse my lack of proper forum etiquette. It all seems mixed together here in this forum at this time. I saw myself as going with the flow. This original post crosses over between the versions, so that's how I might justify this cross-over into postings in the Issues tracker that do not affect 2.0.
Due to circumstances now beyond my control, I am using 3.0, not simply testing it. I try to properly isolate and post any bugs I find, but that is a side-effect of me actually using 3.0 to produce scores and parts. I don't constantly rebase my code to the latest nightly, and that provides me with some degree of stability.
I can try to use the TP forum more in the future. So to discuss a potential bug in 3.0 prior to posting an official issue, I should use the TP forum instead of this one?
In reply to Yes. Excuse my lack of by sideways
Yes, when discussing something that ordinary users won't ever see because it only affects experimental developments builds, it is best to use the Technology Preview forum, to avoid confusing users (as well as developers). But indeed, it's not always clear, as sometimes there are discussions that start as issues with current versions and then morph into suggestions for future releases or discussions of how experimental development builds might be addressing the issues.
Anyhow, and you're right the boundaries often get blurred. But it's good to be clear to avoid misunderstandings. Regardless of which forum the post went into, it would have been a good idea to make clear which parts of what you are writing about apply to which versions.
But once more to be clear: for reasons that I trust you fully understand and accept, experiment 3.0 developments builds are *not intended for real use*. They are completely unsupported and it is not to be expected that they actually work. Chances are you will have to throw away every score you create with a current 3.0 development build, as they probably won't open in future builds. And of course, there may be stretches of time where large bits of functionality simply don't work. That is the nature of development builds at this stage.
In reply to The reaosn you don't see by Marc Sabatella
" ... instruments that actually need them - rhythm section instruments (except drums) ..."
I believe that the symbols should be added to the drums because they may well actually need them. It can be valuable to those who use the harmonic structure for their drum solos, and those who may get lost can where the harmony changes.
In reply to "I don't want to see a by Isaac Weiss
Actually, I think the OP makes a good point. I can see that there may be occasions when it might be more convenient to have chord symbols behave as system text and appear in all parts "automagically", without having to copy them across to all staves (if that's what's needed).
However, I personally wouldn't want that behaviour as default - for example, in a typical big band chart I might want chord symbols in the piano, guitar and bass parts for most of the arrangement but (except for improvised solo sections, of course) I certainly wouldn't want them to appear in all the horn and drum parts too because I'd then have to go through each of those parts individually, selecting all the chord symbols and deleting them, which is just unnecessary extra work.
I can't see any harm in making this a selectable option in the inspector and/or preferences so the user could choose between chord symbols behaving as staff-linked (as now) or system-linked though.
I don't understand why viewing a score with mixed transpositions is a problem though - that's what the Concert Score/Transposed Score button in the toolbar is for (so you can quickly and easily switch between Concert and Transposed score views).
In reply to Actually, I think the OP by Xasman
Now that the Concert Pitch button was explained by Isaac, I understand how all that works - no issue there.
I think the example you give vs. my example illustrates that this is a numbers game: what percentage of my staves want chord symbols? For me, clearly drums do not want them. But I have a bunch of rock scores with multiple guitars, and I like putting the chord changes with the vocal parts, like a lead sheet. So for those rock scores, the only staff that doesn't want chord symbols is the Drum Kit staff. If there's a piano or other keyboard, that staff will want chord symbols too. Guitars and keyboards are simply pervasive in pop/rock music, and guitarists and keyboard players like to see chord changes, so do bassists.
In reply to Now that the Concert Pitch by sideways
I understand that, which is why I agreed that your suggestion was a reasonable one and why I suggested that giving the user an option (in prefs and/or inspector) to choose whether Chord Symbols should be either stave- or system-linked would, in my view, be a good idea.
In reply to I understand that, which is by Xasman
I agree they are potentially a good idea as an option. I was just responding to your questions about how and why things are.
In reply to I agree they are potentially by Marc Sabatella
Not my questions - I didn't pose any! I was just lending support to the Original Poster (sideways) by suggesting the provision of an option for this.
In reply to Not my questions - I didn't by Xasman
Indeed. For whatever reason the forum software stops indenting at some point so it can be difficult to tell, but I wasn't actually responding to you :-)
See this .
In reply to See this. by chen lung
Sorry if this has been considered before, but there is a difference in the way a score should look and a part should look. My thought is that only one set of changes needs to be visible in the score, in "C". The transposed changes should appear in the parts.
In reply to Sorry if this has been by xavierjazz
Of course, but this is easy to do now - in fact I do it all the time. Here's how:
Just input the chord symbols onto the one stave in your score where you want them to appear, then copy and paste to any other staves as required. (In the score) In each of those staves you just copied to (i.e. those staves in which you want them to appear in the parts but not in the score), right-click the first chord symbol and select all in same stave, then hide them (uncheck visible /Ctrl+v). They will, by default, still be visible in the parts.
Now you'll have chord symbols visible in all the parts where you want them but they'll only be visible in the score on one stave.
In reply to Sorry if this has been by xavierjazz
What should appear depends on the type of score and your requirements - there's really no way MuseScore can second guess that. But fwiw, virtually every jazz big band and combo score I have seen shows chords symbols on each staff of the score that needs them - eg, piano, guitar, bass, and whichever instrument is soloing.