Human Touch (#2)

• Jul 5, 2019 - 21:55

I've been thinking for quite a long time about the possibility of MuseScore adding emphasis to music based on the metrical pulses of the beats of a measure.

When a child sings Happy Birthday, they almost instinctively do so with the Strong, Weak, Weak inflection that we recognize as 3/4 time. That same pulse lies under a Haydn minuet, a Strauss waltz, and a Chopin Polonaise. (though with differing weights of the stresses, and often with subtle and sophisticated treatment of the subdivision of the beats.) If the child sings Mary had a Little Lamb, they will do so with the Strong, Weak, Medium, Weak emphasis we instantly recognize as 4/4 time. We may call these the grooves of the music.

Unless we make manual adjustments to the score, MuseScore does not differentiate the stresses that underlie the different meters. If you enter four measures of eighth notes, each of those notes will have the same volume. It is possible, but very time consuming, to adjust the dynamics of the music on a note-by-note basis by editing the velocity value in the inspector or by adding invisible dynamic markings to each note.

What I am suggesting is kind of "Intelligent Groove" within MuseScore wherein you can select a score or a passage of music and assign a groove, which will then automatically adjust the stresses within the measure by a pre-determined set of values. You could perhaps have a knob or slider that allows the user to adjust the weight of the groove to suit the style of music. Some popular or dance grooves may have a particularly heavy feel, while others may be much more subtle. You could pre-set a known groove to a piece of music when you begin, or experiment and apply different grooves as you fine-tune your work.

If a child can do it, I'm sure we can convince the metrical clocks that power MuseScore to do it too.


Seems like a simple method of weight distribution should be an editable attribute per time-signature, or something of the sort. Something as simple as having a percentage-redux, defaulted but editable by the user of user-velocity between beats (any note value that falls not on a whole number as related to a beat, e.g. 1.5), would be tremendously useful as a beginning stage before any further individual velocity changes. Getting more fancy would allow for slight variation between main beats (like in 4/4: the first stress is the strongest, the 3rd slightly lesser, and the second and fourth the more weaker). Either way, this idea doesn't really seem too difficult to implement and should therefore be very much considered, or something like it, in near future

Although It may be more complicated than just applying an accent, applying a velocity increase to the note falling exactly on the first beat in most cases improves the metrical intelligibility (but not necessarily contributes a human touch). However, in many cases it will be necessary to change also the tempo of the first beat or fraction of beat (called agogic accent). I use much this approach manually but couldn't find so far a rule which would ensure in all cases, even corresponding to the same type or style of music, a satisfactory result. Seemingly, it also depends on the particular melody, on its rythmical variety, the size of the initial interval and probably many unidentified factors.

In reply to by fmiyara

Agogic accents and other functions that alter the timing of notes are part of a different discussion I initiated some time ago. (and which was quite summarily rejected.) For the record, I don't disagree with you.

This particular discussion is about the use of note volume to synthesize musical groove. At the time I was thinking of these things, I quite purposely separated the two concepts, though, in fact, they contribute to the same goal of having MS playback sound more human.

In reply to by toffle

I don't think I would say that your ideas were outright rejected, I don't think there is the general passion for this issue that you have. I'm not looking to replace human musicians, I just want a reasonable playback that gives me an idea of what I'm writing. I think the cool response you got on #1 is indicative of this mood. Of course, the forums are read and commented on by the same 20-30 people most of the time with an occasional visitor, so you are truly getting a small amount of feedback. Perhaps a discussion on Facebook would raise more interest in the subject.

In reply to by mike320

Don't get me wrong, Mike. I took the previous discussion exactly as you describe it. (and with absolute equanimity) I judged that there was little interest (passion) for the idea. As I always remind myself, the MS developers have much higher priorities just keeping the bugs at bay to waste time on a single user's pipe dream.

To be honest, in the other discussion, I was a little taken aback at the suggestion that any variance in timing by a human player was considered a mistake. But that is another discussion, and I am perfectly happy to let that lie.

In reply to by toffle

One of the issue with MuseScore development is that if it isn't perfect they don't do it. For example chord playback. For long years answer was no because humans would do this or that and automatic chord playback will never be able to approach that.
Of course I'm well aware that instead of complaining a more positive approach would be to submit PR. (And yes I know we'll soon get chord playback, could be the reason to finally use V3 instead of v2 for my daily work).

