Inconsistent behaviour with dynamics when creating parts from voices

• Apr 23, 2020 - 15:17

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:

Voices-parts_bug.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

• Apr 23, 2020 - 19:11

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.

Reply

• Apr 24, 2020 - 06:04

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)

Different_dynamics_in_voices.png

Reply

• Apr 24, 2020 - 09:19

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.

Reply

• Apr 24, 2020 - 11:01

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.

Reply

• Apr 24, 2020 - 11:34

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!)

Reply

• Apr 24, 2020 - 12:07

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 :-)

Reply

• Apr 24, 2020 - 12:35

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?

Reply

• Apr 24, 2020 - 17:51

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.

Reply

• Apr 24, 2020 - 18:10

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.

Reply

• Apr 24, 2020 - 19:36

@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?

Reply

• Apr 24, 2020 - 12:29

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.

Reply

• Apr 24, 2020 - 13:35

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“

Reply

• Apr 24, 2020 - 18:11

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.

Reply

• Apr 25, 2020 - 10:29

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.

Attachment Size
Orchestra1.mscx 20.16 KB
Orchestra2.mscx 20.54 KB
Orchestra3.mscx 21.09 KB
SATB.mscx 21.38 KB

Reply

• Apr 25, 2020 - 10:23

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
Voices-parts.png

Attachment Size
Voices-parts.mscx 43 KB

Reply

• Apr 26, 2020 - 16:58

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 😊

Reply

• Apr 26, 2020 - 17:15

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.

Reply

• May 17, 2020 - 11:44

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.

Reply

• May 18, 2020 - 17:49

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).

Reply

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