trill and turn implementations

Hi everyone,

There are several discussions requesting a trill implementation in musescore playback.

I've added implementations for Trill, Turn, and ReverseTurn into a branch of musescore.
The branch is called 1518-articulations.

The can of worms being opened is that different types of music and even different users will want the different ornaments to be played differently. Does the implementation I've done (or any implementation) break more than it fixes because some people are going to disagree?

I'm attaching some very simple test files to show the basic idea.

The way I did this was to implement a fairly generic function called renderArticulation (find it in the file rendermidi.cpp). I'm not yet 100% happy with it because it is not able to implement all ornaments I need for baroque style music. I think the function will need a few more arguments.

Please let me know what you think.

Jim

AttachmentSize
trilltest2.mscx8.41 KB
trilltest2.mid488 bytes

Comments

I would like to continue this development by implementing more of the ornaments which currently have no implementation in the playback.

I also welcome anyone's feedback on the actual C++ code, as I'm a long time lisp programmer pretty new to C++. I tried not to make it too lispy.

I tried playing the following, it is pretty obvious that there should be a lower limit on speed of trills.
The mordents sound nice, but the trills are pretty bad.

https://musescore.org/sites/musescore.org/files/ABRSM%20piano%202015%208A6%20Scarlatti_sonata%20in%20B%20minor%20(K497)_0.mscz

Good job! They sound pretty decent, certainly much better than nothing! These could be the default trills and more types could be selectable from the inspector along the lines of these examples from Wikipedia.

I think the trills are fine for speed, perhaps slightly too fast but only very slightly. I think the main problem with the trills is that you try to slow them down part way through. In my view *mimes opening can of worms* this should only happen if there is another form of notation present, such as a Fermata, and the correct way to do this would be through tempo rather than sub-note length.

Your solution was some kind of compromise involving changing from straight demisemiquavers to other note durations, and even tuplets, part way through.

In my opinion it should simply be:
trill.png

And (only) when there is a Fermata:
fermata_trill.png

So it seems to me that you actually made life a bit more difficult for yourself than you needed to. Perhaps the 2nd example could be implemented using the same as-yet-to-be-created algorithm as ritardando and rallentando (rit. and rall.).

AttachmentSize
trill.png 6.2 KB
fermata_trill.png 11.29 KB

However, even this example with Fermata seems beyond what is absolutely necessary. Using a constant low tempo for the duration of the Fermata (i.e. the current "time stretch" behaviour) would be more than adequate for a first implementation. I think the idea (at least in the first instance) should be to give an impression of how it is meant to sound, and not necessarily exactly how it should sound. The impression just needs to be good enough that a composer can click Play and think "ah yes, there will be a trill there" rather than fixing in stone how every piece must be performed.

Hi shoogle,

Thanks for the comments. Yes, the current trill for notes larger than 1/8th note indeed looks like: https://musescore.org/sites/musescore.org/files/trill_1.png

Your comment about the fermata trill combo brings up another point.
If I'm not mistaken, the musescore editor allows you to stack articulations, even ones which make no sense together. It is not clear from the code what the effect is. For example, if you stack a trill and a turn, I believe one will be rendered in playback and one will be ignored, but I'm not sure which.

I'm tempted to refactor the articulations into two groups, ornaments and other. The user semantics would be that only one ornament is allowed per note, and ornaments have a speed or resolution attribute. I'm not sure the consequence of this refactoring, nor the benefit.

Hi Shoogle, this is an interesting example. Actually sort of the opposite is needed in a Mozart style trill. Such trills often start slow, and speed up at the end.

Nice work!

I just listened to the midi file and looked at the score (rather than building your branch of MuseScore). So I didn't get a chance to test how the trills perform at different tempos. Are they always 32nd notes or does the note length change depending on the tempo?

At a super fast tempo 32nd notes would be too fast for a trill. For example if the computer plays a trill faster than is humanly possible on an acoustic instrument, then it is too fast.

At super slow tempos 32nd notes may even be too slow for a trill. For example if the computer plays a trill so slowly that it no longer sounds like a trill, then it is too slow.

Hi David, thanks for the comments. For the moment the trills are hard coded as 32nd notes, and the turns are 16th notes. However, I do plan to make this smarter, taking the tempo into account.

Two possibilities are pretty easy to implement.

1. I decide on a heuristic based on tempo.
2. Allow the user to specify some sort of trill-speed (or maximum speed).

Currently there are no properties defined on Trills which I can use to allow the user to specify his particular preferences on the trill. A musescore limitation (at the moment) is that ALL articulations have the same properties available. The only property I can currently use is the time-stretch. Time-stretch is intended to be used by the fermata, and is ignored by all other articulations.

I was considering piggy-backing off the time-stretch. My feeling is that would be wrong and confusing, but may be pragmatic for experimentation purposes.

I was thinking a built in maximum speed (and minimum speed) rather than user-specified.

That is a really nice work....
also I would add some comment to reflect further
1. what about begining trills also slower than go faster than go slower again
2. i think accelerando/rall of a trill depends on type of movement and that can't be guessed (can it ?) by a computer
3. what about trill that aren't "half step" above ? (like a whole step, or next scale note?)
3 bis . What about trill with an alteration above ? (to precise accidental of the note)
4. : what about the order : which note begin the said "real" one, or the "orenemental" one ? (my little experience showed me it depends from which note you come, and which musical period it is)

I would like this as a facultative plug in .... not as all ornemnets played if we can't select "second" note played and which note is first...

But that is right now a great job, just some comment to improve / reflect on it ;)

Thanks for the comments.
(1,2) The way the code is currently structured, it is not suited for tempo change within the trill, unfortunately. Although of course you are right, for the playback to sound as authentic as possible, this feature would be delightful to have.

(3,4) I have implemented a baroque trill. This starts on the note diatonically above the written note. E.g., in the key of F, an A trills down from Bb, and C trills down from D. There is a slight bug here because if D has already been flattened earlier in the measure, it should trill down from Db.

The trill also always starts on the beat. Some articulations really want to start before the beat and resolve on the beat. But to do this an articulation needs to be able to enter events in the past (negative time). I'm not sure how to do this, and not sure if it is possible if the first note of the score has such a decoration.

I agree that of course not everyone wants a baroque trill. If you're capturing Mozart music rather than Bach music, you'll probably wish it worked the other way. But there is currently nowhere in the data structure to store the desired starting note.

I have some ideas about adding properties on the articulations to allow the trill engine to be smarter. This of course changes the musescore data structures, and might effect lots of things which I'm not yet brave enough to edit in the musescore source such as, the GUI.

(I'm basing my comments on what I saw yesterday, so it may all be wrong by now; I'm hesitant to load a nightly build or branch build, let alone build it myself).

Your trill timing seems to be done with slowdowns of tempo. That won't suffice at all if there are other voices; it has to be done with note-values, including ingeniously rationalized tuplets.

Second, I think your turn was wrong. Turn on D should be E D C D, no? See Wikipedia "Ornamentation."

Hi BSG, yes I think you are right about the turn. I'll fix that for sure.

Also you make a very good point about multiple voices. Could you please explain more about what your concern is there? Is the issue that you'd like a nice sound if several voices are trilling at once, but each starts on a different beat? An example would be very helpful here.

As per the nightly build. This change IS NOT incorporated into any nightly build.

Jim

Hi, Jim (I'm Bernie, btw, but that username was taken). You said that they're done with carefully-measured notes, not tempi, so my concern with multiple voices has been addressed. I do use trills in multiple voices, but they start and end at the same time, so they should come out the same.

Flatting/sharping the excursion notes is important. Why don't you look and see if self-standing sharps, flats, etc are hung off the ornament, and whether their placement is above or below

BTW, my trills are not implementing using slowdown of tempo.

In the interested of full disclosure, the way it works is as follows.

PARAMETERIZATION:

Every ornament has 3 component patterns any but not all of which may be empty.
1. prefix
2. body
3. suffix

Each pattern specifies a list of excursion notes relative to the principle note. E.g., {1,0,-1,0} means play the note above, then the note, then the note below, and finally the note.
The body has two additional boolean parameters, repeatp and sustainp, specifying whether the body should be repeated as many times as possible, and whether the final note of the pattern should be sustained to fill the remaining time slot.
In addition each ornament has a default note duration e.g., 1/32nd note or 1/16th note.

ALGORITHM:

The engine calculates how many times the body can be repeated to fill the time slot allowed for the note. If repeatp=false then body is played once but not repeated.
If the pattern [prefix] [body]* [suffix] fits into the time slot it is played as such.
If the pattern is too big for the time slot, then the note duration is decreased just enough to make it fit.
However, if this causes the note duration to become less than 1/16th of a second then the ornamentation is omitted.
If the total pattern is less time than the time slot and sustainp==true, then the final note of the body pattern is sustained to fill the extra space before the suffix is played.

KNOWN LIMITATIONS:

1) Each note of the ornamentation is played at the same duration, with the exception of one sustained note.
2) Only one note is sustainable per ornament.
3) The notes comprising the ornament cannot preceded the beat of the principle note.
4) The ornament properly respects the scale of the key signature, but not accidentals occurring previously in the measure.
5) Users cannot customize the excursion notes, nor the accidentals of the notes, nor the duration of the individual notes.
6) The fastest note playable is hard coded as 1/16th of a second.
7) Ornaments do not compose. If you specify a turn and a trill on the same chord, one will be played, and the other ignored.

