trill and turn implementations

• 2 years ago

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

upload
Attachment Size
trilltest2.mscx 8.41 KB
trilltest2.mid 488 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.

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.).

Attachment Size
trill.png 6.2 KB
fermata_trill.png 11.29 KB

In reply to by shoogle

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.

In reply to by shoogle

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.

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.

In reply to by David Bolton

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.

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 ;)

In reply to by Lamardelmy

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.

In reply to by jim.newton.562

(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."

In reply to by BSG

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

In reply to by jim.newton.562

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

In reply to by BSG

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.

In reply to by KostisP57

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.

In reply to by jim.newton.562

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.

In reply to by KostisP57

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.

In reply to by jim.newton.562

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

In reply to by KostisP57

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.

In reply to by KostisP57

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.

In reply to by jim.newton.562

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).

Attachment Size
Tableofornaments750.jpg 59.75 KB

In reply to by KostisP57

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.

In reply to by jim.newton.562

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.

Attachment Size
Schleifer.png 29.74 KB

In reply to by KostisP57

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.

In reply to by jim.newton.562

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)?

In reply to by BSG

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?

In reply to by jim.newton.562

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.

In reply to by KostisP57

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.

In reply to by KostisP57

hi KosrsisP7, The current framework for ornaments is not sufficiently flexible to implement the style described in //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 //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.

Attachment Size
ornaments.pdf 514.73 KB
dupuits.png 211.05 KB

In reply to by jim.newton.562

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.

In reply to by shoogle

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."

In reply to by Isaac Weiss

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

In reply to by Isaac Weiss

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.

In reply to by shoogle

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

In reply to by jim.newton.562

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).

    In reply to by shoogle

    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.

    In reply to by jim.newton.562

    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.)?

    Attachment Size
    compile_errors.zip 1.5 KB

    In reply to by shoogle

    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.

    In reply to by jim.newton.562

    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.

    In reply to by shoogle

    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.

    In reply to by jim.newton.562

    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.

    In reply to by shoogle

    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!

    In reply to by BSG

    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