In reply to by frfancha

A nice thing about GSoC (that created chord playback) is that it is a paid internship for the student programmer. This is their incentive to do the work. Many GSoC projects haven't been merged or are still marked experimental. A volunteer programmer is not likely to do this work if there is no guarantee the code will be merged and exposed. The answer has not been no because the question was never officially asked. The problem is that no one was willing to put in the work to see if it will get accepted by lasonic and now Anatoly-os.

Since Anatoly-os had input into which projects would be accepted he's at least willing to consider merging the code but this is still not guaranteed if he deems the results to not be complete enough or too flawed to be exposed to everyone. BTW, I haven't heard a word of opinion from Anatoly-os about this or any 2019 project.

Melody and accompaniment makes accents on different strokes in same piece .

In Pop music: the melody emphasizes the first and third beat, while the rhythm-instrument's snare-drum constantly emphasizes second and fourth.
In sections B (chorus/refrain) : offbeats is emphasized in the ride-bell of the drum (second eights).
in Reggae and some south-american styles: offbeats emphasized by guitar.

In Latin American styles: bass and rhythm emphasize 2.5th and fourth beats.

in the Waltz: Melody emphasizes only the first beats but accompaniment is emphasize second and third beats (both classic and pop music styles) . // There is also another form of emphasis in the Viennese waltz style (not written but played) like as swing-waltz

That is, while a child sings 'Mary had a little lamb', she is unaware of these styles. she only emphasizes the word "Ma-ry" and "had-a" with the word coming out of the mouth.

When the same child sings the same melody with the words "a - pan, a - lamp, a - hat, a - cake', the emphasis changes to 2. and 4. beats automatically. // (and you might think you're listening to a broken old cassette tape (due to weak prosody of "a" ).

In reply to by Ziya Mete Demircan

Indeed, there is great subtlety and variety in the pulses of even common musical styles. When we perform live, or do a MIDI recording, those stresses are almost instinctual and constitute an integral part of the overall effect of the music.

MuseScore does not account for the style or pulse of the meter. I believe this is an opportunity that could do much for the authenticity of score playback.

If a groove function were to be added to MS, it would require the ability to overlay a "velocity map" over the measure, selection or entire piece. I don't see this as being particularly difficult, but I have no knowledge of the necessary coding. I'm not even certain if this needs to be destructive or non-destructive of the musical data. (Destructive, as in actually changing the note velocity, may be simpler and less demanding of crucial CPU resources, but may lack the flexibility of a non-destructive overlay.)

The controls necessary to adjust the weight of the groove may not be that difficult either. It's analogous to adjusting the transparency of a layer in Photoshop - the user can decide how much of the effect to employ.

The most difficult or time consuming aspect of this could be designing a library of grooves to choose from. As you rightly note, there is more than one way to weight a measure of 4/4 time. A simple strong-weak-medium-weak may be effective, but not always appropriate for a given style.

In the end, it is up to the developers to decide whether this is worthy of their time, given the other, far more pressing issues they are facing.

In reply to by toffle

I think that before any attempt of coding anything like this it would be necessary to find a feasibly rule or set of rules like: "for classical piano music, increase the first beat velocity by 10 units and slow down the tempo of the first half beat by 5 %". As mentioned above, I couldn't so far find a consistent rule. I don't say it is not possible, but it isn't easy either.
I think it is also necessary to differentiate "rythmical intelligibility" from "human touch". The first is easier than the latter. Much serious research should be conducted (and has been and is currently being conducted). See, for instance (there are much, much more):……

In reply to by fmiyara

"I think that before any attempt of coding anything like this it would be necessary to find a feasibly rule or set of rules like: "for classical piano music, increase the first beat velocity by 10 units and slow down the tempo of the first half beat by 5 %". "

Conversely, once the functionality is set in place, the values could be set and/or adjusted according to stylistic rules (if such can be found) or according to the user's preference.

I, too, am trying to keep the rhythmic and groove discussions separate as they involve editing different kinds of musical data..

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