Request to synchronize note playback properties by default once it becomes possible to unlink them on command
Please synchronize Velocity types and Velocity values in the main/score with the Velocity types and Velocity values in the generated Parts. This behavior needn’t be the default, however I would certainly want the choice—via Preferences—to turn on Velocity sync and know thereafter that I can rely on Main / Part synchronization.
Presently, on inception, the velocity values in the Parts are populated to match those in the main score. But afterwards no linkage exists ... in either direction.
I similarly request and advise that Musescore synchronize Dynamic>Velocity values in the main/score with the Dynamic>Velocity values in the generated Parts. In the same manner as velocities Dynamic values populate into Parts initially but no linkage exists after the Part is generated.
Discussion and example score here
scorster
Comments
Also please synchronize play duration and play start time (position).
Doug
I discovered some typos the initial post and decided to add clarification ... but it was too late edit. So I rewrote it here.
Later I was able to edit the initial post, so I've deleted the text to avoid redundancy.
Here's an example score for Dynamic velocity settings
Inspector Dynamic Velocity.mscz
scorster
In reply to Also please synchronize play… by Doug Kerr
Yikes! I hadn't notice that play duration and play start time too are not linked between Main and Part.
The list of known linked note properties is getting a smaller and smaller, but gratefully it includes pitch!
Use case rational for the initial Issue Tracker request:
Often I want to work in a view less cluttered than a score's Main view. Largely this option so I can read along like “an instrumentalist reading the printed part,” rather than reading like a conductor, who frequently needs to flip pages. Naturally, much like a conductor turning pages, Musescore similarly needs to update the display during main score playback, and does so even more frequently if the user is viewing on a small display or zoomed it. When I want to focus on a single Part I prefer to avoid the main score as reading there can have a significantly jarring impact on my eyes and concentration.
Granted in the main score I can Press “I” and hide all the other Parts. And then make them all visible when done. But that seems like an unnecessary step when Parts already exist.
And in Part view, while proof reading, I can easily see and groom the Part’s layout and appearance using the appropriately unlinked style properties like: page margins, staff spacing, line breaks, first line indent, scads of others properties …
In short, I prefer proofreading, editing (and even composing) from the Part:
• because it's easier on my eyes and concentration
• because it allows me to proofread/edit the score while “simultaneously” editing the Part’s layout and style properties—thus once the Part is indeed well groomed and it's essentially ready to go to press.
• and while grooming layout I can also edit playback properties, like velocity properties). So when done, the part looks right and the Part sounds right —though currently the latter is not possible when editing velocity and dynamic properties in Part view.
I'd expect that other scorists who generate Parts would certainly want these options. Presently however it's "dangerous" that certain properties, like note velocity, are not synced between the Part and the main score. One can feel safe editing velocities in the Part, and later discover that those changes are meaningless and not stored in the main score.
An additional issue is that we never hear the part itself, even when Play Part Only is checked we hear the part from the main score.
scorster
scorster,
Makes sense to me.
Doug
The bizarre issues described above result from the underlying behavior inherent to linked staves.
Summary and context
• At some point in Musescore's history Linked staves were developed to allow for the existence of score Parts. Parts are an important feature of any significant score writing software, so this was a good move.
• At a later date Musescore leveraged its Linked staves mechanism to provide live notational editing between a tablature staff and a linked standard staff. Again, that was a significantly good move, because essentially all of substantial tablature editors offer the option to sync tablature with a standard staff.
Here's the situation as it stands in Musescore v3.6:
In Linked Part or Linked Tablature configurations:
• we have complete synchronization over note pitch (Bravo!)
BUT:
• not so with volume (i.e. note velocity and dynamic markings)
• not so with timing subtleties, such as start time, play duration.
Furthermore:
• In a score with a standard staff, there is no option for hearing velocity edits made on a tablature staff. Such an environment imposes serious shortcomings on anyone attempting to create expression via velocity edits:
a) it's tantamount to editing audible aspects of a score with the channel muted.
b) the designated sounding staff is never updated—and it's easy to "not know this" because the behavior is undocumented (out of embarrassment?) Perhaps it's more accurate to say that the documentation is consistently misleading or largely in error on these issues. Ironically the documentation describes the behavior I would expect and prefer. This suggests that the existing documentation reflects the original design intent and a prior implementation ... and somehow things went sideways somewhere down the road.
• Similarly in a Musecore Part, even with Play Part Only unchecked, we can't hear the Part (because in v3.6 playback is always generated by the Main score, NEVER by the Part) So we never get to hear velocity or dynamic edits made in the Part. Therefore the shortcomings are the same as a) and b) above.
Request
• Pitch is a notational aspect of a score, the part or tablature. Therefore Musescore rightfully syncs pitch between part/main and between tablature/standard.
• Audible non-notational aspects of a Musescore Part or a tablature staff (such as velocity, dynamic playback, start times and play duration are unfortunately quashed, because playback emanates only from the linked standard staff, if there is one. And changes in Part or Tablature properties are never synced, thus a hapless user may easily lose track as the score's intended velocity integrity fragments and degrades. Velocity sync is the simple logical solution and prevents all these issues.
To date we've only heard weak justifications and purported purposes for confusing and awkward unsynced situations. Meanwhile those wanting to edit velocities in Parts or tablature are simply out of luck if they want hear the result in playback. And worse, the changes are not synced, or updated between the Part and the main score, nor between a tablature staff and its linked staff. And, sorry to say, I think this marks the 20th time I've stated this.
Request
Please add an option to synchronize velocities, dynamics, start times and play durations between Linked staves—perhaps via a Musescore preference (and allow a score or a part or a note can override that setting) — OR — make the synchronization of these properties the default while allowing overrides to break syncs( per note, per staff or per score.)
Hopefully we get this in v4!
All playback properties are unlinked as far as I know, by design.
As explained in in the various forum thread, it would be a mistake to linked these until such a time as it becomes possible to break the link. The general principle we try to follow is, link the things one virtually always wants linked, but leave independent anything where the user might commonly want independent control. And that's for one simple reason: it is far far far easier to simply reproduce the same adjustment across both staves than it is to deal with the sort of workaround involving invisible notes or worse that might be required to "fake" independent control if the property were linked. So, given that sometimes one wants values synsed and other times one doesn't, we choose the default that causes the least amount of pain for the cases where you don't happen to want that behavior.
On the other hand, if/when it becomes possible to unlink properties on command, this would make a good candidate to reconsider the default for. So I'm leaving it open to revisit at such a time as it becomes feasible.
Also, a more serious issue here is that adjustments within the part have no effect at all, since the part's settings are ignored in favor of the score. This makes it impossible to do things like add cue notes that are silent in the score but not parts, etc.
In reply to (No subject) by Marc Sabatella
Hi, Marc,
You say:
>>So, given that sometimes one wants values synsed and other times one doesn't . . .
Just in the interest of my ongoing education in musical practice, I would be pleased to hear of an example or two of when someone wanted the velocity values not synchronized between two staves in the same part (on the master score, if there are Parts), and how that behavior of MuseScore would be utilized in that case.
Thanks.
Doug
In reply to Hi, Marc, You say: >>So,… by Doug Kerr
It appears that, at the present time, for a scorist working with a linked regular notation staff and tab staff (on the master score - I am not talking at all about Parts), wishing to set note velocities to other than the original values, should just do so on the regular notation staff.
There is no need to even think about the velocities on the tab staff since they don't do anything anyway.
Of course, if it is anticipated to later delete the regular notation staff, the story becomes different.
Doug
The issue with linked staves is entirely separate and (IMHO) clearly a bug.
This issue here is about main score and parts, please don't mix up these.
Velocities not being linked between score and parts can be usefull for example for a multivoice part, 2 instruments in one staff, e.g. Soprano and Alto or Tenor and Bass (or Flute 1 and 2), extracted twice, once with voice 1 (Soprano or Tenor) louder and the other with voice 2 (Alto or Bass) louder, for better rehearsal.
In reply to The issue with linked staves… by Jojo-Schmitz
Hi, Jojo.
Thanks.
I assume that play in rehearsal would be from separate score files made from the extracted Parts. Otherwise we would not hear the customized velocities.
Am I correct?
Thanks.
Doug
No, one score, same part generated twice.
In reply to No, one score, same part… by Jojo-Schmitz
But in that setup when we select a Part tab and do play, the velocities of the sent notes are those on the "master score".
What am I missing here?
Doug
No, as those are not linked, which this very issue here ia all about
In reply to No, as those are not linked,… by Jojo-Schmitz
I think you speaking of using two Parts extracted from the same master score part when you have two instruments on the same part, then having the velocities on the two extracted Parts be different (so one Part can be used in rehearsal for one of the instruments, and the other Part for the other instrument, so they will have different "loudness".
Yes, we can do that because, with respect to the Parts vs. the master score, the velocities are not linked.
But if we play at rehearsal from this score file (carrying the "master score" plus two Parts extracted from the same part) , whether we select the "master score" tab, or one of the two Part tabs or the other, the play will sound the same, with the sounded velocities controlled by the velocities on the master score..
So I'm still missing something.
Doug
In reply to I think you speaking of… by Doug Kerr
Is the attached what we are talking about here?
In this score:
On the master score, the velocities are all User 80 (U:80).
On the extracted Soprano Part, for M1, the velocities are all U:100; for M2, U:50.
On the extracted Alto Part, for M1, the velocities are all U:50; for M2, U:100.
If we play with one of the three tabs selected, we can tell which Part contributes the velocities by the change in loudness from M1 to M2.
Doug
That's not multivoice, only voice 1 all the way. But apparently it doesn't work as I thought it does, changing the velocity of one voice in one part doesn't make any difference in playback, strange
In reply to That's not multivoice, only… by Jojo-Schmitz
Jojo wrote [Part playback] apparently doesn't work as I thought it does, changing the velocity of one voice in one part doesn't make any difference in playback, strange.
Hi Jojo,
I'm so glad you see this. It's what Doug, myself and others have repeatedly pointed out.
scorster
In reply to (No subject) by Marc Sabatella
In the past I never felt a need to comment when a forum member renamed one of my Issue Tracker reports or requests, because the result was similar enough, or it improved the title.
This time it's different.
Scorster's original title of this Issue Tracker request:
Synchronize Velocity types, Velocity values, and Dynamic>Velocity values between the Main score and Parts
Marc's retitling:
Request to synchronize note playback properties by default once it becomes possible to unlink them on command
I specifically stated in the second sentence that I was NOT requesting a change to the default behavior, but rather, just an option to synchronize velocities between the Main score and Parts.
Therefore Marc, please reassign the original name to the this Issue Tracker request. Or at least change it to:
Request for a preference to synchronize note playback properties between the Main score and Parts
If you think it's important to have a request entitled "Request to synchronize note playback properties by default once it becomes possible to unlink them on command" please open your own. It sounds like a reasonable and worthwhile request, but it is not my request.
scorster
It is the same thing, really. Currently it is not possible to break or set such a link, the properties that are linked, are in a fixed hard-coded list, all others are not linked. Once having the mechanics in place to set or break such a link, we can have such a pref, until then we can't.
Jojo wrote >> Once having the mechanics in place to set or break such a link, we can have such a pref, until then we can't.
We'll all be happy when that day comes and a velocity sync preference is possible. Godspeed.
Meanwhile a group of us have logged compelling reasons for synced velocities. And perhaps one way would be for MuseScore will that add velocity to the fixed hard-coded list, of which you speak ... if that's possible without upsetting the applecart. But we keep hearing that our compelling reasons are merely fringe use cases, and that other use cases far outweigh those. Unfortunately the presentation of those cases is not forthcoming, not in a coherent or convincing manner. Then conversations devolve into a twisted wreckage, and I conclude that the needed change is seen as difficult to implement. And though I have no concept of the underpinnings and dependencies, I suspect that may indeed be true. So best to everyone in the effort.
scorster
that other use cases far outweigh those
That hasn't been said and is not really true anyway, a single case/reason where you don't want them linked is enough already!
We only link those that without any doubt should be linked and don't link any other, because there is no mechanism in place to break (or set) such a link.
Here however the issue is that these properties are not links, but not working as expected either, they don't change the playback apparently.
In reply to That's not multivoice, only… by Jojo-Schmitz
Hi, jojo.
You wrote:
>>That's not multivoice, only voice 1 all the way.
Yes. The objective of that file was to most clearly illuminate the behavior I had described, not to be a model of a realistic scoring situation.
Doug
If you don't want the properties linked but merely just a command to run to copy velocities from one staff to another on demand, that's fine too, someone could write a plugin for that today I guess. But I doubt most people would find that as useful as actually linking. So I'd prefer to leave the issue title as I have set it - that's the only new feature that I think makes sense to add. In other words, at such a time as it becomes possible to break links, it definitely makes sense to have the default be to link playback properties in my opinion.
I was also asked to provide examples of the usefulness of having separate velocities. I've given several already. Two most obvious, humanized/non-humanized playback, and cue notes.
Regarding playback of parts, my understanding is that as of maybe around 3.1 or so, parts don't actually play at all - playback simply triggers the playback of the corresponding staff in the score. In fact, at one time it was even impossible to play the part only - viewing the part always played the full score, and I think then muting or soloing in one also did it in the other. This was replaced later with the scheme you see now, where if you view the Mixer when in the part, you'll see a checkbox that toggles whether you hear just the part or the whole score. As far as I know, it's a trick - you're really hearing the score either way, but with the part soloed if you check the box.
Anyhow, I'm still not getting how this discussion has generated so much heat. As I keep pointing out, the issue is extraordinarily simple and no different really from any of dozens of other properties that we could link but don't. The principle, once more - exactly as is the case is for dozens of other properties, exactly as it has been since MuseScore 2 first introduced the idea of linked staves and parts - is that when there is any doubt as to whether to link a property or not, we don't. We don't for one plain and simple reason. If the default is unlinked but you want them the same, just do it - takes about two seconds and causes no harm to anyone whatever. Whereas if the default is linked and you want them different, good luck - it's usually a convoluted and painful workaround that is likely to be "fragile" and break at the next update.
It really and truly is absolutely that simple, no reason to be expending thousands of words on the basic principle still after all these years.
Again, once it becomes possible to actually break links directly., this all changes, and we can revisit defaults.
Hi, Marc,
You said:
>> This was replaced later with the scheme you see now, where if you view the Mixer when in the part, you'll see a checkbox that toggles whether you hear just the part or the whole score. As far as I know, it's a trick - you're really hearing the score either way, but with the part soloed if you check the box.
Yes, and that latter way of looking at it is more accurate than one might think. If the selected Part has different note velocities from the corresponding part on the master score, then when we check the box and play, we near only the notes of the selected Part all right, but rendered with the velocities from the same part on the master score - indeed just as if we were "on" the master score and set the mixer to solo a certain part. (I use "part" to mean a part on the master score, and "Part" to mean an extracted part.
The lingering clinker in all this is, if it is indeed desirable to be able to have note velocities different on a Part than on the corresponding part on the master score, what does that actually accomplish? We cannot hear that part rendered with the velocities we have set on the corresponding Part.
Doug
In reply to If you don't want the… by Marc Sabatella
Hi, Marc,
You said:
>>I was also asked to provide examples of the usefulness of having separate velocities. I've given several already. Two most obvious, humanized/non-humanized playback, and cue notes.
Well, those are just "titles" for two usage cases. I was hoping to hear how they would actually be done. I'm not familiar enough with advanced scoring practice to be able to visualize that.
For example, for the "humanized/non humanized playback" case, if, on a work for guitar with both a regular notation staff and a tab staff, the velocities on the regular staff were for the "non-humanized playback" form, and the velocities on the linked tab staff were for the "humanized playback" form, how would we actually play back the humanized form?
One answer: Delete the regular notation staff and then play the score. But I'm not sure that is what you visualize.
For the "cue notes" case, I am imagining that you have in mind to, for example, give the cue notes lower velocities on the tab staff than on the regular notation staff, so that we could hear the work with the cue notes not prominent.
But how would we play that version?
Thanks.
Doug
How to play the non-default staff - as already explained elsewhere, copy/paste, or remove the other staff, or reorder them (a bug prevents this from always working, but that's no reason to remove the feature). For the cue note case, again, it's not currently supported, but when it is, the ability to control playback properties independent will be crucial.
In reply to How to play the non-default… by Marc Sabatella
Thank you.
Doug