"Humanized" playback
I think I missed something in the way.
I've tried to get a "humanized" kind of rhythm playback, but I can't.
I'm talking about... Humans, normally, treat some rhythm figures in a bad, but full accepted, way.
Example:
The upper staff is what humans have to play. BUT, normally, humans play like the lower staff.
Humans often shorten the first figure and lengthen the second figure.
Yes, I know it is an error. But, we are so get used with this... That it is accepted!!!
I know it isn't a MuseScore important issue (because it isn't related with the final main target), but...
I wonder if we can get that "humanized" kind of play the music pieces.
I thought "swing" was closing to that, but not. "Swing" is another idea.
SO... Can somebody understand my topic?
How can we get it into MuseScore, today? ???
Greetings & Blessings from Chile!!!!!!!
Juan
Comments
Where I come from, some humans do accidentally play it like the lower staff, until they learn how to play it correctly. Is it a good idea for MuseScore's playback to imitate beginners making mistakes?
In reply to Where I come from, some by Isaac Weiss
Even in classic music, the players let themselves some "licenses" about this.
The machine can play it in a 100% academic rules right style, but... It will be sound as a machine, robotic.
The human mistakes (by error or in purpose) give the music... The essence of the music!!!
It is the main reason because we like the live human performances instead the computer "Interpretation".
I think it isn't my thought, only.
In reply to Even in classic music, the by jotape1960
Absolutely, I agree, humanizing is a good. But what you described isn't humanizing; it's just incorrect. There are lots of *other* things that could be done to vary aspects of playback to make it less robotic, and if we implemented those, people would hear it and agree it sounded better. It just happens that the example you chose would make most musicians who know how to read music say "that's wrong" and start filing bug reports that MuseScore doens't play dotted rhythms correctly.
In reply to Absolutely, I agree, by Marc Sabatella
It is true that "tripletizing" dotted rhythms is generally wrong. But there are oodles of examples where it is accepted--if acceptable is up to the individual.
In baroque music a dotted rhythm that goes along with triplets (especially if the rhythms sounds simultaneously) is almost always made to match the triplets (or else it is sharpened to a 5:1 ratio). Or listen to recordings of Schubert's B flat piano trio, first movement, which also combines the two rhythms: You'll find recordings that make a point of contrasting them and others that make a point of making them alike (and some who do a little bit of both--those are the ones who don't even consider the question). Nobody knows what Schubert would have wanted to hear.
In reply to It is true that … by azumbrunn
> Nobody knows what Schubert would have wanted to hear.
Presumably he wanted to hear it played the way he wrote it, otherwise he would have written it a different way...
In reply to > Nobody knows what Schubert… by shoogle
Look at the score: When triplets and dotted eighths sound simultaneously it sounds like bad playing when you insist on playing it like printed (it wouldn't be a problem at slower tempi). There is a genuine issue here.
In reply to Look at the score: When… by azumbrunn
I find it strange that the composer would use both kinds of rhythm if both weren't intended. I could understand dotted notes being used in place of triplets if the composer was too lazy to write triplets (a kind of swing-like notation), but if the composer has already gone to the trouble of writing triplets elsewhere in the score then I find it hard to believe that the composer would then switch to dotted notes without intending a dotted rhythm to be played.
Maybe a triplet rhythm does sound better (in some peoples opinion), but that doesn't mean it is what the composer intended. Maybe Schubert got it wrong on this occasion, or maybe that was the effect he was going for, but either way, MuseScore can (and should) only play what is written. MuseScore should not play something in a manner that is objectively wrong, just because it sounds subjectively better.
However, I may have (completely by accident) hit upon the solution in my first paragraph. Perhaps "lazy triplets" could be implemented as an extension to MuseScore's swing notation? This would allow composers to explicitly say "I want dotted rhythms to be played as triplet rhythms", rather than writing a horrendously complicated algorithm to try to guess what the composer wanted, and it would also be visible to human performers.
Edit: Marc already suggested something similar below.
In reply to I find it strange that the… by shoogle
I'm no expert on Schubert, but I do know he was dead long before the idea of swing came along, so he would not have been able to suggest swing notation. One of the things that happens with geniuses in the arts is that they start using "tools" before they are in common use. Was Schubert this kind of genius?
Not being a expert on Schubert, I also don't know if he wrote this or the publisher put it in the score in error or due to laziness. All editions on IMSLP are from decades after it was first published. It would be interesting to see the autograph, which may or may not exist. A large number of German autographs from that era do still exist.
In reply to I'm no expert on Schubert,… by mike320
Again, I would point out that he (or the publisher/engraver) already used triplets in the score, so I doubt that they would then switch to dotted notes unless a dotted rhythm was intended. However, if people feel otherwise then they can insert the swing marking themselves, possibly within brackets to indicate that it is an editorial suggestion, or simply make it invisible.
In reply to Again, I would point out… by shoogle
I think the explanation is simpler than that: At the time the baroque practice of accommodating dotted rhythms to triplets (or on the other hand playing them as if double dotted in some situations) still lingered. I also observe that the modern notation of a quarter-plus-eighth triplet (as opposed to "normal" three eighths) is rare in music of the time--if there even are examples. The piece is not an exception, just an example where the problem is occurs more often than in most music.
I suspect we tend to expect more consistency than most humans (myself included) are willing to deliver.
As to an editor changing an autograph score in this way: I think this is highly doubtful. Why would they? It would have to have been one in a consistent manner throughout the movement (otherwise we could trace it) which would be work that nobody would pay them for.
I agree that humanized playback would be good, but also tht *wrong* playback would be bad, and the above is indeed simply wrong. What I think this is really showing is someone attempting to notate "swing" eighth notes by writing dotted eighth / sixteenth, when they should simply have written them as eighth notes and included the word "Swing". True swing eighths are not really exactly like triplets either. MuseScore does provide swing playback, but you need to notate it correctly for it to work - that is, notate as eighth notes and add the Swing text. You can customize the actual ratio to make it sound horrible (eg, 75%, which is like dotted eighth / sixteenth) or merely not very good (eg, 66%, which is like triplets). The default of 60% is somewhere between normal eighths and triplets and sounds abut right at medium tempos. It's too exaggerated at fast tempos but not quite enough at slow tempos.
I definitely think there should be a humanizing effect. The easiest thing to do is for the user to be able to set a range for random deviation from the intended velocity. I already adjust velocity to make things sound better, but it would be nice if it could be procedurally generated. Maybe the tempo could vary? It would need to vary less often and less dramatically though because otherwise, it's just bad. Rhythm would be hard to find a way to vary, but it gives room for more creativity.
It's true that if you "humanize" it too much, it's just badly played. However, the tool should still be available and adjustable so that if used right, it's much more beautiful.
In reply to I definitely think there… by Theguyhere
"The easiest thing to do is for the user to be able to set a range for random deviation from the intended velocity."
Terrible idea. There is nothing random about how and why a performer varies the dynamic/volume/velocity of the notes in a melodic phrase or rhythmic figure. Equally, there is no fixed rule covering how to balance vertical sonorities in a chord. As to tempo, it isn't a question of changing the BPM, but of introducing millisecond changes to the lengths of individual notes to achieve "playing in rhythm" rather than "playing in time."
More significantly, performers decisions are based on context. Not just the context of "where the notes fall in a piece," but the individual qualities possessed by the specific instrument they're playing (e.g. a Steinway D vs. a Bösendorfer Imperial), the venue of the performance, the size and receptivity of the audience, and a host of other factors.
I'm going to go out on a limb, but I believe I've devoted more time to humanizing MuseScore scores than any other user out there. The results speak for themselves. (Please, please correct me if you are, or know of, someone who's producing music from MuseScore of a quality equivalent to, or better than, what's on my YouTube channel https://www.youtube.com/channel/UCUhxBZDJtPyW1Q9-gG-6Cow.) I make the claim in the hopes it will lend weight to my argument, which is that rather than offering a "humanizing" routine or algorithm, MuseScore needs to make it easier to humanize playback manually. Most of what I compose these days will only ever exist as playback from MuseScore. That means my interpretations, my "humanizing," have to be as close, musically, to my ideal as I can get it. That entails a lot of manual tweaking--unavoidable manual tweaking. I don't expect MuseScore to do it for me, but I do expect MuseScore to make it easy.
Here are my suggestions for improving MusScore's "humanizability" tools.
Restore gate offTime as a parameter settable from the score, like it was in version 1.x! I am sick to death of inserting hidden notes and rests and co-opted articulation marks at the end of every phrase to introduce a break between phrases. Lungs run out of air, bows change direction, and pianists sometimes take their foot off the pedal. If there's one thing that will significantly humanize MuseScore playback, it is just this. Nobody should have to go through this much trouble to compensate for the removal of offTime from version 2.0. The process should be be painless, thereby encouraging average users to be a little fussier with their playback and giving dedicated users a reasonable tool to work with.
Make TimeStretch a settable note property, not just a settable articulation property. At present, I add hidden tenuto marks and set a note's TimeStretch from there, but in a long piece or a big orchestral score, this is a PITA. As with the lack of gate offTime, it actively discourages average users from making such adjustments. A terrific advantage of TimeStretch being note-settable is that it would make crafting the gradations of slow-down and speed-up in rits, accels, and rubatos much easier; these things never proceed at an algorithmically derivable pace, and creating them only by changing BPM doesn't offer sufficiently fine-grained control.
More effective use of StaffText Properties. Let users be able to set the number of channels they want for any given staff so they can switch to different samples ("soundfonts") for that staff from StaffText. I need this functionality all the time, even in my piano scores (una corda, anyone?), but I have to text edit my mscx files in order to get it.
Keyswitching soundfonts provide a similar functionality, but engaging the switches involves littering a score with hidden notes typically 5 or more ledger lines below or above the staff. Users would surely welcome a keyswitching StaffText option, e.g. a "Keyswitch" button with a value field beside it for the desired note. (Such an option could be part of the tantalizing but apparently unimplemented "Midi action" tab.)
In reply to "The easiest thing to do is… by Peter Schaffter
For keyswitches, you would need a way to stop the switch too no? A staff text would only be able to send a note on event. You would need a spanner for noteon at the start and note off at the end, or did I misunderstand how keyswitches work ?
MIDI action is kind of implemented for staff text I believe, but unfortunately it can only send CC and not noteon/off event. Kind of because you need to edit the mscx or instruments.xml to add the actions...
In reply to For keyswitches, you would… by [DELETED] 5
Sorry, because my ignorance...
Are you talking about we can edit "instruments.xml" to add some MIDI parameter actions and then MuseScore will recognize those changes???
Can you teach me more about this, please???
In reply to Sorry, because my ignorance… by jotape1960
I used Pianoteq because it's the only virtual instrument I own. Pianoteq will press the Soft Pedal of the piano if it receives the controller 67 with value 127, unpress it if it receives controller 67 with value 0.
If you setup a piano like below (I removed the articulations section), you are able to select one or more MIDI actions for each staff text you add to the score. The simplest score attached will switch the first pedal of pianoteq (soft pedal) on and off on the second staff. I added the pedal spanner to show what I meant that keyswitches should be. We would need a way to attach controllers (or midi on/off) to the start and end of spanners (or a way to change a value of a controller over a spanner, linearly or not...)
In reply to For keyswitches, you would… by [DELETED] 5
There'd be no need for noteOff. Keyswitches are persistent.
Notes for keyswitching can be added onto a note or chord in the score. (The keyswitch note needs only have a velocity of "1" in order to function and is thus inaudible, or it falls outside the sounding range of the instrument.) The switch happens simultaneously with the sounded note/chord, whose duration determines the length of the keyswitch note. The duration of the keyswitch note is actually immaterial since the keyswitch remains in effect until a new keyswitch note is encountered. Thus, no need for spanners either.
Visualizing how this might work: the user sets Staff Text "pizz." and enables the pizzicato keyswitch note (presumably in MIDI Actions). Behind the scenes, so to speak, the keyswitch note is tacked onto the note/chord that has the Staff Text, but without appearing in the score. The note/chord itself will be pizzicato, as will all subsequent notes until the user puts "arco" in the score and activates the keyswitch for arco.
I don't pretend to know how to implement this at the code level; perhaps, like the ever-so-needed "swell through sounding notes," it's a nightmare. The reason I feel it's needed is that one cannot, in fact, add a keyswitch note to a note/chord and selectively hide just the keyswitch note since the stem leading to it remains visible and has to be manually shortened and re-positioned so it looks as if it's in the right place.
Alternatively, keyswitch notes may be put in another voice on the same staff and the whole voice hidden, but there's a catch: if a keyswitch note is in another voice, it has to occur before the first sounding note you want affected.
Both these workarounds for keyswitching are awkward and time-consuming, which discourages the use of keyswitchable soundfonts, such as those in Paul Battersby's beautifully organized Virtual Playing Orchestra.