Hi, I posted this same topic in the MuseScore Technology Preview forum, hoping to attract more comments; so far, it attracted none! So, while apologizing for the duplication, I try with the dev list. ____________________________
First of all, this post does not refer to the UI at all, but to the internal categorization of score elements; as far as the UI is concerned, I assume articulation symbols and ornament symbols can be kept in the same palette (as now) or divided between several palettes, regardless of the internal structures and categories. I believe there be some reasons for qualifying articulations and ornaments in some different way, at least internally, namely: 1) Ornaments may (actually should) apply to individual notes, not to chords. For instance, in this passage from the /Pièces à une et deux violes/ (third book) by M. Marais: <http://dev-list.musescore.org/file/n7579521/Marais_Livre_3_p_25_ms_4-6.png> there is a difference between the first chord of second measure -- where the /tremblement/ is applied only the E -- and the chord at the middle of the third measure, where two /tremblements/ are applied one to each of notes G and E. On the other hand, there is probably no need for (real) articulations to apply to individual notes: chords are enough. 2) As far as playback is concerned, they have to be managed differently: articulations have to do with timing (either with time gate, for things like staccato, portato, ... or with tempo, like fermatas); while ornaments result in the note being split into several sound events. The current implementation (see here on github <https://github.com/musescore/MuseScore/blob/master/libmscore/rendermidi.cpp#L1342> ) tries to deal with both types at the same time, but the result is partial as, for instance, it depends from the order in which the different elements have been added. If the above reasoning is correct and sensible, articulations and ornaments can be differentiated in one of several ways: A) A new *Element::Type::Ornament* enum value can be added and the *Articulation* class split into two different classes; this may raise backward/forward compatibility issues? B) A new member variable can be added to the *Articulation* class, to distinguish elements which are attached to chord and elements which are attached to notes. C) A new member variable can be added to the *Articulation* class, holding a subtype of some kind (articulation, ornament, fingering( see below), ...), which appropriate code would then dispatch to the chord, to the note, position accordingly, render accordingly and so on. In all cases, ornaments would presumably end up being stored in the note *_el* list. _______________ A case apart are the four lute fingering symbols visible near the end of the Articulation palette. They were implemented as articulations, rather than as fingerings, as normal fingerings are textual elements, while these four symbols are, well..., symbols and, for them, all the Text machinery would only create problems. They too should be applied to notes rather than to chords; see for instance, this excerpt from D. Gaultier, /Pièces de luth.../, Paris 1670, first chord, where the first finger fingering applies to two notes only out of four; <http://dev-list.musescore.org/file/n7579521/Gaultier1670_020_fingerings.png> For this reason, they could possibly be treated the same (or similarly) as ornaments. Any idea anyone? Thanks, M. -- View this message in context: http://dev-list.musescore.org/Articulations-and-Ornaments-better-to-separate-them-tp7579521.html Sent from the MuseScore Developer mailing list archive at Nabble.com. ------------------------------------------------------------------------------ _______________________________________________ Mscore-developer mailing list Mscore-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mscore-developer
