Quantcast

Articulations and Ornaments: better to separate them?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Articulations and Ornaments: better to separate them?

Maurizio M. Gavioli
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:

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


For this reason, they could possibly be treated the same (or similarly) as ornaments.

Any idea anyone?

Thanks,

M.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Articulations and Ornaments: better to separate them?

Jim Newton
It seems to me that the only thing ornaments and articulations have in common is the manner which they get rendered in print.  Although, it get the impression when dealing with the code, that they should both be represented as two subclasses of some common class.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Articulations and Ornaments: better to separate them?

Maurizio M. Gavioli
Jim Newton wrote
It seems to me that the only thing ornaments and articulations have in common is the manner which they get rendered in print.  Although, it get the impression when dealing with the code, that they should both be represented as two subclasses of some common class.
This is my impression too! I was trying to get some comments from the devs about possible alternatives and best practices...
Loading...