I got that syncing feeling ...
My tests show that a score's Velocity types and Velocity values are not syncronized between the Conductor's score and its Parts.
Could this be according to design?
Please see the attached score.
Conductor vs. Part Sync. - Velocity types and values 02.mscz
scorster
Comments
These settings being somewhat related to layout rather than content, and without a way to break the syncing, I'd see this as by design.
In reply to These settings being… by Jojo-Schmitz
And probably not syncing is a Good Thing as velocities are more likely to be tweaked in the score to achieve balance but in the parts to achieve nuance. And those are not necessarily the same thing.
In reply to And probably not syncing is… by SteveBlower
SteveBlower wrote> ... velocities are more likely to be tweaked in the score to achieve balance but in the parts to achieve nuance.
You can hear part-edited velocity nuance in the parts?
As mentioned in the attached score, I only hear velocities according to the conductor's score, even when I have the Part "soloed" with the Mixer's "Play part only" option checked. How can I edit nuance if I can't hear it? Am I missing some option or setting for that?
But as mentioned, I certainly would like to configure my scores so Part & Main velocities are synced. So I can reliable edit in either view and know the change is being applied to the other. Just as with pitch.
scorster
In reply to SteveBlower wrote> … by scorster
If you change the number in the velocity field for a note or a dynamic marking in the inspector and then create a part that number is replicated in the the velocity field in the part. Whether the effect of that number can be heard or not is another matter and not mentioned in the original post. The numbers are propagated when the parts are created but are not subsequently synced.
In reply to And probably not syncing is… by SteveBlower
I'm a bit confused, perhaps because I'm not a musician but rather a telephone engineer!
I had always thought of a "separated" instrument part (as we can have MuseScore create for us) as being one instrument's portion of what I will call here for safety the "whole score", not as being a separate work derived from that instrument's part of the "whole score". So I can't quite understated how we would come to "tweak' the separated part (other than with respect to labeling and the like) but not identically tweak that instrument's part of the "whole score".
Or is the notion that the raison d'être for the instrument's part is that we would have MuseScore play it as a solo performance, in which we might well want differences in rendering from how we would want that instrument to "play" when we have MuseScore play the "whole score"?
I keep in mind that if MuseScore's work product for some project is paper scores or parts, the performers can''t see our assignment of velocities to the notes, so all this discussion doesn't matter. Indeed if a violinist takes the printed violin part of a quartet and plays from that in a solo setting, she may very likely render the notes differently than it she were playing as part of the ensemble.
But we are talking here about MuseScore being the "performer".
What am I missing here?
Thanks.
Doug
In reply to These settings being… by Jojo-Schmitz
[Post moved to appropriate section]
In reply to I'm lost here ... You're… by scorster
Velocities (of notes and of dynamic markings) are replicated from the score when a part is created. Subsequent edits are not synchronised. Thus it is possible to create a part with velocities identical to those in the score and it is also possible to then modify either without affecting the other, which seems a Good Thing. However, I think I read somewhere that users may be provided with more flexibility in setting linkages between score and parts in MuseScore4.
In reply to Velocities (of notes and of… by SteveBlower
Velocities (of notes and of dynamic markings) are replicated from the score when a part is created.
Agreed -- and so generating parts is best done after all velocity edits to the main score have been made.
Subsequent edits are not synchronised. Thus it is possible to create a part with velocities identical to those in the score and it is also possible to then modify either without affecting the other...
Yes, velocity number edits are not synched with existing parts. Playback (of parts) is affected though.
.
My observations...
Main score and part velocities can be modified in one and will have an effect on the other, but it is not a two way street, and a part may "sound" exactly like its playback (e.g., as solo) in the main score though the velocity values in part and main score may be different. The behavior differs when changing velocity values of dynamic markings, or when changing the velocity of a range selection of the notes themselves.
Here's a test score that uses 4 instruments. It's easy to adjust the lead guitar part's velocity settings and to listen to the results:
More_Than_a_ff.mscz
N.B. In the score, the ff, for the lead guitar was originally velocity 112 (default, as per other instruments).
I created all the parts, and all ff's showed 112 for the ff, velocity.
I then changed, in the full score, the ff, of the Lead Guitar to 95. The playback volume of the part dropped (also showed lower in the synthesizer), but the value of "Velocity" did not change in the Inspector of the part to reflect the drop in velocity (to 95).
This has to do strictly with changing (in the Inspector) the value of "Velocity" for a dynamic marking.
Changing ff, to velocity of 30 in the full score will propagate to the part -- but only for part playback volume. The velocity number of ff, in the Inspector of the score part does not change.
Also, changing ff, velocity in the score part has no effect at all on the main score (not even for playback).
However, changing the ff, in the part to, say, p, (or even a brand new ff, from the palette) will be accurately reflected in the main score.
Setting 'Offset' or 'User' velocity values (of a range selection of notes) in the main score get playback sound but not velocity values propagated to the part.
In reply to Velocities (of notes and of… by Jm6stringer
Jm6Stringer wrote > Changing ff, to velocity of 30 in the full score will propagate to the part -- but only for part playback volume.
Thanks for your input. Busy day here so I haven't yet checked all the scenarios your presented, but I do want to make a couple of comments.
To be clear in the following I use capitalized "Part" to refer to a generated Part (via File>Parts) and by lowercased "part" I refer to a part/track in the main score.
1) I'm with OP. Dynamic mark settings and velocity properties "propagate to the part" ONLY when the part is initially generated. After Part inception no linkage exists in either direction—MuseScore "hangs up the phone" between the part and the Part, and there's no option for the Part to "phone home." In other words the user can't update the Score from the Part or visa versa.
2) Best I can tell, we never actually hear the Part—even though "Play part only" semantically extends that promise. I certainly haven't discovered how to play the Part with its velocity properties audible as a "soloed part" ... or play the Part along with all the other Parts.
Perhaps it's clearer to say:
When playing a Part with "Play part only" checked—we hear the "part" soloed from main score! In other words, playback heard via "Play part only" is an impersonation of the Part, because under these circumstances playback cannot incorporate the part's note velocities, velocity types, or dynamics (even if the velocity type is Offset) because in truth, MuseScore is simply not playing the Part.
If I've indeed accurately described the reality, it colors a misleading conflagration of issues and behaviors.
When viewing the Part—and when given the choice to "Play part only"—it seems quite odd that we can't actually hear the Part with all of it's dynamics and note properties.
The overarching problem with this is that the user must always remember NOT to edit velocities in Parts if they want/expect them to be heard in playback. This is a shame because it's easier to read along and edit in a Part, but then one must switch to the main score to alter a velocity.
Perhaps Musescore could endow the Mixer and/or Playback preferences with a switch for:
• Play Part's velocity settings
• Play Part's dynamic settings
or
• link velocity between main score and parts
• link dynamic settings between main score and parts
I vote for the latter two options and more flexibility in linkages in Musescore 4.
scorster
In reply to Jm6Stringer wrote > Changing… by scorster
If changing velocity in a part doesn’t have any effect on that part's playback, then either that or the fact that it isn't in sync with the main score is a bug.
In reply to If changing velocity in a… by Jojo-Schmitz
Jojo wrote> If changing velocity in a part doesn’t have any effect on that part's playback, then either that or the fact that it isn't in sync with the main score is a bug.
Yes. It appears two huge bugs have been revealed (or that Musescore lacks some seriously important options):
a) velocity values and velocity types changed in a part fail to update the velocities of the with main score
b) velocity changes made in a part never effect that part's playback, neither when viewing the part and playing with "Play part only" checked, nor when playing from the main score. "Play part only" merely solos the main score's unlinked versions of velocities. Main score playback always references its velocities, not those of the part
Regarding a)
While I don't see why anyone would want part velocities unlinked from the main score's velocities, people in this thread have argued for this default behavior, for instance, as a means to add nuance to the Part. But, as mentioned, those nuances are never heard—except perhaps if one exports the part and therefore rendering it completely extricated from the main score. Which would make sense: post export there's no longer a main score on the playground to bully the part into submission. But I haven't tested that part export for this because more than half my effort has been devoted to making my observations and recommendation clear in my posts.)
And I agree with @Doug Kerr that "velocity performer" is Musescore ... and the printed page cannot communicate individual velocities to a human performer. Musescore entirely ignores the Part's velocities, as does the human performer. So who are the Part's nuances for?
Regarding b)
With velocities unlinked (between main score and parts) we lose an excellent venue/view for editing the part's velocities as we'd want them heard in the score. To me this is a bug ... or a missed huge opportunity.
Each part provides an refreshingly uncluttered view ... often on a single page or spread that's fixed on the screen for an extended period of time. Editing in such a view is MUCH easier me, particularly with respect to important details such as velocities. Granted, at times I may want to edit velocities in the score, but ONLY if the part's velocities are linked and updated; others may have no use for this or they may hold different preferences.
Editing in the main score is indeed useful when one needs to frequently attend to multiple parts. But when the intent is to refine a single part, the main score amounts a sea of distractions, due to the presence of the other parts and therefore Musescore's need to frequently update the display. It can be dizzying and tiring.
Thanks to all!
scorster
In reply to Jojo wrote> If changing… by scorster
Huh. That makes sense. If these velocities are never used they ought indeed to be linked.
In reply to Velocities (of notes and of… by SteveBlower
Getting slightly OT, but I tend to edit the .mscx to break more links as I heavily change my parts vs main score. Deleting the
<linkedMain/>
tags in the main score and the<linked></linked>
tags in the parts (3.x) or<lid>97</lid>
etc. tags from either (2.x).In reply to These settings being… by Jojo-Schmitz
I'm lost here, Jojo ...
You're saying that note velocity and velocity type are not content ... and "somewhat related to layout"
I don't know what "somewhat related" means.
For analogy, regarding content. Pitch is certainly content. And therefore pitch is synced between the main/conductor score and it's parts:
• If I change pitch in the main/conductor score it affects the part
• if I change pitch in a part it affects the main/conductor score
Why not accordingly with note velocity and velocity type?
Perhaps "unlinked velocity" is valuable to some, and that's why it became Musescore's' default behavior. But I doubt I would ever want that. So why not offer the option of having velocity linked between Parts and the main/conductor score?
Or an option to:
• update Part velocity values to Main/Conductor's velocity values
• update Main/Conductor velocity values to Part's velocity values
scorster
In reply to I'm lost here ... You're… by scorster
Somewhat layout as it is sound, not really layout.
Pitch indeed is clearly content and needs to be kept in sync.
An option to link/unlink properties between full score and parts has been requested and would be useful, but as long as it doesn't exist we'd need to stay on the save side.
In reply to I'm lost here ... You're… by scorster
I note that not only is note velocity not kept synchronized between the main score and an extracted part, when edited with one or the other visible, but in fact all of what I call "underdata", the properties that (mostly) only influence play, including note play start time ("position") and duration.
I would think that, as a general rule, all note properties should be kept consistent between the main score and an extracted part.
Doug
In reply to I note that not only is note… by Doug Kerr
It should be all of those or none. None, if we'd get the playback to work properly, else all.
In reply to It should be all of those or… by Jojo-Schmitz
I’d argue for all by default, with an option to unlink individual properties per individual Element (note, chord, box, …) which we currently only have by
.mscx
editing but is possible.In reply to I’d argue for all by default… by mirabilos
There's no (official) option to unlink, and as long as there's not we'd rather stay on the "don't link" side...
If the playback can get made to work, that is. If we can't or won't, syncing without an unlink option is the only possible/sensible fix though
In reply to There's no (official) option… by Jojo-Schmitz
… yet ;-)
In reply to … yet ;-) by mirabilos
True. So sync them now, enable unlink later, and together with playback.
If really playback doesn't work currently and can't get made to work more easily than the syncing
In reply to It should be all of those or… by Jojo-Schmitz
If all note properties are synchronized between the main score and an extracted part, it doesn't matter whether play follows the note properties on the main score or those on the active extracted part.
Of course if the "policy" is confirmed that the note properties (both the visible aspects, like pitch and time value, and the "invisible" aspects - the underdata) not be synchronized between the main score and the extracted parts (that is, none of it), then upon play with an extracted part visible, play should be from the note properties on the extracted part.
That of course raises a question about the "Play part only" check box, which is global in its effect, and accessible with any extracted part visible. With it OFF, if we play, would we hear, for the extracted part that is visible, the notes as defined on that extracted part, but for all the other parts, the notes as defined on the main score? Or what?
It all continues to suggest to me that having an extracted part and that instrument's part on the main score not identical in every property is a bad idea. If we wish to have a separate part that is tweaked from that instrument's part on the main score (perhaps to be used for a solo performance by MuseScore), it would seem much better to capture the extracted part as a new score file and then hack away.
But far be it from me to tell real musicians how to do their work
Doug
See #322562: Request to synchronize note playback properties by default once it becomes possible to unlink them on command