I think this file I'm attaching covers all the ornaments that do not playback in MuseScore (except of the regular pralls and mordents which have been fixed in 2.0). In every staffline there is the ornament adjusted over the note in the first measure and the actual playback of the ornament in the next measure. Moreover, there should be symbols of trills and gruppetos with accidentals above them which should also playback correctly.

AttachmentSize
Ornaments that don't playback in MuseScore.mscz 20.56 KB

HI KosrisP7, thanks for the list. Many of the ornaments you list here are very different from my understanding of them. I think I'll work on such a sheet to show what the actual implementation is, so we'll have something to compare.

Perhaps it heavily depends on the period or style of music being annotated.

Indeed, in each period (classical, baroque, romantic, etc.) some pralls/mordents are used differently. That's why each musician performs them the way they want. But these are the most common. And if MuseScore would playback them in a future version, that is how they should be heard. However, in modern music, it's 99% certain that you will never come across them. Composers now use regular mordents and pralls and then they just perform according they way they feel at that time. So implementing playback in those is optional. The priorities are the trills, the gruppetos and the glissandi/portamenti/falls.

Hi KosrisP7.

I'm not exactly sure I understand you 100%.
What do you mean buy "But these are the most common."? Do you mean these are the most common ornaments, or rather these are the most common ways the ornaments are interpreted?

I use musescore very rarely if ever for modern music. My use until now has been almost exclusively for classical/baroque music. Since ornaments are so common in this type of music I wanted to implement them in musescore playback.

The current proposal will/would hard-code the implementation of the ornaments. This has the advantage of being EASY to implement, and flexible enough to make a good but approximate implementation of ALL the ornaments in the existing musescore repertoire.

The proposal has the disadvantage, however, that it is not user customizable, and thus lacks flexibility. E.g., a hard coded trill will start (by my proposal) on the note above, and trill down to the principle note. If someone wants the trill to start on the principle note and trill up to the note above, that would be impossible.

The implementation can certainly be extended at a later date to add flexibility.

Hi Jim Newton,
First of all, I mean the most common ways the ornaments are interpreted. If you don't understand something else don't hesitate to ask, because English is not my mother language, therefore I may be misunderstood.

I understand that, not only you but a lot of people, use MuseScore for classical music and that's why MuseScore should playback the rest of the pralls/mordents but it can't playback the way each composer individually used an ornament. That's why I uploaded the list, so that if the developers of MuseScore decide to adjust playback in these ornaments, they would know the most common way each of these ornaments are actually playbacked.

Moreover, concerning the example you are using at the end about the trill, I have included in my list both ways a trill can be playbacked. So nothing is imossible!!

Lastly, I also agree on the flexibility, but I believe it would be difficult for the developers. I mean, come on, it's a computer, not a person. In my opinion, the list I've made covers all the ornaments and their playback.

Regards,
KosrisP7

I've done some experimentation and it looks promising.
I suggest to add a new property to the articulation inspector called Ornament Style:
there are 3 possible values at the moment, but this can be expanded easily.

"default" ==>play in "modern" style
"baroque" ==> play in "baroque" style
"no ornamentation" ==> just play the note as if it had no articulation.

In most cases "default" and "baroque" will do exactly the same thing.

"no ornamentation" can also be used to stack articulations. any one with "no ornamentation" will be treated as a NO_OP.

Hi KorisP7, please check your turns in the score you submitted. Please verify to me that they are correct. You a turn over a B which you suggest be played started at the D and resolving to the C. My code plays this starting with the C and resolving to B.

Oh my God, I'm so sorry. Of course it's a mistake. I'm uploading a screenshot of the correct ones. Thanks for noticing and telling me. ;)

AttachmentSize
rtfg.png 30.33 KB

Hi KosrisP7,

Can you tell me how you came up with this list? Is there a reference I can use myself to verify them?

I consulted my old music theory book for the simple ornaments, but you can't find it anywhere else but Greece because my teacher had written it. However I just found this table of ornaments, which I'm attaching, written by Bach, which includes all the ornaments used in Baroque music. I made a small comparison with mine and I think they're almost the same. Moreover, you can find out about the schleifer (slide) here: http://en.wikipedia.org/wiki/Slide_(musical_ornament).

AttachmentSize
Tableofornaments750.jpg 59.75 KB

Yes, that graphic looks like the one from wikipedia: http://en.wikipedia.org/wiki/Ornament_(music)
Unfortunately, there does not seem to be enough information their to explain how the ornaments are played in the case they are attached to notes longer or shorter than a quarter note.

Also my understanding of the Schleifer is different than your example
A slide (Schleifer in German) instructs the performer to begin one or two scale steps below the marked note and slide upward. The schleifer usually includes a prall trill or mordent trill at the end.

If I'm not mistaken in your example, the Schliefer starts 3 notes below the principle note, and neither contains a prall trill nor a mordent at the end.

When the notes are longer than a quarter note, the ornaments are played with 16th (half notes) and 8th (whole notes) notes, that's for sure, because it's in the music theory book I've mentioned. Regarding the schleifer, I think you're right. I may have misunderstood. I'm attaching a screenshot of the correct one.

AttachmentSize
Schleifer.png 29.74 KB

A limitation of my current implementation is that it does not support ornaments whose rendition contains notes of two different lengths, as is shown in your Schliefer.png.

The current implementation allows the rendition to contain one optionally sustained note, and all the rest of the notes are the same length.

Of course I can enhance my algorithm to support it but I want to make sure it is really necessary, and that I understand it first.

While we're here, is there any reason why the trillo mit curlicue von oben (I don't know its right name), #6 in the table just posted, isn't even in MuseScore's graphics palette? This ornament is very important; it occurs, for one, in Bach's famous organ chorale Schmücke dich, o liebe Seele, BWV 654, and I have used it in my own works. It is not the same as "down prall", as the table reveals.

Can we fix this (and implement this child of turn and trill)?

Hi Bernie (BSG), yes there are many ornaments missing.

As I understand it Musescore only intents to support musical notation which is described in SMuFL, see http://www.smufl.org . In fact the complete list of symbols (not all of which are supported by musescore) can be found in this document: http://www.smufl.org/files/smufl-1.12.pdf. Take a look in particular at pages 153, 157, 161, and 162.

I'm currently not brave enough to add them as that would require touching parts of musescore which scare me. But I'm tempted to give it a try, after the current issue of playback is resolved. I think to make this usable, the current "Articulations & Ornaments" panel should be split into an Articulations panel and a separate Ornaments panel. Once the symbol is supported by the GUI and the editor, then adding the musical rendition for playback is pretty easy and safe.

BTW did you take a look at https://musescore.org/sites/musescore.org/files/ornaments.pdf
I'm not sure which if these are the same as the ones provided by musescore. My suspicion is that the notation (shape of the symbol) is different, even if the rendition is the same.

Any thoughts?

I think that you're right Jim. Firstly, you should implement playback in the existing ornaments. And then add the missing ones, that BSG mentioned. Unfortunately, I can't help on these, because I'm more of a modern musician, so I don't know how they should be playbacked.

Mine is the one that goes "deedleadle-deedle...", :), it's right there in the PDF posted, #6. That is, if on D, E D C D E D E D E D.... (and with a mordent-line through the end, terminate in CD otherwise don't). Notice that the French sources have a similar ornament where the first turn chops into the back of the previous note, but that's different AFAIAC.

Oh, and it's in that SMuFL Unicode array to which you pointed me.

hi KosrsisP7, The current framework for ornaments is not sufficiently flexible to implement the style described in https://musescore.org/sites/musescore.org/files/Ornaments%20that%20don%27t%20playback%20in%20MuseScore.mscz
I've checked with a several experts at the local music conservatory (an expert baroque oboist, and two professors), and none of them agree that the trill speed should depend on the note length as indicated in your file. I.e., the trill speed for a whole note should be the same as for a half note, differing only by number of excursions made.

That being said, I'm very happy to try to implement such a style, and perhaps name it after the professor of yours who suggested it or the author of the book you are using. To do this I'll need to make a small enhancement to ornament playback framework.

If you'd like me to do this, (I hope so), please download the file https://musescore.org/sites/musescore.org/files/Baroque%20Ornaments_0.mscz, and edit it as per your examples. Most should be copy paste from your original document. Then upload it again with a name indicating the desired style name.

Thanks.
Jim

If anyone is interested, one of my motivations for implementing playback for these ornaments was that I wanted to capture a particular suite:
dupuits.png
The piece uses lots and lots of different ornaments. Here is the glossary which explains them. ornaments.pdf. Eventually I'd like to hear all these using musescore playback.

AttachmentSize
ornaments.pdf 514.73 KB
dupuits.png 211.05 KB

I'd recommend that, at least for a first attempt, you concentrate on implementing basic playback for as many ornaments/articulations as possible, rather than providing multiple playback options for each. Just pick a default implementation that is either the simplest or most common interpretation of the symbol. A simple working example is more likely to be accepted into the main code than options that require a whole new framework to allow the user to choose their favorite. The baroque trill is simple and popular, so it seems to be an ideal starting point and default. I wouldn't offer any customisation beyond the "Play?" checkbox in the inspector so that people can disable it if they really don't like it.

Ultimately, the correct interpretation could be selected in three ways:
1. Automatically using entries in "Score info" for "Genre" (e.g. Classical) and "Sub-Genre" (e.g. Baroque).
2. Manually from a list of presets in the Inspector.
3. Manually from a dialog box that allows the user to define their own interpretation.

