Change dynamics during single note

• Apr 2, 2010 - 04:00
Reported version
3.0
Priority
P2 - Medium
Type
Functional
Frequency
Many
Severity
S5 - Suggestion
Reproducibility
Always
Status
closed
Regression
No
Workaround
No
Project

Is the a possible way to change in velocity in the middle of a note? I'd like to know right away.


Comments

There would be no way to change velocity as that refers to the attack, how quickly the key is depressed.

It appears that what you want is crescendo or diminuendo.

I think XavierJazz is right. What you are probably wanting is polyphonic or chanel aftertouch, which has yet to be implemented.

The way forward on this one is to implement the MIDI Expression Controller #11. Aftertouch is not the answer here as it takes more setting up whereas using Controller #11 works straight out of the box as this is exactly what it is for.

There would need to be an interface on dynamic markings, exactly as there currently is for velocity in which the Expression level could be set, with a default applied. Also a means of entering starting and ending values in the hairpin and crescendo/diminuendo elements.

I'm extremely interested to know the status of this one, particularly https://github.com/musescore/MuseScore/pull/2722 which looks like the most hopeful path forward on here, and looks to be basically ready to merge into the main code, but appears to have stalled (hopefully temporarily?) November 2016.

This is one of the main showstoppers to me using MuseScore, as I believe it will add a huge amount to the expressiveness of midi playback.

Does anyone know where it's at? Is there anything it's waiting on that could use help from someone (me, possibly)?

Hi @bryhoyt, I too deem this issue or feature at a high value, so I would like to share some comments

As we know, at some point, https://github.com/musescore/MuseScore/pull/2655 was discarded in favour of a more general approach.

But as there would be (possibly) a high delay while this (#2722) pull is being merged in main, I decided to build (for my own usage) the branch hpfmn submitted at the time (his "CC11" branch, which corresponds to the #2655 pull, see https://musescore.org/en/node/269847 for explanations and links). I see this feature is being delayed as time passes. I understand the reasons the developers explained, but, perhaps (in my opinion) that previous pull #2655 was far more easy to get merged into the main trunk for 3.0 (¿or 3.0-dev?)

That work (the #2655 pull from hpfmn's work) is usable and works very well so far, with the common soundfonts (FuildR3 Mono, Sonatina, and others. You can hear a sample piece I've wrote yesterday in https://clyp.it/2e3pytqi?token=8b6e96df79b35f5c160dd989cb59a78d) .

I'm not expert in programming, but I tried the current proposal (pull #2722) and didn't worked for me, due to crashing (explained in the thread above).

Hope this helps

Severity S5 - Suggestion S3 - Major

How is the current state of this? This is one of the oldest and most requested features, there is NO workaround regarding this and it's the single reason many people I know don't use MuseScore for composing.

What are the levels S1 and S2 for? Moreover, saying that it's not a bug is also relative. If I put a hairpin on a note and it doesn't change anything as expected for it to do, it is a kind of bug in practical terms.

In reply to by Ludwig van Benteuer

It's a suggestion because the behavior is by design. Those who wrote the program have not included code that will change the dynamic of a single note.

From the bug report instructions:

S1 - Blocker - The bug prevents a user from running/opening MuseScore.
S2 - Critical - The bug prevents the user from doing the intended action. They can’t go further. They're stopped. The bug prevents the user from using a key feature of MuseScore (e.g. layout, elements positions, mixer), there is no workaround, the business logic of a key feature doesn't work. There are security issues, data loss. If MuseScore crashes, it's critical.

For the record, the primary purpose of Musecore is notation, not playback. That is, getting printed music in the hands of human musicians.
If something you add to your score doesn't show up in your score properly, then that is a bug. If it shows up in the score but doesn't playback, that is a suggestion for an improvement. Unless it was intended to playback and doesn't, in which case it is indeed a bug, if not as serious as a bug affecting notation. In this case, though, it was never intended that these would affect playback.

It is certainly well-known that many people would like to see this particular improvement. It would have been great if MIDI had been designed to support this better from the beginning - then existing synthesizer code and soundfonts would be able to do this. But unfortunately, getting MIDI to deal with this requires jumping through some significant additional hoops. It's a pretty big re-architecting of how things are done in MuseScore to make this work, which is why it still hasn't happened. Someday, no doubt, it will happen.

Although note there has been a Pull Request available for 2.5 years, which apparently was ready to go at the time with relatively minor impact, and people could successfully build it. I imagine the code's shifted a fair bit in the meantime, so it may not be as close as it was.

Not intending to criticise the developers of MuseScore who are doing an awesome job, and I know from experience how hard it is to integrate features when there are a lot vying for priority.

But it would be awesome to see some real traction on PR https://github.com/musescore/MuseScore/pull/2722 !