Inconsistent behaviour with dynamics when creating parts from voices
I created score, with two voices. I want to create parts, each voice would be separate part. Hairpins are reproduced to both voices. Dynamics will be produced, only if it is in each voice.
But once parts are created, and I add dynamics to score, it is produced in both parts.
Also, if I delete dynamics in parts, it is deleted in score, but different manner (coresponding with way, how dynamics was created)
It is probable better explained by animated gif:
I think, it should work consistent way. I see two possible options:
1) (probably easier, same as hairpins works now) only one dynamics alloved in score, even if we have multiple voices, and it will be preproduced to all parts
2) each voice can have different dynamics, but when parts are created, new dynamics is added only to corresponding part. If so, also hairpins (and cresc. texts and lines) should work this way (multiple hairpins for voices)
Attachment | Size |
---|---|
Voices-parts.mscz | 4.38 KB |
Comments
I agree it should be consistent and I incline to option 1) for the simple reason I'm not sure having different hairpins and dynamics for different voices makes much sense. At least it becomes unreadable in no time. And, as a matter of fact, I never saw different dynamics/hairpins for voices although I can't claim I saw all the scores :-).
To get this solved, it it better to make an issue for this for this at the issue tracker.
In reply to I agree it should be… by njvdberg
Different dynamics for different voices are not uncommon in closed SATB notation. Or any other notation where a voice actually represents a different instrument (such as Flute 1 & 2)
In reply to Different dynamics for… by jeetee
I actoually dont remember, I have ever seen this kind of notation (multiple dynamics per staff), but may be it is common.
How it is written? One dynamics below and one above staff? Because more, than two dynamics is not possible to read (one doesnt know, to which voice it belongs)
Another (for me minor) question is, what "standards" (Elaine Gould: Behind Bars, ...) says?
For me, it make a sense to have a
1) standard - only one dynamics (and hairpins, ...) per staff allowed, (this is priority, starting point)
but have
2) an option (CTRL + dynamics /or hairpins, or whatever/) if I want different dynamics for voice one and two (this could be nice enhacement)
In reply to I actoually dont remember, I… by sammik
Yes, they are notated above and below.
Don't call restricting dynamics to one per staff "standard", because it isn't. See for example #58031: Dynamics/hairpin range for Voice where you can see at least 30 more linked topics requesting to fix the dynamic range options to include "voice".
So no, don't pick option 1 which will break existing scores already notating dynamics in different voices; a completely valid use.
And the solution to option 2 already exists: there already is a dropdown that lets you select the range of the dynamic (staff/instrument). The only addition it needs is the "voice" option.
In reply to Yes, they are notated above… by jeetee
The staff/instrument option affects playback only. The OP's issue is with inconsistencies in the behaviour of the notation. I don't see how adding a voice option to the inspector drop down could deal with that.
In reply to The staff/instrument option… by SteveBlower
Because notation can just as much adhere to that setting
In reply to Because notation can just as… by jeetee
I think you would also need buttons to specify which voice the dynamic belongs to, wouldn't you?
In reply to I think you would also need… by SteveBlower
the one you applied it to, of course. Dynamics know that and show via their color and in the voice selection toolbar
In reply to the one you applied it to? by Jojo-Schmitz
The proposal was "2) an option (CTRL + dynamics /or hairpins, or whatever/) if I want different dynamics for voice one and two (this could be nice enhacement)"
So at this stage of CTRL+dynamic...) the dynamic is not yet assigned to a voice, if I understand the proposal correctly and nothing in the proposal says how it would be assigned.
Then the suggestion was made "the solution to option 2 already exists: there already is a dropdown that lets you select the range of the dynamic (staff/instrument). The only addition it needs is the "voice" option."
Which also does not help with specifying which voice the dynamic will belong to. And hence my suggestion of buttons to do that, but really I think there might be better ways still.
In reply to The proposal was "2) an… by SteveBlower
Sorry.. I assumed that when proposing implementation details you'd be more familiar with the current implementation.
As you could see in the video, adding dynamics already depends on the voice of the note you add them into, so yes, there the only missing thing is indicating it should only apply to that voice.
As mentioned in the linked issue as well, it is there assumed that you add the hairpin to notes of the correct voice. Or if you've added it into voice 1, then you'd change the voice of it in the same way that you change the assigned voice on any other notated element (such as notes); press the correct voice button in the toolbar.
So what you're suggesting is already there. There is no need for an enhancement to enter a dynamic in a voice as you already can enter a dynamic in a voice (which is part of the original post even!)
In reply to Sorry.. I assumed that when… by jeetee
Yes, I do understand that dynamics can be attached to individual voices. It is just that Samik's proposal seems to start at the attaching a dynamic/hairpin point. With a dynamic one usually selects a note in one voice but can equally select notes in both voices and end up with two dynamics. With a hairpin, if you select a range with two voices and then click on the hairpin you get one hairpin attached to voice 1. I assumed that the proposal was to fix that last case to attach a hairpin or to a single voice or to both voices in which case there needs to be something to specify which voice(s) it (/they) need to be attached to.
Perhaps what is missing then is:
0) select a range in one voice.
Or perhaps I need to read more slowly :-)
In reply to Yes, they are notated above… by jeetee
And the solution to option 2 already exists: there already is a dropdown that lets you select the range of the dynamic (staff/instrument). The only addition it needs is the "voice" option.
How does this relate to the voice of the dynamic? If I have a P on voice 1 and a ff on voice 2, both with Dynamic range set Part, what will happen?
In reply to And the solution to option 2… by njvdberg
if set to part they will apply to part, simple as that
In reply to if set to part they will… by Jojo-Schmitz
But the problem is both will apply to the part, so who will win?
In reply to But the problem is both will… by njvdberg
Again.. same as it is now, both will be linked and the last one wins.
In reply to And the solution to option 2… by njvdberg
The same thing that is currently happening, so when in doubt, try it out.
The "last one" will win if both of them are entered on the same time position.
In reply to The same thing that is… by jeetee
From an user point of view this look very odd and for an user it easily leads to a kind of "randomness" in behavior because most likely (s)he won't use the same order at all places so different measure, which will look exactly the same, will behave differently.
When it comes to part generating, I trust the program and will not check each and every detail whether it is copied correct or not. If this "random" behavior, caused by the "last one wins" is propagated to the generated parts, a rethink of this idea should be considered.
In reply to From an user point of view… by njvdberg
From a user point of view, this is already happening; regardless of whether the voice-to-part is added and the voice-specific range is added.
Currently it is even possible to add multiple dynamics to the same note in the same voice. I do feel that , next to the voice-range for dynamics and additional improvement argument can be made for having dynamics replace each other if their applied range overlaps.
In reply to From a user point of view,… by jeetee
I'm not familiar with dynamic ranges at all but is it true they have no relation with part generation? At least I can't get it working. Whatever dynamic range I choose, it won't show up in all parts.
In reply to I'm not familiar with… by njvdberg
that is a separate bug then. a dynamic or hairpin set to system should go to all parts
In reply to that is a separate bug then… by Jojo-Schmitz
Is this actually a manifestation of #297444: Hairpin attached to note other than in voice 1 in score appears on wrong part?
In reply to Us this actually a… by SteveBlower
@SteveBlower: #297444: Hairpin attached to note other than in voice 1 in score appears on wrong part is not about dynamic range but look very similar to this one.
In reply to @SteveBlower: #297444:… by njvdberg
Indeed. I am not sure how connected they are though. I think your comment about mission creep is on the right track about underlying causes. If a feature can be abused, it will be, and sometimes the results are less than optimal.
In reply to that is a separate bug then… by Jojo-Schmitz
@Jojo-Schmitz: That explain why didn't understand the concept of dynamic range. A quick check through the code shows it seems to be used
rendermidi.cpp
only. So, it seems its intentional use is for pay-back, not for notation (and therefor part generation).Is partly implemented or is there a kind of "function creep" where this concept is used for other usage too?
In reply to That explain why didn't… by njvdberg
It was not considered when the voice-to-part feature got hastily added. I wouldn't be surprised if more bugs/incomplete things pop up once you start looking into how items are linked there.
In reply to I actoually dont remember, I… by sammik
According Behind Bars (p 323):
Dynamics for independent lines on the same stave should placed at the stem end of each part. It is very important, especially in complex notation, that they are as close to their parts as possible, so not to be overlooked.
This opens an alternative for adding voice dependent hairpins, instead of selecting begin/end segment for hairpins, select the first and last stem/note. If the selection are segments, create a single hairpin for all voices, if the selection are notes/stems, create a voice dependent hairpin.
Relates to #296009: [EPIC] Issues with linked parts of individual voices
And to #58031: Dynamics/hairpin range for Voice
Sorry for long comment.
I will try to sum this ideas. (Oh, I hate to write these essays.) There are two point of view to this problem. One is „musical“, how we use to read, write and understand sheet music, and second, how to implement it to program.
In „real world“, as far, as I know, it is "standard" most common practise, to have dynamics assigned to staff. (Orchestral scores, piano scores, …)
I see few exceptions – Vocal comressed SATB score, and may be some Contemporary music.
Therefore, for me, it does make a sense, to be default behaviour, to have dynamics (and hairpins, texts, and so on …) assigned to staff.
Nowadays, this is not possible in actual version of musescore.
DHTS (dynamics, hairpins, texts, ...) is assigned inconsistently, byt idea probalby is, to assign them to voice.
Dynamic range looks promising, but it doesnt seem to affect notation.
How it is now
(voice dynamic works in parts only if it was created before generating parts)
Creating DHTS
dynamic:
- dynamic is created to each selected voice
hairpins:
- if multiple voices are selected, only one (voice one) hairpin is created
- if only one voice is selected, hiarpin is created to that voice, if it is created by keybord, but if you create hairpin by pallette, it is always assigned to voice one
When generating parts
- dynamic is reperoduced to parts coresponding to voices
- voice one hairpins are reproduced to all parts
- voice two hairpins are reproduced only to coresponding part two
When parts are created
dynamics:
- adding dynamic to score produces dynamic to all parts (it doesnt care, which voice is it)
- removing parts from score will remove it from corresponding part, if dynamic was created befor generating parts. If dynamic was added after generating parts, removing it from score removes it from all parts
- removing dynamic from part removes it from coresponding voice of score, if dynamic was created before generating parts. If dynamic was added after generating parts, removing from part causes removing from all parts and score.
hairpins:
- adding hairpins to score produced hairpins in all parts (it doesnt care, which voice is it)
- removing hairpins from score removes it from all parts
- removing hairpins removes it from score and all parts
What to do?
If I leave asside current inconsistency, I think, correct behaviour would be:
1) If DHTS is assigned to staff:
a) when one generate parts from voices, DHTS created in score will be reproduced in all parts created from multiple voices
when parts are already created:
b) adding DHTS to score will be aplied to all parts
c) adding DHTS to part will reproduce it to score and all parts
2) If DHTS is assignet to voice:
a) when one generate parts from voices, DHTS created in score will be reproduced only in part, created from coresponding voice
when parts are already created:
b) adding DHTS to score will be aplied to coresponding part
c) adding DHTS to part will be reproduced to corresponding voice in score
General setting should by, that DHTS will be assigned to staff as by default (as it is most common practise in real world)
- this wouldnt affect existing scores, as this would be new feature
- users would have option to change this default behaviour to Generally set, DHTS will be assigned to voice by default (in Preferences - advanced, or in Style settings)
3) If DHTS will be generally assigned to staff (in Settings)
a) only one, „staff DHTS“ is produced, even, if multiple voices are selected
b) one can assign DHTS to voice, by some extra key, for example CTRL (so CTRL + Dynamic will produce dynamic assigned to voice), if multiple voices are selected, DHTS will be created to each voice
4) If DHTS will be generally assigned to voice (in Settings)
a) multiple DHTS are created, one for each voce
b) one can assign it to staff by some extra key, for example CTRL (so CTRL + Dynamic will produce dynamic assigned to staff), if multiple voices are selected, CTRL + DHTS will produce only one, „staff DHTS“
In reply to Sorry for long comment. I… by sammik
A long comment indeed :-) but nice to have this overview.
I agree with your statement that it "standard" to assign dynamics to the staff. As a matter of fact, Gould states if a voice part requires separate dynamics, then it is best to place all voices on separate staves since it is confusing to have two set of dynamics for one stave. I'm afraid to think of having 4 voices with different dynamics :-).
For your proposal, I have to look more closely into it but at a first glance seems good to me.
But I like to add another point, how will things be stored in the mscx file and how about compatibility, both what happens if an older file is loaded in a version supporting this feature and what happens is a file with this feature is loaded into an older version of MuseScore.
In reply to A long comment indeed :-)… by njvdberg
I am not sure, if new version of file needs to be compatibile with older version of program. (v3 scores are not compatibile with v2 program, at least). So if this would be serious complication, you can simple leave it for v4 release (or 3.5, I dont know rules).
Here are some file templates, to compare, what could be saved in files.
As an instrumentalist, I imagined real life situation. I creates orchestra score (oboe parts are in one staff). When I tried to create parts, I found a bug – parts are wrong. I have trhee options.
- I will save it, as it is and wait for fixed release – I have only working score, not parts yet
- I will remove remove dynamic, and write it again back into voice 1 (after parts are created) – I have saved working score and parts
- I will remove parts, add dynamics into voice 2 and recreate parts again – I have saved working score and parts
Option 3 is same, as I have compressed SATB score with separate dynamics.
I dont have deep knowladge enough, I compared files and for me it seems to be promising.
In reply to Sorry for long comment. I… by sammik
Here is ilustration, to easier sum current behaviour:
hairpin in voice 1 always behave as staff hairpin
hairpin in voice 2 always behave as voice hairpin
dynamic in voice 1 behave as voice dynamics, if is added before creating parts
dynamic in voice 1 behave as staff dynamic, if is added after creating parts
dynamic in voice 2 always behave as voice dynamic
In reply to Here is ilustration, to… by sammik
Now in #304456: Inconsistent behaviour with dynamics and hairpins, when use parts from voices
#304456: Inconsistent behaviour with dynamics and hairpins, when use parts from voices
In reply to #304456: Inconsistent… by sammik
I also have question regarding dynamic range. First of all, is it correct I should read "scope"? In that case it makes some more sense.
Next, the values System, Staff (and the proposed Voice) I understand, but what does Part means?
@sammik, thank for nice overview, it helps to figure out what the problem is and how to solve it. I think I might have a solution but gave to think a little more to see all nasty details 😊
In reply to Just for my curiosity, … by njvdberg
Range, span or scope, yes, I like the latter term better.
Part or Instrument, so 2 staves for Piano. Unfortunately "Part" is a multi-purpose word...
In reply to Range or score, yes, I line… by Jojo-Schmitz
Thanks, that makes sense, that also explains the order.
What is by the way the best place to come with a new proposal? A new issue, linking to these issues?
In reply to Thanks, that makes sense,… by njvdberg
Probably a new issue, not sure though. Isn't it covered by the existing ones?
In reply to Range or score, yes, I line… by Jojo-Schmitz
Indeed, "part" is certainly misleading in this context. A part (as in file>parts ...) could consist of staves for Flute 1 and Flute 2. Setting the "scope" to "part" surely shouldn't force identical dynamics for both staves in that case. "Instrument" might be a better choice, but still not ideal. In my example we have two instances if a Flute "instrument". As ever, the devil is in the detail of the nomenclature.
In reply to Indeed, "part" is certainly… by SteveBlower
These are 'linked parts' (internal name is 'excerpt', and not to be confused with linked staves). And 'instrument' doesn't cut it either, think human voice. And indeed flute 1 and 2 on one staff. or closed score SATB
It is quite silent here but that doesn't mean there is no progress.
In what I'm working on, I differentiate two modes. In the staff-based mode parts will be created by copying complete staffs. Next will there be the voice-to-part mode where parts will be created based on voices instead of parts. This means for all dynamics a scope has to be specified, the dynamic range. I used previous work from Jojo-Schmitz to extend the dynamic range with Voice.
Current status is Extract Parts is obeying this dynamic range, in both staff-based and voice-to-parts.
Interesting question is what to do when on a part the dynamic range is changed. This can created a nice paradox. Suppose on the master score Part-1 have a dynamic with dynamic range System. This means this dynamic will appear on the part of Part-2. If now somebody changes to dynamic range to something else, e.g. Staff, this will be propagated to the master score but that means this dynamic should be on Part-2 at all. (Looks a little like travelling back in time and kill your parents, what will happen with you? :-))
For now I have no answer yet. Any ideas are welcome.
In reply to It is quite silent here but… by njvdberg
Hy Niek. May be a little offtopic at the beginig - this is exactly, what I was thinking about, when we were speaking about system lines (as option in inspector).
How is this adapted in lines (and texts): system - staff switch?
Back to dynamics. For me (user point of view), it seems to be more complex question, which requires many things to define first.
In my opinion, there is no reason to be able to change dynamic range.
It is important, to be able to set apropriate renge. But once dynamic is created, option to change its range would cause so many problems (one of them you described in your post), that I would drop this feature (changing range). If user want to change range, he always can delete dynamic and create new with range he wants.
Exactly this way, I think, it is also with system/staff text. You dont have option to change staff text to system, and vice versa, once it is created. I didnt see requests to change this behaviour.
To discuss it deeple, we need to know some basic things. How is dynamis to element? There are two possible scenrios (at least):
1) dynamic is assigned to element, depending its range (voice dynamic is assignet to voice, staff to staff, system to system)
2)dynamic is assigned to bottom level (always to voice), butt affects other elements, depending its range (voice dynamic affect only voice, staff dynamic affects all voices in staff, system dynamic affects all voices in all staffs in system, but still is assigned to bottom level - voice)
Each of this scenarios causes different behaviour (in creating parts, changing dynamic range, ...), each of scenarios have some advanteges and dissadvanteges.
And also, we need to remember to one "special" range - "part" for groupped staff (piano score).