However, these all require major changes to MuseScore, so for a first attempt I think it is best to just give a sensible default. Since you are doing the coding, you get to decide what that default is, but I'd recommend something simple and/or popular.

Once you have implemented one ornament, even if it's not perfect, create a feature request *for that ornament only* in the issue tracker, assign it to yourself, create a Pull Request, tag it with the issue number and link to it in the issue tracker. That is the way to bring this to the attention of the developers.

I'm far from certain that a baroque-style trill is more commonly used, or more likely to be appreciated be the greater number of users. I'd guess you're speaking based on your own specific musical background, but trust me that it would be a bad idea to "not offer any customisation beyond the "Play" checkbox in the Inspector."

My own preference—speaking from my own musical background—would be that starting on the fundamental note should be the default, with a checkbox for "Start on upper note."

Hi Zack, While I want baroque-style well supported, I agree with you it does not fulfill every need and lots of people won't be happy with it.

A limitation in the musescore implementation currently is that ALL articulations use the same inspector. There is no trill specific inspector. Putting lots of stuff in the GUI which applies only to trills will make other articulations such as staccato and fermata confusing. So we have to be cautious extending the GUI. Your suggestion about whether to start with the note or note above, would make the mordent confusing. A mordent cannot start with the note above or below, else it would not be a mordent. But the entries would be in the GUI.

The solution must include a way for the user to select from a robust set of different styles, or to be able to enter his own style.

And if there is a way for the user to enter his own style, this has to be easy and not require difficult to follow tedious instructions.

Please see the following for a related discussion:
https://musescore.org/en/node/56906

I don't want the baroque trill to be the only option either, but the point is that presenting the user with a choice requires big changes to the MuseScore code and probably the .mcsz file type. The developers are unlikely to accept such large changes from a new contributor because it might force them down a path they don't want to take.

My point is that it doesn't need to be completely solved all in one go. A simple working example as a proof of concept is more likely to be accepted in the main code. It would also alert the lead developers that more changes are on the way so that they can assist in deciding the route to take in terms of customisation and choice.

I don't really care which trill is chosen for the working example (it is only meant to be a starting point). I was simply indicating to Jim.newton.526 that I think a baroque style trill is a good choice because it is very simple and reasonably common. Once there is one working example in the main code I imagine others will quickly follow.

Hi Shoogle,

Here is the simple working model and proof of concept which I intend to commit and which is currently available for anyone to see on the branch 1418-articulations.

1. The articulation will have an option called "Ornament type" with three choices. (which can easily be extended)
default
baroque
no ornamentation
2. Saving and reading the .mcsz/.mcsx file will write and read this property correctly.
The only difference in the mcsx format will be the addition of a xml parameter in the
articulation object. By the nature of xml this will be ignored in older musescore readers.
But my assumption should be tested.
3. Some articulations (14 or 15 of them) will have renditions for baroque style. 2 or 3 will have renditions for default style.
4. Programmers will be able to add styles or implementations for missing ornaments as long as they can be expressed in terms of the parameterization explained in the posting above "Posted by jim.newton.562 on April 15, 2015 - 8:37am". Or if a non-programmer wants to describe a certain desired rendition to me, I can add it to the code for you making it available in the nightly build.

In my opinion this model is robust enough to express lots of different types of trill, but does not try to do everything in the first release. Certain types of trills wont be supported (such as trills which sustain more than one note, or which effect the tempo).

The main thing currently preventing the release is that the tests fail, and I cannot figure out how to run the tests on my mac.

Jim

Hi Jim,

I can't see the 1418-articulations branch until you commit and push the commit to your "remote origin" repository on GitHub (jimka2001/MuseScore). I tried building the 1518-articulations branch but the compilation failed at 85%.

However, these changes seem to be what I had in mind. Might I suggest the following minor change?

