MuseScore 4: per-staff dynamics in multi-staff part
In MuseScore 3 there was the ability to add a dynamic that only applied to a single staff in a multi-staff part (for purposes of audio rendering), by opening the inspector and changing the "Dynamic Range" attribute from "part" to "staff". There doesn't seem to be the ability to do that in MuseScore 4, and when importing existing scores from MuseScore 3 that use this feature, the feature no longer works (it appears to always apply any dynamic to both staves).
Comments
I'm having the exact same issue. I used it for my scores but, now, the only solution seems to be to add dynamics to every note individually.
In reply to I'm having the exact same… by ktlel
And, for me, even that barely seems to work. I don't hear ANY difference in dynamics when I change the velocity at which a note is played.
Does anyone know when this feature will be implemented? I need it quite a lot...
In reply to Does anyone know when this… by Max Richard
https://github.com/musescore/MuseScore/issues/22175
I'm having the same issue. Was startled when both clefs of the piano started playing fortississimo instead of just the bass staff
Another workaround (if you don't need cross-staff notation) is to split the score into two 1-staved instruments instead of the one 2-staved instrument.
In reply to Another workaround (if you… by jeetee
cite: Another workaround (if you don't need cross-staff notation) is to split the score into two 1-staved instruments instead of the one 2-staved instrument.
They can't do other things either, like arpeggios between staves. So unfortunately this is not a solution.
Yes, that's my big problem too. Where can this deficiency be reported? I use MuseScore to create background midi files and now it's completely unusable.
In reply to Yes, that's my big problem… by Petr Mach
Already reported (read above)
It is by design that playback settings are removed from dynamics. The new design is, all playback settings belong to the notes themselves. So make your adjustments there instead. Note Muse Sounds currently doesn't support this but should in a coming update,
In reply to It is by design that… by Marc Sabatella
Like I'm supposed to set the velocities of several hundred notes instead of setting one dynamic? That was meant as a joke, I hope.
In reply to Like I'm supposed to set the… by Petr Mach
You can set the notes of as many notes at once as you like - just select them all then change their velocity together. It's not a joke, it how the new design works. Currently you need to use the Properties panel for this, in the future the plan is to provide a "volume lane" for making these sorts of changes using more powerful controls.
In reply to You can set the notes of as… by Marc Sabatella
It makes logical sense that the dynamics are attached to notes, but from a practical point of view, it is really vital that there is an automation lane as you mention, otherwise it becomes impossibly tedious to edit individual notes if your music has, e.g. lots of crescendos/hairpins. It would be extraordinarily handy if the automation lane could at least be initialized from the dynamics that are placed in the score, and even better if that could happen on a per-staff basis.
In reply to It makes logical sense that… by cosmichorror
The people designing the new system have extensive experience with notation and DAW software and with user interface design in general, so I think safe to assume it will work well for the intended purpose. Right now is just an intermediate step toward that goal.
In reply to The people designing the new… by Marc Sabatella
Do they? Because, from what I'm seeing, they have negative experience in UX, and general common sense. When I'm working with multiple voices, yes I want individual control, as I also want general control - exactly how MuseScore 3 provided it. MuseScore 4 is a regressive MuseScore 3 with a more prominent soundfont.
In reply to Do they? Because, from what… by JordyGSmiteP
JordyGSmiteP, MuseScore 4 has regressed from MuseScore 3 mildly because they have taken a completely new approach to the design of the software. MuseScore 3 was very inefficient in the behind-the-scenes design and was very complex and impractical for the programmers to manoeuvre about when making changes. MuseScore 4 has regressed, but it should hopefully only be for the short-term as the structure of the new software allows for a much broader potential of future changes.
In reply to JordyGSmiteP, MuseScore 4… by Jonathan Liu Penman
Well, yeah, so now the programmers have it easier, but the program is stupid, it doesn't do what it's supposed to do, and we musicians have switched to alternative software.
In reply to Well, yeah, so now the… by Petr Mach
Can you explain in more detail which feature you feel is not working as it should? Did you open an issue on GitHub to report it?
Anyhow, as discussed, yes, some old inefficient and clumsy features have been cleared away to make room for vastly improved versions. It’s like remodeling a bathroom - you sometimes need to remove some of the old to make room for the new.
In reply to Do they? Because, from what… by JordyGSmiteP
I’m not sure what you mean, but you continue to have control over multiple voices, and starting with 4.2 - due out within the next couple of months or so - you’ll be able to add dynamics per voice (something never possible before). And then in a release after that, you’ll have graphical automation lanes - another giant leap forward. It’s true a couple of things had to be temporarily cleared out of the way to make all this advancement possible. But make no mistake, it’s moving forward.
In reply to I’m not sure what you mean,… by Marc Sabatella
Hooray for 4.2, maybe I'll be able to finally use MS4 instead of MS3, but I'll probably never switch until I can simply control the volume of a dynamic marking (like setting a mf to 100 velocity instead of the default 80). You talk of the automation lanes, so I guess I will continue to wait.
In reply to Hooray for 4.2, maybe I'll… by Leo Schunn
I quite lost my interest in MU4 to be honest. As I see it, there is too much regression and too little attention to fix it. There has not even been a serious attempt to investigate all regression that has occured with the update. In fact most of the reports have been made by users that found regression by chance. Github lists almost 200 regression issues from MU3. There is probably more if someone would actually look for it. If one regression would be fixed per week, which seems impossible, it would still take 4 years to turn MU4 into a better software. I would gladly help to raise money via patreon or something similar to hire additional programmers just to address this problem. But unless I see a clear commitment to this, I'll stick with MU3. MU4 can still be a great playback engine to use in conjunction for the time being.
In reply to I quite lost my interest in… by oMrSmith
You still don't understand what I understood a year ago. This is not a mistake due to lack of resources, some oversight. These features were disabled on purpose. And now we know why, the project is ruled by programmers and they didn't want to do it, it's unnecessary complexity for them. It's 99 % an irreversible design decision, a flawed data model, so it's unfixable. The likely author of this decision will be here for years convincing you that they don't understand your requirement and that it's not needed, and that you can adjust the dynamics for each note individually or change the volume on playback (which is not the same thing, it has different results, but they don't care, they're programmers). Fixing this would mean starting over, muse score 5. So either you accept it, or you stay with the dead unmaintained muse score 3, or like me you switch to an alternative product that respects the musicians need.
In reply to You still don't understand… by Petr Mach
There's my Mu3.7 ;-)
In reply to You still don't understand… by Petr Mach
It's true that certain features relating to the old-style MIDI method of velocity customization were removed on purpose to make room for the vastly superior system to come. So if you are one of the small percentage of users who relied on those features, by all means, continue to use MU3 while the new systems are being developed, and meanwhile the vsast majority can continue to enjoy the incredible advances in MU4. Everyone wins!
But for the record, the project used to be "ruled by programmers", but this hasn't been true for some years. The primary decisions are now made by professional musicians who are also professional software design experts with extensive experience in the use of a wide range of music and audio software products.
In reply to It's true that certain… by Marc Sabatella
You can't do better than respect the notation system. MuseScore is unusable, everyone I know personally has stopped using it and moved on to something else that works, especially Notion, or large commercial notation software. As I wrote a year ago, you've destroyed what was good in MuseScore (3) and are trying to replace it with something that's good for daw, not for notation. And even after a year you are still arrogantly telling unhappy 'not yet' users that it's better. It isn't.
In reply to You can't do better than… by Petr Mach
Sorry to hear you are having trouble using MuseScore 4! Far from being :unusbalke", it's an incredibly powerful professional-quality tool used by millions, and it's definitely better than MU3 for the vast majority of use cases.
But indeed, as noted, a small minority of use cases may still require MU3 currently. As also explained, the plans in the works are to make it far better than ever before for all use cases, so you can expect to see those changes being rolled out over the next coupe of updates. Again, this just required clearing out some of the old MIDI-based stuff that won't be compatible with the new system. But certainly there shouldn't have been any need to switch programs if MU3 was working for you - it still works today!
In reply to I quite lost my interest in… by oMrSmith
Full list of regression vs Mu3:
https://github.com/musescore/MuseScore/issues?q=is%3Aissue+is%3Aopen+so…
Assuming every related issue got tagged accordingly, that is...
In reply to I quite lost my interest in… by oMrSmith
I don't understand what you mean - there have been hundreds of bugs fixed since the initial release, with more every day. Yes, there are still some bugs in MU4 not in MU3 - and vice versa is also true. Is there a specific bug preventing you from using MU4?
In reply to Hooray for 4.2, maybe I'll… by Leo Schunn
Just because you were forced to resort to that method in the past because it was the only method available, doesn't mean it's really the best design possible. The new system will be vastly superior.
In reply to Just because you were forced… by Marc Sabatella
Marc,
Maybe the new system will be vastly superior but we have to work now.
And please don't ask again and again what is not working in MS4 and why we use MS3 now.
In reply to Marc, Maybe the new system… by Johan-v
Indeed, so if you are one of those who relies on something currently not supported in MU4, you are of course free to use MU3 in the mean time.
But I won't stop offering to help users. if someone expresses that they are having some sort of difficulty with MU4 but doesn't say exactly what the problem is, I consider it my privilege and duty to help them by finding out what specifically they are having trouble with. That way, I can assist them in finding a solution - either the new version of the old feature they simply didn't know how to find, or a workaround to accomplish the same goal a different way, or in delivering the good news that the issue they were encountering has already been addressed since the last time they checked.
I also will not stop performing the important function for the good of the community as a whole of making sure the issue has been reported on GitHub. So again, when someone expresses they are having some sort of issue but aren't specific about it, it is absolutely imperative that someone ask for further details, for the good of everyone.
In reply to You can set the notes of as… by Marc Sabatella
Oh god, you've ruined what was good about MuseScore.
'Volume lane' is nonsense in notation, it is suitable for DAW in piano roll scheme. Will you have a volume lane under each stave, like in a DAW under each track?
If not, it's wrong (you won't be able to see the volume progression for each stave), if yes, it's also a waste (because it's confusing, because in DAW I can display the track as one line that fits the width of the screen, that you can't do it with the staff).
I have several DAWs. If I wanted to use a DAW, I'd use Waveform Pro, for example. But I want to write sheet music, not use a DAW. And then I need those notes to play as written, not according to some invisible independent setting.
Who will keep it in sync? After a few edits, the notes will play differently than they are written. I was happy that MuseScore started to apply other music tags when playing, such as ritarando, this is a step in the right direction. The fact that he stops applying other musical marks, such as dynamics, is very bad.
In reply to Oh god, you've ruined what… by Petr Mach
I'm not understanding the distinction you are making here between changing an "invisible independent setting" in the Inspector in MuseScore 3 versus changing a different "invisible independent setting" in a volume lane. Either way, the score as written is the starting point, and you have the option of tweaking the playback further through "invisible independent settings". Only difference is what specifically you click to access them. And since the new system hasn't been designed or implemented yet, it's a bit early to assume it won't be one that works well :-) Maybe don't judge it until you've seen it...
In reply to I'm not understanding the… by Marc Sabatella
When I set one dynamic for a piano part, I expect it to be applied to both staffs (right and left hand). When I set up two dynamics, each for one staff, I expect them to each apply to their own staff. This can be achieved in MuseScore 3, it's intuitive and visible, and I don't have to set individual notes in any way. It cannot be set in MuseScore 4 and you say that I should set each note individually. This is invisible. it has nothing to do with the musical 'mark'. After a few tweaks and editing of the notes, each one will play at a high volume and the notes will not respond to changes in dynamics written in the notes.
MuseScore should always respect written notes when playing notes. The playback settings should not go beyond the musical interpretation of the notes.
That is, it should be possible, for example, to set the relationship between the music mark of dynamics and the midi velocity, because different sound banks can react to velocities a little differently, and the velocities need to be adapted to the bank so that the music sounds natural. Or we can set the length of the fermata, since it is not specified exactly how long it should be.
But one should never sound anything that is not written in the notes or even contradicts the written notes. And that's because it's invisibly (invisibly in the notes) set in hundreds of places. That is, to set the volume of each note separately and then ignore the dynamics written in the notes, this is an extremely bad approach to the matter.
In reply to When I set one dynamic for a… by Petr Mach
What makes you think dynamics are not currently respected, or wouldn't be respected in an as-yet-to-be-designed volume lane feature? Do you think the people designing this are not also musicians and wouldn't understand these basic needs?
In reply to What makes you think… by Marc Sabatella
Because you yourself stated it. And because you're turning MuseScore into another dozen DAWs, of which there are dozens, and you're throwing away what made MuseScore unique.
I'm sorry, I'll have to look for another product that will be able to play the notes the way I wrote them. MuseScore 4.0 can't do that, and that's too bad, and it's not considered a bug by your mouth, but a feature.
If on principle you do not intend to respect the dynamics written in the notes, then no instrument will fix it. You have simply ruined a good program.
Hopefully Sybelius can handle it, I can't think of any other alternative. So I can stop paying the subscription for musescore.com.
In reply to Because you yourself stated… by Petr Mach
I stated no such thing. Not sure what part of what I wrote you misunderstood. But anyhow, currently dynamics are honored. Not sure where you got the idea that they aren't, but that's just fall out 100% incorrect.
And neither of knows what the new design will look like, so it's pointless to argue about what you assume it might not do well.
In reply to I stated no such thing. Not… by Marc Sabatella
cite: It is by design that playback settings are removed from dynamics. The new design is, all playback settings belong to the notes themselves.
If I set the dynamics for the right hand and the left hand, it is not honored. And the solution should be that I set the velocities for each note individually. That's the design you described, and it's a bad design. You need to be able to set the dynamics. And both which staves it should be applied to, as well as the specific midi velocity value.
In reply to cite: It is by design that… by Petr Mach
Yes, but that never worked by default in MU3 either - you needed to fiddle with an "invisible independent setting" in the Inspector to get that to work also, because of course the norm in piano music is that dynamics affect both hands. So you sim;ply need to change a different "invisible independent setting" now. As mentioned, currently it's done by the Properties panel, but in a coming update it will be by a far more powerful tool.
So again, it's already possible now, and will become more powerful and more flexible in the future. no need to learn some completely new software whcih will also require some new and different method from how MU3 did it.
In reply to Yes, but that never worked… by Marc Sabatella
It is not true. In MuseScore 3 I could see whether I was using dynamics for each staff separately or one for both, it was visible. And that's why MuseScore 3 reacted to every change in dynamics in the notes.
It doesn't work in MuseScore 4, I have to set hundreds of individual notes individually, I can't see how they are set in the notes, and MuseScore 4 no longer reacts to changing the dynamics in the notes. Something other than what is written in the sheet music is played and changes in the sheet music are ignored. And that's a huge bummer.
This makes MuseScore 4 an unusable tool because it requires the user to always remember how to set which note, otherwise they will not be able to edit the notes properly. And this is impossible, so it will lead to hidden errors. I have about 250 scores in MuseScore and sometimes I adapt and edit them. More than half are for piano. Until MuseScore 4 can play back what it has written in the sheet music, I won't be using it.
Are you the official spokesperson for this product? Can I trust that this horrible design flaw will never be fixed because you're going to pass it off as intentional? If that's the case, I don't have to wait for a fix and can switch to another tool now.
With keyboard instruments, it is common for each hand to play a different dynamic. Dynamics is one of the basic musical means of expression. A tool that can't work well with it is useless.
In reply to It is not true. In MuseScore… by Petr Mach
I am not an official spokesperson, I am just a volunteer user trying to help people use the software. I'd love to help you understand how to use the software as well, and to ease your fears about the coming system.
Anyhow, no, in MuseScore 3 you most definitely could not see just by looking at your score whether a dynamic marking affects only a single staff or whether it affected the whole instrument. That information was hidden in a side panel called the Inspector. You needed to use that side panel to change the default settings in ways not visible on the score, if you wanted to control dynamics for two staves independently.
That is, putting an ff on one staff and a pp on the other most certainly did not cause MuseScore 3 to play what was written. It would either play both staves ff or both staves pp. If you wanted it to play what was written, you had to go to the side panel to change those invisible independent settings.
That's still true in MuseScore 4. Exactly as with MuseScore 3, it remains the case MuseScore 4 won't play one staff ff and one staff pp unless you change some invisible independent settings in a side panel. It's just different settings in a different side panel than it was in MuseScore 3.
Yes, it's different and takes a little getting used to. But no, it doesn't make it unusable. I'm using quite successfully myself. And again, I'd love to help you too.
In reply to I am not an official… by Marc Sabatella
So first I'll say, there was an awful lot of unmerited hostility in this thread, and I have a lot of respect for your continuing to respond in a calm and (attempted) helpful way!
I'm not going to claim to know how this future volume lane setup will work – for all I know it'll be great, whenever it shows up. I do think, though, that there were some meaningful concerns mentioned in here about the adjusting-volume-by-individual-notes flow that will apply until the new system does arrive (concerns which were not conveyed particularly well amidst all the hostility, I think) and I'd love to know if you know of workarounds for them. Namely:
I don't want to use the term unusable because I don't want to play into the combativeness that was happening here, but from what I can currently see, I don't really understand how I personally could use this interim system, particularly given the latter issue. Is there something I'm missing?
In reply to So first I'll say, there was… by Kloivier
A well-written, genuine comment, and it gets no response (at least from what I can see). Unfortunate.
In reply to A well-written, genuine… by therealunders
Sorry, this topic came up often and we wrote up tons of responses in various threads, sometimes one slips through the cracks.
I guess you’re asking specifically about the last post regarding crescendos? These actually work just fine in most cases. The velocity settings are relative, so a single value affects all notes through the crescendo.
The only care not handled well in the interim system is the rare cases of wanting crescendo in one staff only. For those you’d indeed need to set velocity per note, for now. The new automation lane system being designed will solve that case more elegantly as well.
In reply to I'm not understanding the… by Marc Sabatella
Is there anyway to see what the velocity each dynamic sets the notes to? Regardless of whether I put pianissimo or forte on the stave all the notes seem to always be at 64 velocity. It would be nice to be able to tell what value pianissimo sets the notes to so that we can then set the velocity for a stave manually ourselves.
In reply to Is there anyway to see what… by randomcat695
64 is a lie. It's just a convenient midpoint (within the MIDI range of 1-127) to mean "the same as the dynamic", and then you can turn it up or down from there. Think of it as a dial that goes from 1 to 127 and 64 is the middle point meaning, no change from what the dynamic is. Numbers larger than 64 mean louder than whatever the dynamic is, numbers smaller than 64 mean softer than whatever the dynamic is. So you don't need to actually know the values used by the dynamic to use this system.
It is expected that a come update will replace the 64 with a value that does in fact reflect the dynamic. That's all part of the long term plan mentioned, to get to the point of having "volume lanes" that will be more flexible and powerful than anything MuseScore has had before. Meanwhile, this is how you use it today.
In reply to You can set the notes of as… by Marc Sabatella
Any idea to when this will come out? It's been almost 10 months, surely they'd come out soon right?
In reply to Any idea to when this will… by kondsicc
It is in the works as we speak and planned to be part of 4.2, due end if this year
In reply to It is by design that… by Marc Sabatella
And it's not true, the dynamics set the playback volume. He just can't do it with the piano part for each stave separately.
In reply to And it's not true, the… by Petr Mach
In piano music, different dynamics per staff is quite common, in fact it is idiomatic of the instrument. Musescore 3 handled that quite nicely in playback. Musescore 4 currently does not, and, If I understand correctly what's been said above, that's by design and it never will.
I've noticed several apparent functional setbacks in the Musescore 4 in relation to Musecore 3, but I'm always ready to the discount my own "don't change my habits" syndrome and to allow some tolerance for a few bugs or even poor design decisions in an initial major release .
However, discarding the "per staff" property of a dynamics indication, if it's done consciously and on purpose, seems to me be a blatant case of gratuitously disregarding user needs.
In reply to In piano music, different… by josemdavid
It is simply not true that MuseScore 4 doesn't handle this. It most certainly just - just differently, as has been explained: by changing the notes themselves. To be honest, I personally also miss the ability to set it on dynamics, but the designers and developers made a good case that there was no advantage to having these settings in two different places. And a future update will provide additional controls that go above and beyond what MuseScore 3 could do.
In reply to It is simply not true that… by Marc Sabatella
There still doesn't seem to be a way of doing this 2 months later. "Changing the notes" is ridiculous since every time you add notes to a part you have to update them as well. There really needs to be a way of putting a "forte" in the upper staff and a "piano" in the lower staff and have the playback respect that.
Different dynamics per staff is not at all uncommon in piano music. It's a shame that musescore doesn't support it anymore.
In reply to There still doesn't seem to… by pommicket
Truth. And since the author of Musescore doesn't consider it a bug, I bought Notion for notation. A huge plus is that it has a solid editor for iPad and Android as well. https://www.presonus.com/products/Notion
In reply to There still doesn't seem to… by pommicket
It's a temporary situation that you would need to adjust notes added later. The plan for the future is to add an automation lane to let you easily specify volume changes graphically, and yes, they'd apply to newly added notes.
Separate dynamics for separate staves will likely come back as well.
What probably won't come back is the need to custom velocity settings on dynamics as well as custom settings on notes and then a separate control to specify how those two conflicting values interact.
In reply to It's a temporary situation… by Marc Sabatella
And that's why I switched to an instrument that respects musical notation.
In reply to And that's why I switched to… by Petr Mach
? I'm not understanding, In what way does what I wrote suggest MuseScore doesn't respect musical notation?
In reply to ? I'm not understanding, In… by Marc Sabatella
It does not respect the dynamic markers in the piano staves.
I don't understand how you can't understand that. People have been complaining about this for months. But I don't care, I voted with my feet.
In reply to It does not respect the… by Petr Mach
You mean, the fact that currently this limitation exists and requires a simple workaround? Indeed, I agree it's not ideal. but as I also explained, this is likely coming back. That's why I was confused when you said "that's why..." - the fact that it's likely coming back is surely good news?
In reply to You mean, the fact that… by Marc Sabatella
It is wrong to trivialize serious problems. There is no reasonable workaround for this. Your solution is completely useless for serious work. And you don't want to fix it either. For me, it was the reason to leave MuseScore after more than ten years and pay €500 for a serious tool. MuseScore was a well-designed tool, but now it's become a toy in the hands of people who don't take it seriously.
In reply to It is wrong to trivialize… by Petr Mach
Dude just use MuseScore3 or forget it, this is a free program that has years of work put into it, and I'd hope as someone who pursues music you'd have something better to do than fight this useless argument. I agree MS4 is scuffed as hell, but there's nothing to win here, move on.
In reply to Dude just use MuseScore3 or… by Leo Schunn
It's a free program that I've supported financially for years and paid several bills. I'm not the only one who left him in our community, so take this as feedback why solvent clients leave him.
In reply to It is wrong to trivialize… by Petr Mach
I'm not trivializing anything. I am simply helping people by showing the workaround (which is not complicated, takes only a few extra seconds) and assuring people that is only a temporary limitation - that the plan is for a much better system to come. And that much better system is being designed right now, precisely becuase the designer do take this seriously. I don't know where you got the idea that no one wants to improve this - of course we do, that's what I have been trying to explain here.
You can of course choose to spend money on a commercial program that doubtless has other limitations; that's your right.
In reply to I'm not trivializing… by Marc Sabatella
What you are showing here is not helping people, but denying the problem and mocking. You lack understanding and empathy. You messed up a good design and now you're trying to convince others that a bad design is good.
In reply to What you are showing here is… by Petr Mach
Agreed. And after months of complaints, I'm confused why it hasn't been fixed five times over by now. I love Muse Sounds, but the editor it comes with makes it almost not worth using. One thing I'd like to add though is that this person isn't an actual developer or designer, they're just answering on their behalf. You'd probably get a real answer by asking a real development team member.
In reply to Agreed. And after months of… by therealunders
As explained in various discussions, they want to develop a good rubust system that is a huge improvement over what was possible before. Developing temporary band-aid workarounds short term ends up being counterproductive long term, in that a) it takes design & development time away from the real solution, b) it creates more hacks to possibly need to support forever or else annoy people again when the hacks are removed. But a good robust automation lane feature takes time to design and implement, and won't be improved by rushing.
So meanwhile, the interim solution is sufficient for 99% of use cases. For the rare cases where the interim solution is not sufficient, one can use other workarounds (eg, creating two piano instruments of one staff each rather than one instrument of two staves), or just stick with MuseScore 3 a while longer. And the less time the developers need to spend working on yet more temporary interim workarounds, the less time users will need to wait for them to get the full solution done!
In reply to As explained in various… by Marc Sabatella
I'm sorry, but I really don't see how developing an automation lane, one of the most simplest features in existence, one that has already been developed time and time again, would take so long? I understand that there are other features being worked on, ones that are higher priority. So say that. And I assume your "99% of cases" doesn't account for crescendos and diminuendos? Those are extremely rare for sure. As someone else stated as well, two instruments of one staff doesn't work with arpeggiated chords and glissandos. Simply having staffs not be affected by a single dynamic in this build would have fixed this problem. If anything, making you write the dynamic twice like in Flat.io would've been much better, especially since, unlike in Flat, you can actually make things invisible.
In reply to I'm sorry, but I really don… by therealunders
Hmm, since it seems you have extensive experience in designing and implementing DAW features, you’re the perfect person to volunteer for the job! MuseScore is, of course, open source. So we welcome your contributions. I’ve contributed thousands of lines of code over the years, as many others - it’s how things get done.
For the record though, crescendos and diminuendos already work in general - they are part of the 99% of use cases that are already covered. Not sure what you mean about arpeggios or glissandi, but that sounds unrelated - best to start a new thread for questions about those.
In reply to Hmm, since it seems you have… by Marc Sabatella
As a matter of fact, if I was paid to, I'd gladly get the job done. Sadly, I'm not, so there goes that. Or if you gave people incentive, although I'm not sure I'd trust the word of a man who thinks "thousands of lines of code" is even worth mentioning. Things can quite easily "get done" without open-sourcing, like with, say, a team of developers. But hey, that's just my opinion. Of course, that's not to say I distrust open source code, of course not. I'm sure somebody with spare time and decent skills will come along and do something. Or heck, maybe that'll be me if I wanna take a break from composing and have an abundance of free time. Who knows?
Crescendos and diminuendos work, of course. But how about with this little solution you've mentioned? Do you really believe 99% of use cases don't have a crescendo in only one hand? And even if it was just 1%, a single four-bar phrase could be 100x the time wasted for setting every single note's velocity. Is that not worth mentioning? And arpeggios and glissandi aren't "unrelated," since if you mention another solution that breaks other features, that's not unrelated, oh no, that's hardly a solution.
Though of course, it's obviously pointless to keep talking about this since that won't make the team speed up. Well, talking to you is pointless anyhow with how often you dodge questions.
In reply to As a matter of fact, if I… by therealunders
I’m not sure which questions you think I am dodging. But for the record, if you check GitHub, you will see I have written well over 100,00 lines of code in MuseScore making me the second-most prolific contributor outside the core team.
If you’d like to apply for a job with the company, I’m sure there is a process for that. But the way open source works is, people actually do volunteer to work on it. Again, you’re welcome to join the effort.
Do I believe that 99% of music does not have a crescendo in only one hand? Yes, quite obviously true. Sample 1000 random measures across all instruments, styles, and genres and see how often you find this.
If there is a post you missed where you explained the relationship of dynamics to arpeggios, sorry I missed it. I have been so busy helping users, it’s hard to keep track of every single post.
Anyhow, again, better solutions are being designed. There is no point in continuing to argue about this.
If it helps any, you can change the velocity of any given set of notes by clicking the beginning of a selection of notes then shift+clicking the end and it will select all of the range in between, then in the properties tab you can change all of them in bulk.
What worked well for me regarding playback piano dynamics was to add 2 pianos and then remove the bass stave from one and the treble stave from the other. That way, i could independently control the dynamics of each remaining stave. However, this function seems also to have been removed. I don't see the point of removing the ability to delete one or other stave of a piano score?
In reply to What worked well for me… by GeorgeJay
This was not necessary, the volume could be set for each outline separately. With this procedure, you disabled the pedal, for example.
In reply to What worked well for me… by GeorgeJay
It's still possible, but it's in a different place. In the "Instruments" tab (not the Parts button in the menu bar!) you can use the "eye" icon to show or hide any part, or stave within a multi-stave part, or you can use the wastebasket icon to actually delete a part or stave.
I also thought about using different instruments for the treble and bass staves of a piano score in order to have correct playback of different dynamics per stave. But if the purpose is to produce an actual piano score, this has several inconvenients regarding the formating, so it's not worth the hassle of compromising good formatting to have more realistic playback. However I use this technique when I want to export a piano score to MIDI with each stave in a different MIDI track, I've done it MS 4 and it works.
I've tried setting different velocity for different staffs and it still just thumps the whole thing out in one dynamic. What do I do now?
Just wanted to comment on this to add visibility, the "new" way to do this seems less efficient and extremely unintuitive, would love if they brought back a simple toggle between "part" and "staff" that just acts as a shortcut for the "new" way to do it
In reply to Just wanted to comment on… by mundeepsa
Yeah same here, I've been transcribing some music recently and it's been frustrating having to split my piano parts into two instruments for the dynamics to work properly... hopefully they can re-implement that soon, it'd be helpful
I think being able to set the dynamic range for dynamic symbols was a good feature
and that it should not have been taken out but rather expanded to feature
a per-voice dynamic too. And I would prefere to add dynamic symbols rather than
drawing lanes. In the end of the day the musician will have to read the symbols too
and not the invinsable lanes.
In reply to I think being able to set… by oMrSmith
Of course you should still continue to add dynamics and these will continue to affect playback in the expected ways! The only question is how to go about overriding that playback. MU3 had a complex system where some settings were customized on the dynamic itself, other settings were customized on the notes, and then another setting entirely controlled how those two first two settings combined to yield the final velocity. MU4 simplifies that so all overrides are in the notes, and the then lane feature will simplify how how those settings are made.
Marc Sabatella is a hero responding to everyone here, but man I really hope this new volume thing is really great. I so badly want to use MuseScore4, but every time I start a new piece on it I realize more and more features were taken away that make my life a pain. I write for percussion parts, and there is literally no way to do multiple percussion instruments per staff easily now that you CAN'T SELECT MIDIs, just entire soundfonts. The fact that I can't select a mf and tell it to be velocity 70 instead of 64 is also brutal, and now not being able to simply apply dynamics to single staffs has really pushed me beyond trying anymore. I'm sure MS4 will be great someday because there is so many talented and wonderful people working on it, but that day is definitely is not now.
In reply to Marc Sabatella is a hero… by Leo Schunn
Hmm, I'm not understanding what you mean about multiple percussion parts on a single staff. That hasn't changed - you can continue to use a standard MIDI drumset, customize the pitches in Edit drumset, etc - same as always. You wouldn't normally be using separate soundfonts for different instruments on a single staff just to do percussion. Best to start a new thread and describe your problem in more detail so we can understand and assist better.
As for velocity, the new system being designed is expected to be graphical in nature - just draw in volume changes etc. Much nicer than fiddling with numbers. And no need to set some numbers on the dynamics, others on the notes, and have another settings still to control how those two notes interact. Everything is nicely centralized in the notes. That much is already the case.
In reply to Hmm, I'm not understanding… by Marc Sabatella
For the percussion thing, I've already checked threads and the answer is you currently cannot select individual MIDIs from a soundfont, so if I have, for example, the Sonatina Orchestra SF2 and I want to select the percussion MIDI included in the SF2, I cannot. I have to change between 20 percussion instruments praying that MS4 decides to let me use the percussion MIDI (which it hasn't, I had to give up). This will hopefully be changed in the future.
For the volume thing, I'm really going to miss changing the velocity of dynamics, but here's to hoping this new visual thing will solve all the problems manually entering numbers on note heads causes.
I don't understand a lot of what I read in this thread, but the takeaway for me is that you can no longer apply single-staff dynamics without playing around with individual notes (most likely as groups).
MuseScore 3 had a feature where I could apply "MF" to the top staff and "MP" to the bottom, and it played it back correctly. Apparently the absence of this feature is itself considered a feature instead of a bug, which is where I fail to understand how the downgrade ends up being advantageous. I'm trying my best to avoid venting here, but--said as calmly as I know how--MuseScore 3 was better in this regard, and if this new "not-a-bug" feature carries over into future versions of MuseScore, I'll be looking elsewhere.
They took what was very simple and made it more convoluted. At present, I would have to insert the dynamic markings I want, look up what the default velocity is for those individual markings (because the only velocity I get under properties is 64 regardless of the dynamic I use), and there I stall out because a solid 5 minutes of searching for said values turned up nothing. Even if I were to find them, I would then have to select the notes I want to change, and change their velocity to the appropriate value.
It's a lot of tedious work that takes away from my enjoyment of using MuseScore to practice music theory. I fail to understand the logic behind this decision, which I concede doesn't mean there isn't any, just that I don't understand it. Surely there's a way to maintain the feature from MuseScore 3 that achieves the same end result as MuseScore 4 with regard to whatever the issue is that makes this a supposed advantage?
In reply to I don't understand a lot of… by Rob Killam
You are correct that currently this isn't as simple; the old method has been removed to make room for an improved method yet to come. The old method wouldn't have been compatible with the new method being designed, that is why it could no longer be supported. The new method will be both simpler and more powerful than the old. The interim solutions is indeed more awkward to use the velocity adjustments for these cases, which is unfortunately, but again, the idea is that it will become better in the future in ways that would not have been feasible otherwise.
But FWIW, I'm not sure what the issue of having separate dynamics on different staves has to do with music theory? That's more something specific to composing for piano. Studying music theory doesn't depend on dynamics at all.
In reply to You are correct that… by Marc Sabatella
My use of the term "music theory" apparently provided too narrow an idea of what it is I do with MuseScore. I use MuseScore to study music, which often involves reproducing sheet music I find here and there as precisely as possible, in order to hear how it sounds. Until I can play sheet music on piano for myself, I rely on MuseScore to at least approximate how a song should sound. It's not often I come across sheet music with separate dynamics on different staffs for the same instrument, but I use the effect a fair bit in my own writing, and it's irritating they effectively broke this feature to where it's barely useable, with the promise of an upgrade later.
In reply to You are correct that… by Marc Sabatella
The "interim solution" does not appear to work - I have tried adjusting the the velocity for groups of notes in "Properties' and it does not alter the playback volume - it seems to default to a volume of 64 irrespective of any adjustment that is made - the only way I have been able to alter dynamics is by using the dynamics icons in the dynamics palette. Any ideas?
In reply to The "interim solution" does… by damienpower
Velocity is a MIDI thing and thus only works for soundfonts, not for Muse Sounds.
64 is always the default, but what that actually means is, it honors the current dynamic. Values greater than 64 will then be louder than the dynamic, values less than 64 will be softer.
In reply to Velocity is a MIDI thing and… by Marc Sabatella
Since we are talking about MIDI and Velocity in this topic, I will ask you to touch on one of the topics that no one has given me an answer to (unfortunately). Marc, do you know the answer to my questions in this topic? https://musescore.org/en/node/362558
I think this is a very important discussion (so it's not strange that it is quite heated) and I would like to add a few of my thoughts about the future dynamics system. I'm not related anyhow to MuseScore team. I just hope this is the way the new system will be done and I think that if it will be done in this way, the people from this discussion will be happy.
With only one layer of velocity numbers that are stored for each note, I can see this problem: if I annotate "forte" in the score and fine-tune the dynamics of some notes in this "forte" section and later change my mind and change "forte" to "piano", all my fine-tunings will be overridden.
Interpretation of music is a very subtle thing. All tempo and dynamics changes that a performer does (especially in the performance of classical music) can not be written in the score, even if the composer would like to do that because the score would then become too cluttered. Hence the score only shows the main aspects.
Because of this, it's clear that we actually need two separate layers: the first layer that corresponds to what is written in the score and the second layer that enables us to fine-tune things. The first layer contains absolute velocity numbers that are related to "piano", "forte", "crescendo", etc that are written in the score (either per grand staff, per upper/lower staff, or per voice in staff). The second layer contains relative velocity numbers like +15 or -10 (per each note) which superimpose (i.e. add) to the first layer.
The absolute velocity numbers in the first layer should be edited only by changing the properties of dynamic annotations in the score (like the absolute velocity of a certain "forte", or the type of curve of a certain "crescendo"). USERS MUST NOT BE ABLE TO CHANGE THESE VELOCITY NUMBERS PER SINGLE NOTE BECAUSE THEY ARE CALCULATED FROM THE PROPERTIES OF DYNAMICS ANNONATIONS IN THE SCORE. ONLY RELATIVE VELOCITY NUMBERS FROM THE SECOND LAYER CAN BE CHANGED BY USERS PER SINGLE NOTE.
In reply to I think this is a very… by hstanekovic
Also I think there is nothing wrong in visualizing dynamics, like in DAW, by using graphs (read only) and perhaps even ability to draw (write) in graphs, but writting should only change relative velocities from the second layer. Thus anytime user can execute "reset to what is written in the score" command to reset dynamics to absolute velocities from the first layer ie forget (set to zero) all fine-tunings in the second layer.
In reply to I think this is a very… by hstanekovic
I agree with this idea, that any individual note dynamics should ideally be relative to the written dynamic. Like how tuning works, where an adjustment in cents is added, but the note can still be changed to a different one while keeping that change.
Some of you are being so mean and unreasonable. This is FREE software developed out of the kindness of the Musescore team's heart, for you. Be grateful that we have this option at all. If you want more advanced features, just go and buy Dorico or something, but do it quietly without loudly announcing it on this forum as if you're publicly breaking up with someone you just caught cheating. No one hurt you, deliberately or otherwise. There's no need to be harsh and unkind toward the Musescore team. I am also looking forward to Musescore 5 or whatever where all these issues might be fixed, but aside from this comment I look forward quietly. I urge you to do the same. As a scientist who writes a lot of code, I know how difficult it is to write something as big as this without funding from software sales. Write your own free notation software if you're so upset. You'll learn a lot and gain more appreciation for the Musescore team's excellent work. For a start, try implementing a tie and slur system that avoids clashes as well as Musescore 4. Good luck. Hint: try constrained gradient descent with a cost function based on degree of clashes between elements. That might work if you do it right. But stop being mean now.
This thread is... something. I will not argue on the matter, I am here to give you a solution.
Problem: No per-staff dynamics in multi-staff instrument
Solution:
1. Create as many single-staffed instruments as there are staffs in desired multi-staff instrument.
2. Change all those instruments to desired multi-staff instrument.
3. Select proper accolade and clefs.
4. Enjoy!
It sounds a bit complicated, but I have done it in circa 30 seconds for piano multi-staff
Good news!
My issue was addressed:
https://github.com/musescore/MuseScore/issues/23884#event-13787565295
In the latest nightly of MuseScore 4.4, correct handling of old per staff (and now per voice) dynamics is back!
Go team.
OS: Windows 10 Version 2009 or later, Arch.: x86_64, MuseScore Studio version (64-bit): 4.4.0-242210305, revision: 23820f3
https://ftp.osuosl.org/pub/musescore-nightlies/windows/4x/nightly/MuseS…