Articulations and Ornaments: better to separate them?

• Sep 10, 2015 - 23:29

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, 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 which would suggest to qualify 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:
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 to one note only -- and the chord at the middle of the third measure, where two tremblements are applied one to each note.

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 ) 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 several ways:

A) A new Element::Type::Ornament enum value can be added and the Articulation split; 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;
Gaultier1670_020_fingerings.png

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

Any idea anyone?

Thanks,

M.


Comments

Another example why it should be wise / useful to split them.

If an articulation and an ornament are applied to the same note, in several cases the rendering depends on the order in which they are added. For instance:
NOT FOUND: 1

Of course, it would be possible to hard-code the stacking order of any possible combination of pairs (or more) of Aticulation-Ornaments, but splitting the group in two (according to any of the above listed methods) would greatly reduce the complication.

In reply to by chasejordan

@chasejordan: thanks for the suggestion. I am a string player myself too so I presumably see your point.

However, I have a two-sided question:

1) This thread has to do with the internal classification of score elements as seen by the programme. Are you asking that the internal architecture of the programme should have a class (or some other coding device) for bow markings separating from the current Articulation class?

2) Or are you telling that bow markings could benefit from a palette of their own in the User Interface?
If this is the case, as there are only two bowing marks, I wonder if this would make for a rather empty palette.

It is true that the "Breaths and Pauses" palette only has three icons, but we should try to optimize between too crowded palettes in which is not easy to find the needed symbol and too many palettes across which it is difficult to identify the relevant one.

So, if this is your concern, would you mind creating a specific feature request for this palette split in the issue tracker ? It would give interested peoples a chance to discuss this point.

Thanks,

M.

In reply to by Miwarre

I don't think an additional palette is necessary, but if they could be coded with their own internal classification that would be a major improvement.

I dont see the need to create a palette with various bowings (as there are only two standard symbols). I have a bowing palette, where I also have slurs as well as various extended techniques, but, as those aren't the norm, they shouldn't be necessary for a new palette.

In reply to by chasejordan

Well, bowing marks are made of the same 'substance' as other articulations (a font glyph) and obey practically all the layout rules of other articulations. They also apply to the same base element (a chord, even possibly made by a single note), as it is of course not possible to apply different bowings to the different notes of a bichord or trichord (spelling?). The current assimilation of bowing marks in the Articulation class allows to manage pretty much anything about them with the same code as for the other items of the group.

So, it is not evident to me why a different internal classification for them would improve the functionality of the programme. Am I overlooking something? Can you elaborate on this?

thanks,

M.

In reply to by Miwarre

I've noticed that bowing a sometimes are shown below per say and accent. Bowings should always appear above. Maybe there's another way to make sure this happens, but it places them in order they are added. This should help them be in the correct position.

In reply to by chasejordan

Good point. As there are other 'articulations' requiring a specific order, I assume code to ensure a proper order of bowing marks can also be added.

In case this will not prove enough, a deeper separation is always possible, but I would like to let the implementor to decide.

In any case, I have filed an issue for this in the issue tracker: #87966: Bowings should always appear above other 'articulations'.

I think it would be better to keep them together internally but provide a straightforward way of changing the order of a "stack" of articulations, ornaments etc. (e.g. right-click on the marking and use the arrow keys to move up or down with the others changing position as needed). The user can create as many or as few palettes as they desire.

In reply to by underquark

A little more of elaboration.

The problem is that, in the great majority of cases, articulations refer to chords while ornaments refer to single notes.

Currently implemented ornaments are usually marked at chord level, with the implicit assumption that only one note of the chord -- usually the top one -- while be ornamented. So, it is in theory possible to keep them as they are now and improve the default visual (and audio!) rendering when necessary.

But other ornaments exist, primarily in lute literature and in Baroque music for instruments able to produce chords like keyboard or viols, which are marked at note level (right before or after it) and explicitly refer to a single note, even separately to several notes of the same chord. This kind of ornaments would be very complex (maybe almost impossible) to implement if they are not internally attached to the note they refer to.

A discussion with lasconic on IRC suggested a way worth exploring: keeping currently implemented items as they are and marking new ornaments of the above kind in some way allowing them to be correctly drawn with as little code fussing as possible. This is the way I am working on now and I hope to have some result to show soonish.

Specifically about your suggestion, a way for modifiying the stacking order could be useful for rare exceptions or niche use cases, but my feeling is that, in the first place, the programme should provide the correct (or most common) stacking order by default.

Thanks! M.

In reply to by Miwarre

As you've probably seen by now, there are already a number of special cases where we do try to fix the stacking order and/or relative positions of specific combinations of articulations. Adding more such special cases is of course possible. But I woudn't mind seeing this whole section of code revisited at some point to see if there isn't a more elegant way of dealing with this. Something like, maybe giving each articulation a "Z-order" and sorting articulations by this as they are entered, or at least as we lay them out, so we at least don't have to special case the ordering with switch statements etc.

If this could be coded someway, that would be my preference, thats less time making the score look tidy and more time writing for me. I have no computer coding knowledge, so how to do this, I don't know what would be best.

Do you still have an unanswered question? Please log in first to post your question.