Rename the ornament types:

  • default --> Hold/Pause
  • baroque --> Trill (Baroque)
  • no ornamentation --> None (It should be obvious what this means since the category is called "Ornamentation type".)
  • Currently it seems the idea is to have a different ornament "type" for each trill, but perhaps it would be better to group them all under "trill" and create another new option for "subtype". But you should submit the pull request as it is (but with the name changes if you agree with them, and make sure you can compile on your own machine). Leave the "subtype" category for the next pull request, if it is decided that it is an appropriate course of action to take.

    P.S. If you want to link to a particular reply to a comment you can right-click (Mac: Ctrl click) on its time-and-date (e.g. April 15, 2015 - 8:37am) and copy the link (e.g. https://musescore.org/en/node/56281#comment-259266).

    Yes, sorry. That was a typo in the message. The branch name is 1518-articulations.

    With regard to the compilation. It compiles fine for me. I'm happy to try to figure out why it fails for you. I can imagine lots of possible issues such as the version of the STL being used, or whether using the C++11 compiler option?

    I'm not sure what you mean by "default --> Hold/Pause"; the default articulations are implemented neither as holds nor as pauses.

    I'm also not sure what you mean by "grouping". I don't really have a plan at the moment to rework the GUI where all the articulations and ornaments are grouped. Perhaps I misunderstood your request. Nevertheless, I would prefer the GUI to separate the articulations from the ornaments.

    As per your comment about "baroque --> Trill (Baroque)", baroque does not (in my plan) limit itself to trills. The trill is one of many ornaments. Any of the ornaments may have (and probably will have) a baroque style. Whether they also have other styles is an open question. I'm happy to implement other styles for any of the ornaments as long as such makes reasonable sense.

    I don't know about these compiler options, surely it should just compile with the Makefile? I run Linux (Ubuntu 14.10) so my system is probably more similar to the Travis CI test. I wouldn't recommend compiling with any custom compiler options, but if you have added custom options to the Mac Makefile you will need to add them to the Linux and Windows Makefiles too. I've attached the errors I received on compiling so you can see if they mean anything to you: compile_errors.zip

    I thought the default articulation has the "Time stretch" attribute which naturally belongs to the Fermata, but might be appropriate for other articulations too (Short Femata, Long Femata, etc.) You could give it type "Femata" if you prefer it to "Hold" or "default". I was just trying to keep it general. As far as I am aware every item in the "Articulations and Ornamentals" palette is an "Articulation" as far as the Inspector is concerned. I don't know if there is a musical distinction between an "articulation" and an "ornamental", if there is then perhaps you could enlighten me?

    I think we had different visions for how the "type" should work. I thought "type" referred to "which ornamental is this?" (i.e. Femata, Trill, Mordent, etc.) but you seem to mean it as "which style are we using for all following ornaments?" (i.e. Baroque, Mozart, Modern, etc.). Your way is better, providing you can tell which ornament has been selected. Perhaps you would consider renaming the new option "Ornament style" instead of "Ornament type" to avoid confusion?

    However, there is one potential problem with your method: what if there is more than one interpretation of an ornament that is considered "Baroque"? You could solve this (at a later date) by adding another "substyle" category for "Baroque (type 1)", "Baroque (type 2)" and (eventually) "Baroque (custom)", but don't worry about this for the time being.

    If the user selects your "Baroque" style, what happens in the inspector? Does the "Time stretch" disappear? Does a new option appear? Does what happens depend on the type of ornament selected (i.e. Trill, Femata, etc.)?

    AttachmentSize
    compile_errors.zip 1.5 KB

    Hi Shoogle, in tracking down this problem, could you look through your copy of the source on this branch and tell me if you find the string resetTimeStretch1 anywhere?

    sh> cd MuseScore
    sh> grep -R resetTimeStretch1 *

    I think I figured out the problem with the compilation.
    There is a .h file which is being autogenerated by a .ui file.
    I had a duplicate widget definition in the .ui file.
    I've fixed this and pushed the fix to 1518-articulations.

    BTW I kept seeing the symptoms of this in my environment, but didn't figure out the cause to now. I had been blaming it on an xcode caching problem. Glad it's fixed now.

    Please let me know if you can successfully compile.

    Anyway, my previous post can be summarised as follows:

    Re: groupings. I was confused before about what you meant by "Ornament type". Maybe consider changing it to "Ornament style" and then those other things I asked you to rename can be left alone.

    Otherwise, everything looks good for the time being, so the priority should be fixing the compilation issues. It seems like there is something about the workflow you use on your Mac that doesn't integrate well with Linux. Perhaps you are using some platform-specific C++ libraries, or something along those lines? See if the error log I sent before offers any clues as to what is missing on my system.

    Articulation Type is a concept already existing in musescore for a long time.
    There is one class of Articulation (unfortunately not one subclass per articulation type). And there is a property on each Articulation object called ArticulationType which determines whether the object represents a trill, prall down, mordent, fermata, staccato etc.

    Of the many articulations which musescore provide some of these represent ornaments. However, musescore does not distinguish them in any way from other articulations. In my thinking ornaments are those articulations which cause extra notes to be played, such as trill, turn, prall etc.

    If I use the expression "ornament type" it means the articulation type of an ornament. I agree with you that it would be better to refrain from using this expression and stick with "articulation type" to reduce confusion.

    The code compiles successfully now. Good job fixing it! The grep search doesn't return anything now (it did before your latest commit).

    Your implementation of the Baroque trill works like a treat! There doesn't seem to be a difference between "Baroque" and "Default", but I take it that this is because "Baroque" is currently the only implemented style, so better to choose it as the default than nothing. Perhaps there is no need for a default, just set it to Baroque? If I were to be really picky I would say that the style names should be capitalised ("Baroque", not "baroque").

    Your distinction between ornaments and articulations appears consistent with Wikipedia's entries, so all is good there as far as I am concerned. My thinking is that you should use the word "type" to refer to the symbol and "style" to refer to the effect on playback (e.g. ArticulationType=trill, Style=Baroque). This appears to be what you have done in the GitHub branch.

    I think everything is ready for another pull resquest. Perhaps try merging the latest upstream commits first to check for conflicts, but otherwise it all looks good to go. When you submit the PR give the developers a quick indication on how you plan to proceed from here and see if any objections are raised before doing anything too major. I guess the next step is to firmly establish the way different choices of playback behaviour are handled and, once that is done, to provide a few choices. But that seems to be the basics over with.

    Thank you for your hard work! We've all been waiting for ornament playback for ages! Once the method is firmly established, perhaps you would consider writing a new forum post in the style of a how-to showing exactly how to go about defining a new style and adding it to the list? I.e. which files/lines must I edit in the source code? That would save you from being pestered by people who want you to implement their particular favourite trill.

    OK, I can't stand it any more! Can one of you send me or point us to instructions on how to point XCode to the GitHub branch and pull this thing? Are there any special build instructions (Mac Yos.)? Thanks for all your hard work!

    Hi BSG,

    I'm afraid I use Linux, not OSX (and hence not XCode), but here is what I think you should do:

    METHOD 1: SIMPLE

    - Do this if you haven't downloaded any MuseScore source code in the past, or you have deleted it, or you have downloaded it and are actively working on it and want to keep it intact.

    1. Go to https://github.com/jimka2001/MuseScore
    2. Copy the HTTPS Clone URL (https://github.com/jimka2001/MuseScore.git)
    3. Follow the MacOSX Compile Instructions but REPLACE STEP 9 with the terminal commands:
      $ mkdir "MuseScore_Articulations"
      $ cd "MuseScore_Articulations"
      $ git clone -b 1518-articulations --single-branch INSERT_HTTPS_CLONE_URL_HERE

    METHOD 2: ADVANCED

    - Do this if you are familiar with Git, have your own MuseScore repository on GitHub, and already have a copy of the MuseScore source code on your computer installed via the Git Workflow guide.

    1. (Optional) Commit any changes to your local copy of the MuseScore source code and "Push" these commits to your remote GitHub repository:
      $ git add . ; git commit -m 'commit message'
      $ git push origin master

      ANY NON-COMMITTED CHANGES WILL BE LOST IN THE FOLLOWING STEPS.

    2. From within you exiting MuseScore directory, type the Terminal command:
      $ git remote -v

      The result should be something like:
      origin https://github.com/shoogle/MuseScore.git (fetch)
      origin https://github.com/shoogle/MuseScore.git (push)
      upstream https://github.com/musescore/MuseScore.git (fetch)
      upstream https://github.com/musescore/MuseScore.git (push)

    3. Define a new target for Git using the HTTPS Clone URL from METHOD 1 (above):
      $ git remote add parallel https://github.com/jimka2001/MuseScore.git
    4. Now the result of
      $ git remote -v

      should be something like:
      origin https://github.com/shoogle/MuseScore.git (fetch)
      origin https://github.com/shoogle/MuseScore.git (push)
      parallel https://github.com/jimka2001/MuseScore.git (fetch)
      parallel https://github.com/jimka2001/MuseScore.git (push)
      upstream https://github.com/musescore/MuseScore.git (fetch)
      upstream https://github.com/musescore/MuseScore.git (push)

    5. To get the code for the 1518-articulations branch:
      $ git fetch parallel
      $ git merge parallel/1518-articulations
      $ git reset --hard parallel/1518-articulations
    6. (Optional) When you are done and want to get back to your development branch:
      $ git fetch origin
      $ git merge origin/master
      $ git reset --hard origin/master

    Thanks very, very much, shoogle. I will try this when time permits; the prereq list looks daunting (if I remember, brew had some grim problem in Yosemite. I may have to learn about MacPorts). Will post if/when I succeed.

    -Bernie

    Hi Bernie,

    If you haven't done something like this before then please do try it, by all means! (Obviously, do Method 1!)

    However, I must give the standard advice: use the official release of 2.0 as your daily notation editor, and just use the nightly build for messing around. i.e. Create your scores in 2.0 and then play them back in the nightly build to hear the articulations. Do not save a score using the nightly build otherwise you risk making it incompatible with the official release of 2.0 and having it rejected if you try to upload it via MuseScore.com.

    Also, please be aware that you are downloading the source code from an unofficial source.

    Good luck!

    I haven't built MuseScore before, and, indeed I am a bit afraid of it clobbering my official installation; I would never switch over to it. I assume it will not install it in Applications. Thanks!

    I believe it does not overwrite the official installation but I cannot be absolutely sure since I don't have a Mac. However, it will certainly not effect your Scores because it creates a new folder "~/Documents/MuseScoreDevelopment" instead of using the existing "~/Documents/MuseScore2". So even if it does overwrite your copy of 2.0 (which it shouldn't) your work will be unaffected.

    Sehr gut. Maybe later today. Thanks!

    Hi Shoogle, thanks for sanity checking this. I'm happy that you're happy :-).

    CAPITALIZATION:
    I agree completely that we (the users) should be critical of the naming at the beginning. When it is carved in stone, it is so carved. "Baroque" is better then lower case, I agree.

    NO ORNAMENTATION
    Also what should be the name of the style which means don't play any ornamentation. It is currently "no ornamentation". 1) I'm not sure if ornamentation is a real work, and 2) perhaps simply "none" or "silent" is better. I want to emphasize that it does not mean "don't play the note", but rather it means "play the note without ornamentation". I avoided "none" because I thought grepping through the code for "none" would return 1000s of hits; I wanted more unique. Perhaps "none" is OK after all?

    "None" IHMO. "Silent" would imply no playback at all, silent notes

    So I guess the choices would be "Default", "Baroque", "None". Maybe "Contemporary"?

    Thanks Jojo. If I actually had some contemporary implementation, I'd be very happy to enter those into the system, then eliminate the "Default" style.

    How about not having a "No playback" style at all and instead having a "Play?" checkbox? That would allow me to right-click on an ornament, "Select all similar" and toggle the playback without changing the style. Otherwise, if (for some reason) I wanted a different style for each ornament I would have to change them all individually when I re-enable playback.

    But if you choose to leave it as it is then I see no problem with calling it "None", and you could even consider reducing "Ornament Style" simply to "Style" or "Playback Style". The meaning is clear because they appear under the "Articulation" heading and the notehead has its own inspector for disabling playback entirely.
    Articulation_Inspector.png

    I'd go for "Playback Style"

    Playback Style makes a lot of sense.

    To play devil's advocate. This could be confusing for users who don't understand the implementation. Remember that the same attributes show up on ALL articulations: E.g., staccato and fermata.

    What would the user expect if he sets "Playback Style = none" on a staccato?
    Having the word Ornament in the prompt does indicate that it has no effect on non-ornaments.

    Does anyone agree or disagree with this potentially confusing point?

    If I select the ornament or articulation (rather then the note it belongs to), and switch playback to none, I know what to expect: that ornament/articulation should not play. The note itself of course still should.

    I agree with this, but I still prefer a "Play" checkbox to "Playback Style: None". This way you can leave the Playback Style alone when you disable/enable playback. This has two benefits:

    1. If I download someone else's score from MuseScore.com I can disable playback of articulations, but the style is remembered so I can re-enable playback later without having to find the original file to check whether they used "Playback Style: Baroque" or "Mozart", "Modern" or whatever.
    2. If I have a score that uses different Styles for many articulations, I can disable or enable playback for all articulations regardless of their Style by right-clicking on one, choosing "Select all similar elements" and unticking the "Play" checkbox. If you have to do it via Playback Style you would need to remember which Style you used for each articulation and you have to change them all individually.

    Good reasons indeed!

    Naturally, if "Play" is unticked then the "Time Stretch" value should also be overridden (but remembered!).

    Hi Shoogle, I didn't understand you comment here. What is the connection between "Play" and "Time Stretch"? What is the problem as you see it?

    You do understand, don't you, that neither "ornament style" nor the proposed "playback" will have any effect whatsoever on the fermata?

    Hi Jojo, I can see some value in the playback button.
    However, there does seem to be a confusing downside.
    Suppose the user selects a staccato, brings up the inspector, and set playback=none.
    Does he expect that the note will no longer be played staccato?
    I think yes, but in reality, the playback=none will have no effect on staccato, nor on fermata, nor on tenuto, nor any other articulation which is not an ornament. A staccato note with playback=none, would STILL play as staccato.

    The problem is that all articulations share the same inspector. We don't have the capability to have different inspectors for different articulation types.
    An advantage of how I've implemented is that, if a user selects "ornament style = no ornamentation" on a fermata, then he should not be surprised that he there is no ornamentation.

    That being said, I certainly can implement an additional button if that is the consensus. I think it is not a huge change.

    Let's not get too sidetracked, thanks very much for your work so far! In theory it would be ideal to have a universal "Play" checkbox that would override all articulations and ornamentals, but its not up to you to do this. Perhaps you could create a "Play" checkbox that would only override your ornamentation and I will submit a bug report requesting that it be expanded to include the other articulations too/implement it myself when I have the time (I have a massive work deadline approaching).

    I really do think a checkbox is the best way forward though. Look at the notehead inspector to see how this should work. Notice that the Tuning, Velocity and Velocity type values are all editable and retained even if the Play box is unchecked.

    Also, just to be clear, you should rename "Ornament style" to "Playback style" even if you remove the "None" option and replace it with a checkbox.

    As for as me explaining the steps for adding a new ornament style, or implementing a new ornament rendition, I hope that first I have the chance to try to implement some styles per user's request. I'm sure that the simple framework I have put in place will need to be enhanced ton be a bit more flexible. I resisted trying to make it too flexible, as I didn't want useless features which had to be tested and maintained.

    If you want to request a new ornament style, please download https://musescore.org/sites/musescore.org/files/Baroque%20Ornaments_0.mscz, edit it to describe the style, rename the file to indicate your style name, and send it back to me (via post to this forum for example).

    I've considered the following, but resisted implementing of them in order to keep it simple

    1. a way to describe what to do when there are too many notes for the time slot, currently it just scales everything down homogeneously, or gives up and does nothing.
    2. need a way to specify notes of different length.
    3. accelerating or decelerating trill
    4. interaction with other articulations such as fermata

    The need to have parallel, hidden, "execution tracks", i.e., the lack of support for ornaments, is the single largest lacuna in this otherwise superlative application. While the above are good starting steps, substantial change seems inevitable, but this is no minor issue. The "one-UI-fits-all" inspector is obviously unsuitable to articulations with differing attributes. If some dialog other than the inspector, some ornament-specific subdialog of the inspector, or some other UI gesture is necessary (what about right-click "properties" that's already there?), let's think about it. I agree, though, that like a trill, we should start off slow.

    I'm uploading several views of a Baroque ornaments sample file.
    the mscz file -- you can play this back if you compile the 1518-articulations branch
    the pdf file -- examples of the musescore notation followed by the equivalent flattened representation.
    the mid file -- you can hear the playback even in older or released versions of musescore.

    I still plan to tweek these before the code is released, but I'm uploading these files just so the community can see what's happening and replay with broad comments if something is really objectionable.

    Take a listen to this file if it works on your machine.
    https://www.dropbox.com/s/10fd19uqn25bs5r/Baroque%20Ornaments.wav?dl=0

    AttachmentSize
    Baroque Ornaments.mid 3.43 KB
    Baroque Ornaments.mscz 22.59 KB
    Baroque Ornaments.pdf 226.33 KB

    If anyone wishes to have a different implementation for any of these ornaments, please download the "Baroque Ornaments.mscz" file https://musescore.org/sites/musescore.org/files/Baroque%20Ornaments_0.mscz, edit it to show me the implementations you'd like to see in all the cases given, and send it back to me (posting in a reply on this forum for example). I'll create a ornament style for the ones which make sense. Please include what name you'd like the style to be called.

    Check measures 7 & 8:
    Looks like the first quarter rest in measure 7 has no corresponding quarter rest entered in measure 8.

    Regards.

    You're right.

    Quick update on the articulations/ornaments work.
    I've pushed some new code onto the 1518-articulations branch.
    Anyone who is building musescore from source is welcome and invited to take a look at it.
    In this branch most of the articulations which are ornaments do play something, although
    not necessarily the right thing.

    If you are of the opinion that something is better than nothing then you'll be happy.
    But if you are under the impression that we need to make them as "correct" as reasonable, then I agree that there is more work to do before this branch is merged into (or rebased onto) the trunk.

    Mainly there are two big issues remaining.
    1) Deciding on the correct rendition of the baroque versions and default versions of the obscure articulations such as PrallUp etc..
    2) Updating the regression tests.

    Number 2 is tricky because of midi-out differences which this enhancement explicitly changes.

    Thanks for your continued work on this. Unfortunately it's not compiling again, even after a "make clean". I've attached the errors I get when building.

    Don't feel like you have to solve everything before merging into the trunk (except the compile issues which obviously must be fixed). I guess you want the underlying process more-or-less secure, but the details of implementation (i.e. exactly how a PrallUp should sound) can be ironed out in later pull requests.

    AttachmentSize
    compile_errors.zip 1.03 KB

    Hi Shoogle, thanks for the feedback. I'll look into this error.
    About your comment: >>Don't feel like you have to solve everything before merging into the trunk<<
    1) It is not me who decides when this gets merged.
    2) I don't believe it will be merged until the regression tests pass.

    The regression tests are an issue I don't yet know how to solve.
    Why? Because this enhancements actually intends to change the midi-out of any score which contains ornaments. So of course there will be lots of regressions.

    Hi Shoogle, thanks again for the comments. I'm looking at your compiler log message.
    I see that the errors (in your log) are indeed related to code I've touched.
    However, in my environment I don't have the errors. I.e., I can compile clean on my system.

    I can make some educated guesses about what the problem might be, but unless I can reproduce the problem, I'm not confident I can fix it.

    More to come...

    libmscore/articulation.cpp:311:46: error: call of overloaded ‘tag(const char [17], bool)’ is ambiguous
    xml.tag("playArticulation", false);

    Here you'd need to cast to int I think

    xml.tag("playArticulation", int(false));
    as there is no Xml::tag(QString, bool) and bool is not part of QVariant

    Thanks Jojo:

    I can try this. But If that's the issue, why does it work for me?
    Do some compilers automatically cast bool to int when resolving a method call?

    No idea, might be a quick in your compiler or in shoogle's?
    Maybe a matter of Qt version used? A quick Google search threw up http://doc.qt.io/qt-5/qvariant-obsolete.html

    Editt 1: Looks I'm wrong, a bool should work there, it is done in other places. So it may indeed be something on shoogle's machine that is causing the error

    Edit 2: Or maybe not, a bool variable should work, but maybe not a bool literal?

    Edit 3: I've tried this now and it works for me, no cast needed, so it should really be down to something in shoogle's setup, not in your code

    Thanks Jojo, I'll give it a try.

    Hi Shoogle, I've updated the code with Jojo's suggestions.
    As I cannot reproduce the problem, I don't know whether this changes fixes it.
    Would you be so kind as to try to compile and see if the problem goes away, or whether I need to search further?

    I've pushed the change to 1518-articulations,
    in particular you should take a look at: 428635064e0e8ffdf0c2a2936d8b71930564f222

    Thanks Jim,

    It's working on my machine now, thanks. I certainly hope there's nothing strange about the way my machine is set up. As far as I'm aware its just a regular Ubuntu 14.10 install but with Qt 5.4 instead of the default (5.3).

    I noticed you implemented the Play checkbox, thanks for doing that.

    Re. regression tests. I'm not familiar with these, do they simply compare Midi output before and after the pull request and fail if it is different?

    Hi everyone,

    I've pushed my latest commits to the branch 1518-articulations.
    I've been able to verify that the code in this branch passes the test_midi tests.

    In my opinion it is ready to merge into the nightly build for users to start testing and giving their feedback.

    The actual playback rendering of the ornaments is not yet stable. I'm happy with the trill, mordent, and prall, but others are more questionable. I need more user feedback from carving it into stone.

    Jim

    Currently the nightlies are built from the 2.0 branch, not from master. Not sure this PR would or should make it into 2.0.1?

    OK, good to know.
    However, the advertisement on the nightly build is the following.

    Nightly versions are produced from the code of MuseScore that is being developed. They are intended for testers and advanced users who want to experiment with new features, or need access to the latest bug fixes and are willing to risk the instability of an unfinished product. (according to https://musescore.org/en/download#Nightly-versions).

    Without new features going into the nightly build, what's the mechanism for users to test new features and give feedback to developers? I'm not saying I know the answer, just playing devil's advocate and asking.

    This is a temporary measure until 2.0.1 gets released, which should be pretty shortly.
    Currently we'd want that to get tested by a wider population than just the few that build MuseScore (from master) themselves.

    That's my understanding anyhow.

    I agree it's not suitable for 2.0.1 which should just be for fixing bugs that weren't fixed in time for the official release of 2.0, not major new features. However, it is perfectly possible to submit a pull request to merge into the "master" branch (which is set to become 2.1). Now that the code passes the regression tests I think it is ready for merging into "master".

    I'm sure the nightly builds are popular on Windows and Mac, but on Linux at least I would imagine it is far more common to use Git and compile from source than use the nightlies. Git makes the process of keeping up-to-date much easier than having to manually download and install each time. I would guess that most development is also done by Linux users, but I don't have anything concrete to back this up.

    I've improved the say the baroque ornaments are rendered.
    Please take a look if you are interested.

    These changes have been pushed to the branch 1518-articulations.

    You can listen to the midi file even if you don't have access to the development tree.

    I believe these are correct, except for the unfinished Schleifer.

    AttachmentSize
    Baroque Ornaments.mscz 22.03 KB
    Baroque Ornaments.pdf 243.29 KB
    Baroque Ornaments.mid 3.53 KB

    They all sound good to me, but if I export as Midi and then re-import into MuseScore they don't all look exactly like your example PDF. Perhaps this is intentional and the PDF is only supposed to give a rough idea?

    How they look on Midi import:

    Turn_revTurn.png

    Has there been any progress with the pull request?

    Hi Shoogle, that is a very good test. Thanks for thinking of it.
    Let me look into this to see if I an better understand why its happening.
    I'm most curious of the 1/16th rest at the end of the measures. That space should be filled completely.

    You're welcome. Visually you want the notes to fill the space, even on Midi import, but not in terms of sound (see gate time) otherwise you won't be able to hear where one note ends and the next note begins if it is the same pitch (with wind instruments anyway, this won't be a problem with the piano because the note fades with time). The space at the end reminds me of how Midi files would look imported into MuseScore 1 where the gate time gap was interpreted (incorrectly) as a rest on Midi import. Perhaps something similar is going on here. Your solution should not be to remove the gap, but to use the same gap as is defined for the current instrument in instruments.xml.

    I don't know quite how the code works, or whether this is even possible, but perhaps the solution to the general problem of notes not looking correct on Midi import would be to use MuseScore's existing note definitions instead of defining your own.

    So instead of:

    $trillSubNoteLength = 10 Midi ticks

    Try:

    $trillSubNoteLength = $lengthOfNormal32ndNote

    (But don't forget to pad the gate time gap with silence).

    This has the advantage of updating automatically if future versions of MuseScore use a different gate time, or if the gate time is different for legato or staccato notes, etc. It might even be possible/desirable to call up the normal 1/32nd note function that MuseScore uses rather than creating your own definitions:

    Instead of:

    if $noteIsTrill then
        #divide it into small notes that each have 10 Midi ticks.
    endif

    Try:

    if $noteIsTrill then
        #call MuseScore's 32ndNote() function (if there is one).
    endif
    

    Can you explain what gateTime is. I've seen this in the code, but didn't know what it means or how to incorporate it into my calculations.

    I can explain the concept, but I don't know how MuseScore goes about implementing it. Hopefully there is a way for you to piggyback off MuseScore's current implementation without writing your own code.

    It's quite simple really: say I have a bar of 4 quarter notes all playing middle C. If on playback each note was really held for a quarter of a bar there would be no way to tell where one note ends and the next begins. That would be a 100% gate and would sound equivalent to a single whole note (think "legarto"). Instead, you need a small gap between each note (think "staccato"), so you might choose a 90% gate time. Now each note lasts for slightly less than its full value, but you can hear where each note ends and the next begins.

    This whole issue is irrelevant on the piano because the note fades out after the initial "attack" so it is easy to hear where the next note begins even with a 100% gate. But with a wind instrument the note stays at the same volume so the gate time is very important. Because of this, I believe the gate time is different for each instrument and is stored in a file called instruments.xml. Hopefully MuseScore has already looked up this value and stored in a variable (probably gateTime) so you don't need to look it up manually yourself. (It is also possible that MuseScore uses different gates depending on whether consecutive notes are the same pitch or not. If the notes have different pitches then you can get away with a 100% gate and it might even sound better than having a gap. If they have the same pitch then you need a gap.)

    A perfectly justifiable shortcut to take would be to only implement gateTime for the final sub-note of the ornament. So for a trill, all of the subnotes should last for a full 32nd note except the final subnote which needs to be cut off early in case the next proper note is at the same pitch.

    I've discovered what I think the problem is.
    It seems musescore represents each note as a container of events.
    Each note is resolved to a resolution of 480 ticks per quarter note.
    However, within a note sub-events are on a resolution of 1000 milli-counts.
    Screen Shot 2015-04-30 at 11.41.20.png
    In the trill shown here, the dotted half note contains 480*3=1440 ticks.
    Thus each of the notes of the trill SHOULD have 1440/24=60 ticks.
    Instead since the events within the note are on a resolution of 1000, 1000/24=41 milli-counts. That is 41.66667 rounded down to 41.
    This corresponds to 59 ticks rather than 60 ticks for the first 23 notes, and 83 ticks for the final note: (59*23+83)=1440.

    I believe when you export to a midi file and then read that back in musescore tries to resolve the notes to something human readable and cannot (or does not) represent do a good job on this extremely difficult case. What midi-in sees is a sequence of 23 notes each of which have 59 ticks, followed by a single note of 83 ticks.

    I wish musescore didn't use a 1000 resolution for its internal representation, but rather used some multiple of 480: e.g., 1920, or even 4800. Or better, it used rational numbers (ratios of integers) rather than integers.

    I'm not sure what to do about this problem.
    I can think of some very complicated solutions, but no easy one comes to mind.
    I'm open to suggestions.

    AttachmentSize
    Screen Shot 2015-04-30 at 11.41.20.png 16.74 KB

    Using something that isn't a multiple of 480 does seem to be a bit of an oversight on behalf of the developers.

    Ideally the subnotes should by treated as proper individual notes in every way except for how they are displayed. However, if that is not possible then I would make up for the rounding errors manually: Say your note should be 33.33333 milli-counts.Currently you round this to 33 and make up the difference at the end. Instead, round every third note to 34 so that the length is correct on average. It should be possible to make a general rule involving modulus (division remainder) or something like that.

    I found a pretty good and easy fix for this.
    I just increased my own resolution for calculation purposes.
    Rather than using 1000, I now use 1000*(ticks of the note).
    So for a dotted half note, the resolution is 1000*(480*3)=1440000.
    I divide back out the (ticks of the note) before pushing the event to the musescore event list.
    This is not perfect, but it is very very good, and much better than before.
    I'm attaching the midi-out file which I get now.

    I've noticed there seem to be a problem with PrallUp and PrallDown. I'll look into that soon.

    In the mean time, I'm uploading the fix on the branch: 1518-articulations
    The latest commit is 6e5996c763168d58768129238e53a37852787bc4

    AttachmentSize
    Baroque Ornaments.mscz 24.61 KB
    Baroque Ornaments midi-out3.mid 3.53 KB

    This looks much better! It's not perfect, but the MIDI importer isn't perfect even for "normal" notes so I don't think it's something you need to worry too much about.

    I'm not sure I agree that the notes in an ornament are necessarily "proper individual notes in every way" - at least, not necessarily. Acciaccaturas, trills, and unmeasured tremolo in particular are not not normally played in tempo. And the units are different anyhow - 480 is an absolute number of ticks, 1000 is relative to the length of the note. This same unit is used for things like affecting the start time or length of a note - which a user can currently do through the Piano Roll editor - and most users probably wouldn't want to have to think in ticks, although no doubt in some cases, that *would* be easier.

    I meant "proper" in terms of how they are handled internally. If he can call an existing function to handle subnotes then he will benefit from future improvements to that function (e.g. changes in gate time for legarto vs. non legarto, etc.) whereas if he defines everything manually he won't get the improvements and his code would diverge from the main code. You are right though, it may not always be possible or appropriate to treat subnotes as individual notes.

    I haven't looked at the code myself so I don't know how the units are handled, but it seems to me that in many cases the user will want to divide notes-lengths into rational fractions like 1/2, 1/3 etc, so 1000 may not be the best choice. Milli-counts were probably not designed with ornamentation in mind so it might be necessary to use a different system in this case. 1000 is at least an easy number to work with and is big enough that most rounding errors will be insignificant.

    A known limitation of the current implementation is that the following two
    trills are unfortunately not played the same.
    Screen Shot 2015-04-30 at 12.14.50.png
    The first trills from C to B, whereas the second trills from C# to B.

    I think this is a rare case. But it is wrong nonetheless.

    AttachmentSize
    Screen Shot 2015-04-30 at 12.14.50.png 9.89 KB

    I've improved the way ornaments handle accidentals.
    Here is an image of a test case as entered by hand into musescore.
    Screen Shot 2015-05-04 at 16.12.44.png

    Here is what it looks like after midi-out and midi-in
    Screen Shot 2015-05-04 at 16.37.13.png

    AttachmentSize
    Screen Shot 2015-05-04 at 16.12.44.png 33.56 KB
    Screen Shot 2015-05-04 at 16.37.13.png 32.94 KB

    Rhythms look great! Accidentals look to be handled properly, except in the 2nd to last bar which I don't know enough music theory to assess. Does a mordent on a double-flat really not change pitch?

    Hi Shoogle, it looks like you are observant. As for your question, I would say that a mordent on a Bbb descends to the A, in the key of F, but to Ab in the key of Eb.
    This is exactly what I intended to happen.
    However, like you I would not bet a high sum of money that every musician will agree.
    It is an edge case of an edge case of an edge case, which software developers love.

    However, you would not really use a Bbb in the key of Bb. But you might have one in the key of Eb in which case the ornament would play as expected without controversy.

    Musescore does not implement glissando as an articulation. Nevertheless it is somewhat similar from the perspective of the end user. Please see (and comment on) the discussion of glissando playback.

    https://musescore.org/en/node/59356

    Great work on these! I've only tried a few, but it's good to hear them!

    Regarding turns: in addition to their used placed directly above a single note, they are also commonly placed *between* notes. In order to achieve this in MuseScore, you need to attach them to a particular note and then move them. My guess is that half the world is placing them on the first note and then moving them to the right, the other half is placing them on the seocnd note and then moving them left. Your playback supports the latter, and this does make sense, since the effect *is* basically similar to that of placing the turn on the second note. Still, it might be nice to provide an option to have the turn played *after* the note to which it is attached, to support cases where people have attached the turn to the first note of the pair rather than the second.

    Also, don't forget the trills on the Lines palette.

    Hi Marc to do this I think there needs to be some extra information in the data base.
    Normally the playback does not depend on where graphical objects have been stretched to, but rather where they are attached. Consider the hairpins, if I simply stretch the graphically it has no effect. Rather they must be end-attached to the note the hairpin semantically attaches to.

    There is nothing in the DB currently that I know of which corresponds to this.
    Do you have any suggestions?

    I'm not suggesting looking at the physical location - although actually, that's quite possible - just look for a position X offset in pos().

    What I was suggesting is just a checkbox or drop-down selection in the Inspector to control whether a turn is applied directly to the note it is attach to, or whether it should actually be played *after* the note, before the next (like a grace note after).

    FWIW, I disagree. If a turn should be play for the note before, just attach it to the note before.

    There is one thing I find disturbing with the implementation, but it was also the case for fermata. Now any articulation has 3 controls (time strech, play, ornament style) while for some of them, say staccatto, it doesn't make sense. A gate time would though... We would probably need a different model to handle this...

    I would agree that if users could be educated to attach between-note turns to the second note of the pair and then moved to the left, we wouldn't need additional controls. I just suspect a fair amount of music has already been created with turns attached to the first note of the pair and then moved to the right, however. Maybe it's enough to just tell people they need to re-enter their turns.

    The current architecture of the code only effects the way a note is played by its own articulation, not the previous or next. However, it would be great if articulations could also effect the surrounding notes. For example a staccato should also shorten the previous note. At least that is how some musician like to play it--staccato has space before and after.

    I didn't look to close at how grace notes work, but sometimes you want the grace note itself to start on the count, but sometimes you want the note to start on the count and the grace note start and end before the count.

    This is similar to the turn in that sometimes you want it to start and finish before the note it is connected to.

    If we want to make the turn be able to apply to the next note, then it needs to turn around the pitch of the next note. This seems to mean that from the program's perspective the previous note (i.e, the note the turn is attached to) is irrelevant. Right?

    We could add a property (and associated graphical control) to indicate that the articulation/ornament starts on the count or ends on the count. This could be very useful for lots of articulations. It could fit nicely into the current architecture. I'd have to look ahead for articulations which are marked end-on-count. and make a similar calculation as is made now but sort of right-justified rather than left-justified.

    Could work nicely.

    (5) is not a problem with automatic ornament realization. I have "hand coded" ornaments, i.e., written them out in small notes, and the decline in volume and wrong tone quality really damages work. The gorgeous adagio of BWV 1042 (https://musescore.com/user/1831606/scores/864526) which I recently posted is a case in point. Except for the ornaments, all hand-done, the "electronic violin" is wonderful. I can't imagine what a good solution to this would be, and one is necessary (what do other programs do?), but it is not part of the realization problem.

    (sorry, this should have been under the posting below)

    "(5) is not a problem with automatic ornament realization."

    Strictly speaking, you are right, as it affects also manual realisation of ornaments. This issue belongs to a wider topic, the lack of 'realism' (whatever meaning we assign to this word) in a mechanical playback.

    However, it does affect automatic realisations too and forces them to work on an even weaker ground, contributing to put their usefulness even more in doubt.

    Thanks,

    M.

    The heroic effort gone into this endeavour is surely to praise; however I am far from sure that any automatic ornament realisation has any real usefulness, in particular for pre-classic music.

    I am aware that my view is perhaps heterodox and I am not specifically referring to Jim implementation, but to the mere concept of automatic ornament realisation. I have already expressed elsewhere my main concern, but there are other, in a very rough order of importance.

    1) Even limiting ourselves to, for instance, early XVIII c. music and to just the trill, there is no such a think as the "correct trill". Trill is quite different according it has a two-note or a one-note resolution; the trill in an Allemande is not the same as the trill in a Sarabande or a Courante, and so on (and this without even entering into specific cultural differences, like French music versus Italian music...).

    2) Only a subset of the used ornaments is recognised by MuseScore, by SMuFL or, I believe, by any general notation programme. I'm speaking of fairly widely used ornaments: for instance, many of the ornaments used by French Baroque music are not recognized and are unlike to be in any non-specialized software in any near future. On the other hand, the set seemingly familiar to notation programmes include ornaments which I have never met in decades of Baroque and Renaissance music playing, like for instance many of the prall variants.

    3) Written ornaments are only a subset of the ornaments actually played: for instance, not rarely sources omit cadential trills, but they *have* to be played nevertheless.

    4) Ornaments are only one aspect of 'ornamentation': inegalité, passing notes, diminutions, etc... are, each in its capacity and context, an integral part of the execution. Some are, by their very nature, left to the taste of the player, but some, like inegalité, are fairly predictable (but again, very difficult to render algorithmically).

    5) On the technical side, ornament notes tend to be fast and, in many occasions, (almost) only the attack part of the sample is played, resulting in an unnatural sound and in noticeably lower volume in any non-keyboard instrument.

    All in all, the result of any automatic ornament realisation is so distant from the reality of any acceptable 'real' performance that, at least in my opinion, its usefulness turns out to be quite limited.

    Thanks,

    M.

    Hi Jim,

    A few comments about your pioneer implementation of ornament realisation which finally ended up into the main code. I'll refer specifically to the Baroque style and I'll try not to let my ideas on automatic ornament realisation to influence my comments...

    Of course, there inevitably is a part of personal taste in these areas; I'm trying to summarize some common practices from my personal experience and, above all, from the performances of reputed players I appreciate.

    1) Trills 1 appoggiatura: the trills should begin with an audible appoggiatura on the superior note; roughly speaking it could take from approx. just the time of one upper-lower note alternation (for lively tempos) to approx. one half of the note (for slow tempo), reducing the 'trilled' part accordingly.

    2) Trills 2 'trilled' part: your implementation links the trilling speed to the tempo speed. In my experience the trilling speed is almost independent from the tempo: with faster tempos and shorter notes, there will be less alternations and vice versa with slower tempos and longer notes. Currently, your 'fast' trills sound to me somewhat too fast and the 'slow' trills way too slow. Something in between?

    3) Trills 3 resolution: each trill should have a resolution, either of one note or of two notes; two-note resolutions are tricky and involve a third note. They may be required if a pair of appoggiaturas are notated at the end of the trill, but let's leave it for another occasion.

    The main characteristic of the one-note resolution is the break between the trilled part and the resolution note. The resolution note may be notated explicitly (for instance in the trilled dotted crochet + quaver pattern) or not, but it should always be there in the playback; if not notated, it will be the same note as the note following the trill and may take more or less 1/4 to 1/8 of the trilled note.

    Before the resolution note, there should be an audible silence; in the case of the pattern quoted above, the silence may take almost the whole dot.

    4) Mordents and similar: it seems to me they are also realised with a speed which depends on tempo; again, this does not match actual performances: the quick ones sound fine, but the slow ones are way too slow.

    5) Cross: first of all, I'm very happy you thought about it! Unfortunately it is a rather tricky ornament.

    5a) In cadential positions and on the dotted note + short note pattern, it is a 'long' ornament, in practice the same thing as a trill (with all its components: appoggiatura, trill, break, resolution)

    5b) In other position, it is a 'short' ornament, like a 'doubled' mordent with an initial upper note or on occasions just a regular mordent. The current realisation which alternates the main note with the note below is totally new to me.

    6) Augmented seconds in some lower note ornaments: when the main note is sharpened (or un-flattened), it may happen to (temporarily) be an augmented second above the note below according to the key signature. If the ornament requires the note below, this should be raised to avoid the 'wrong' interval. Note that this is independent from any (extra) accidental existing or lacking in the previous notes.

    7) Rhythmic patterns: by their very nature, ornaments are not measured. So, please do not obtain the length of their notes by diving the main note (or the beat) by a power of 2. Use as a base a prime number as 13, 21, 111, even an irrational number (PI, e, ...), whatever you like, but not a power of 2! Possibly, even better may be the use of a fixed absolute duration, with small variations for different tempos if you want.

    Unless I forgot something, I believe these to be the most important points; appoggiatura duration is a too vexata qæstio and the other ornaments are too rare or too vague to be worth lucubrating on.

    Thanks,

    M.

    Hi M, many thanks for your detailed feedback. It sounds like you have lots of experience with these ornaments in real life than me. I may have indeed made some unfortunate errors in the implementation. One thing you have to keep in mind in your criticism is that I wanted to keep the implementation simple. Why? Because if I tried to make it too elaborate, there would be more and more discussion and it might never get done. My concept of having different ornament styles, is hopefully general enough to allow me (or someone else in the future) to implement different algorithms for calculation the trill rendition.

    There is another very different approach someone could try to implement. Rather than setting up build-in patterns, this alternate approach should allow the user to set up note/ornament renditions within his score. Musescore would not try to auto-calculate ornaments at all but rather there should be some reference data ability in the score. The user should be able to say, THIS trill corresponds to Ref-1 pattern, and THAT prall corresponds to Ref-2 pattern. I think this type of approach would allow users to create any type of ornament they want. Unfortunately I don't know enough about the deep implementation of musescore to really suggest how such a new concept could be introduced.

    First of all, I was not pointing fingers or marking errors; if I gave this impression, I apology; I am trying to give the hints I can to improve an area which is rather important for me: 'early music' support in MuseScore.

    Baroque ornamentation is a complex thing; when, back in the 70's, Frederick Neumann re-organized and summarized the (then) current situation, he ended up with a 600-page book; since then, the researches and the discoveries have gone on. This is why, in the past years, I have always urged against opening this can of worms.

    100% perfection is not possible and reasonable approximations should be acceptable. However, if a programme includes a "Baroque style" ornamentation feature, it should be an approximation within the range of solutions generally accepted (or at least recognized) by the Baroque music specialists.

    In the past years, I have tried, with some success, to diffuse the usage of MuseScore within the circles of 'early music' players I'm in touch with. The latest version helped me a lot in this. If the next version is going to include a non-plausible "Baroque" implementation of ornaments, this would act against MuseScore credibility in that area (a small 'market' share, I know, but everything counts, I believe).

    1) A rather simple solution could be to drop the multi-style options completely and implement ornaments as 'modern' practice says they should. Baroque music players would simply turn ornament realisation off and do what they are already accustomed to do: 'hear' internally the ornaments (the written as well the unwritten ones) while reading the score or hearing an unlearned performance.

    A global preference switch "Turn ornaments on / off" would be very helpful for this.

    2) If a Baroque alternative is considered important, it should follow the basic, general guide lines of Baroque ornamentation. Different players could argue indefinitely about small details, but a general consensus about general guide lines does exist. Second-level approximations (French Baroque versus Italian Baroque, or Gavotte-like trill versus Sarabande-like trill) are less important, if a well-thought average rendition is chosen for each ornament: the user is aware -- we hope! -- that the realisation is mechanical and anyway the audible result (edit: the *global* audible result of the whole score) falls short in so many other respects that these are secondary.

    Assuming the current implementation of 'modern' style is correct / acceptable, some basic differences are necessary, thought:

    • 'small note' speed should be independent from the tempo or only very slightly dependent on it (but total independence would be an acceptable approximation, in my opinion; getting more opinions from other instrumentists with a solid background in Baroque music would help);
    • multiple ornaments on a single note could be ignored (in 30+ years of playing Baroque music for winds and strings, I only remember the Tresieme Concert Royal by Couperin as an example of multiple ornaments per note), but grace notes before and after should be taken into account, as they are an integral part of the ornament;
    • a few rather important points would remain uncovered, like supplying the trill resolution if not written out or multiple-meaning ornaments like the French cross.

    My impression (to be verified, of course!) is that many Baroque music players would prefer solution 1) to a solution 2) with "too many" shortcomings (where "too many" is obviously subjective).
    __________________________

    The idea of a repertory of ready-made patterns to draw from sounds intriguing, but I am not sure it would actually fulfil the expectations, unless the patterns would allow to specify things like:

    - hold upper note for 42% of total note duration
    - alternate with upper note at 400MM for 15%
    - silence for 18%
    - repeat main note for 25%

    (which is the description of a possible trill pattern) but I suspect this would make the underlying pattern 'interpreter' rather complex to implement and the patterns themselves rather complex to define.

    I think the main reasons for this complexity does not come from the multitude of possible patterns, but because different styles have different basic guide lines.

    Thanks,

    M.

    Regarding 1/, what would you advise as a good default for a global setting as of now? ON or OFF ?

    The multiple selection is fine by me. Maybe "Baroque" needs a better label.

    Regarding 2/, as a drummer, this discussion is hard to follow. What is "Modern"? currently we only have "Default" and "Baroque". What would be helpful is to define what you think should be different in each style we have right now, knowing the framework we have. And how we could add more features to the framework in order to add more ornament styles if needed.

    "ready-made patterns" is one step further. Let's focus on the two points above first.

    @lasconic:
    " What is "Modern"? currently we only have "Default" and "Baroque".":
    ok, replace "Modern" in my post above with "Default" (or vice versa).

    "Regarding 1/, what would you advise as a good default for a global setting as of now? ON or OFF ?
    The multiple selection is fine by me.
    "

    The main point of solution 1) is to drop support for multiple ornament realisation styles, keeping only the current "Default" (as it is now or with the adjustments performers of "Default" music may suggest).

    As things are now, I would assume that the global default setting (yet to be implemented) for ornaments realisation should be ON, so that the average user would get ornament playback by default.

    "Maybe "Baroque" needs a better label.":
    Not necessarily; the term has a rather defined meaning and refers to a rather defined (set of) practice(s). My point is: if it is there, it should be within (a subset of) those practices.

    "Regarding 2/, [...] What would be helpful is to define what you think should be different in each style we have right now, knowing the framework we have.":
    I know very little about post-Baroque ornamentation and, from other comments, I assume the current "Default" implementation is generally fine for "Default" music.
    In my opinion, the most important structural differences that the "Baroque" style requires from it could be: A) independence from tempo, B) grace notes within ornaments, and, if possible, C) supplying unwritten trill resolution, D) non-measured timing; each is described in more detail in the posts above. 'Fine tuning' the durations of individual ornament sections, to find the best average implementation to use in all cases, can be a second step.

    "in order to add more ornament styles if needed.":
    I cannot think of more styles needed for 'learned' Western music. About other musical cultures or 'ethnic' areas I know nothing (but I suspect it could be another can of worms).

    ""ready-made patterns" is one step further. Let's focus on the two points above first.": Agreed!

    Sorry, I don't understand what the expression "ready-made patterns" means. Can someone please explain this concept further. Keep in mind that the same ornament might appear of any type of note, I.e., over a whole note, half note, dotted 16th note, or any note of a triplet, 5-let, 17-let etc. It is not clear to me how the same ready-made pattern fit would "fit" on any type of note. Also keeping in mind that the user can change the play tempo, and also change the key signature such as from 4/4 to 2/2, or 3/4 to 6/8.

    As said earlier, I would prefer to postpone this discussion :) and focus on improving the existing.

    Apparently we all agree that the default style is ok for now. The baroque style could be improved. Maybe it would be better to create another topic to discuss the baroque style in particular and see what we can do to make it better? Not dependent on tempo seems to be the first thing to address?

    Congratulations on the successful PR, Jim!

    I am personally very happy with your implementation of the ornaments and the glissando. I see no reason why a lack of standardised definitions should prohibit MuseScore from making some attempt at playback based on popular, straightforward interpretations. Clearly many people will have their own idea about how things should sound, but they are free free to disable it or customise using hidden notes, etc. If you want to add a few more styles, or create a little "how-to" so that others can create some styles, I'm sure that would be very much appreciated but well beyond the call of duty. I think you have chosen very sensible defaults that should be fine for most users, most of the time.

    Thank you for your hard work!

    I finally downloaded a new nightly build, and this is simply fantastic! But something pretty big is still missing. Marc Sabatella mentioned it above (https://musescore.org/en/node/56281#comment-279831): "Also, don't forget the trills on the Lines palette."

    Glad you like it. Thanks for the comment.

    Please help me understand something. What should the trill line do? How is it different from a normal trill? Does it mean that each of the notes under the line are to be treated as they have an individual trill over them?

    Actually, a trill line is basically exactly the same as a trill would be, except that it has the addition of visually extending for the note's entire duration. You'll find that in MuseScore the line automatically fits itself to the proper length for the note it's attached to, and won't extend over more than one note. If there's not enough horizontal space before the next note, it actually makes itself look exactly the same as the corresponding articulation/ornament.

    In the attached example, the last trill, which looks like it's from the Articulations & Ornaments palette, is actually the same kind of line as the others—select it and see in the Inspector.

    AttachmentSize
    trillline.mscz 7.92 KB

    The trill line *is* a normal trill. Notating a trill *without* the line is the exception, but as far as I know, it doesn't mean anything different from a normal trill line. Leaving out the line is, I assume, just something you do if space is tight, or if emulating the style of some particular historic edition that didn't use the line. But the norm according to modern engraving standards is to use the line (at least for long notes).

    There is already something done for trill here https://github.com/musescore/MuseScore/blob/master/libmscore/cmd.cpp#L273 but it's for sure not the right place so the noteevents are cleared later on.

    Apparently trill lines CAN span chords. So in this case, I'm not sure what the playback should do.

    I'd say it's not hugely important to support that, but if you're looking for the "expected" result, I'd say, treat it as a bunch of individual trills.

    I've created a new pull request for the implementation of line type trills.
    It is called trill-line-playback.

    It is a limited implementation. It basically looks at the note on the track and implements a trill (of the appropriate trill-type on each of the notes (on that track) which the trill line overlaps.
    Since this will normally be just one note, that good for now.

    I will upload some test cases, in the coming days.

    I've been using the trill playback quite a lot recently and I've discovered a problem which I intend to fix. It exhibits itself when you set the tempo very slow such as for adagio. quarter note=40 or 30 etc. If a trill is placed over a half note, or whole note the trill plays very slowly.

    This problem is caused by an insufficient heuristic which I programmed.
    I put an upper limit on trill speed to never be more than 16 notes second.
    This limit means that even in 2/2 (cut time), or if you turn up the meter very fast,
    you don't hear garbage in place of the trill, but rather you hear something that sounds musical.
    But I didn't put a lower limit.

    I'm attaching a score which exhibits the problem.
    This is an actual piece I use for rehersal, playing a physical oboe along with the musescore playback.
    The trills in measures 14 and 15 sounds nice, but
    listen in particular to measure 22. It sounds not like a trill at all.

    AttachmentSize
    andante.mscx 231.94 KB

    Hi Jim,

    I just wanted to let you know about an issue: #66781: Trill stops after first part of tied note Thanks again for all your good work.

    Anyone here know how to do an accidental trill? Like, that trills up a half step instead of a whole? Thanks,

    The trilled note obeys the accidentals which appear earlier in the measure. So if you want for example to trill between a Db and C, you can put the trill symbol on a C, and previously in the measure make a note D with a flat accidental. You can make the note invisible and silent.

    This trick won't work of course if the trill is the first note in the measure :-(

    Please feel free to file an enhancement request to add this feature. It is something that should be supported, but the initial implement tried to be very simple in the hopes of getting people's feedback.

    A difficulty with ornaments involving accidentals is that the trill just involves one "derived" note, but some ornaments involve several, such as the turn. I can easilly imagine how to extend the GUI to allow a trill to be denoted with an accidental, but it is not so clear to me for the turn and other ornaments.

    Thanks Nicolas for the heads up. I made some comments on those threads.

    Syndicate content