Baroque French ornaments. Request For comments
Baroque French Ornaments
This is going to be long and tedious: I apologise, but I hope at least someone will stand it...
The current (MuseScore 3.3RC) situation about ornaments has some shortcomings. The bulk of the implemented ornaments are the "standard" XIX c. ornaments with some Baroque additions mainly from German keyboard literature. One of the major areas missing are the Baroque French ornaments which, once implemented (even partially) would cover more or less all the other Baroque ornament notations (primarily Italian).
Another is the ornament notation for lute (and sim.) tablatures, which is a topic in itself and I will leave for the moment to other more competent than myself (possibly in a different thread to keep this one focused).
I understand these are rather specialised interests, but not more specialised than other things currently implemented in MS like bagpipe embellishments or quarter-tone accidentals.
1) Selection of Symbol Repertoire
The French musical culture seemed particularly fond of ornaments and many composers devised their own ornament notations, which in some cases has been adopted by other or are individually important for the relevance of the author, while other are marginal. So, it is probably almost impossible to collect "all" the Baroque French ornaments, as we can expect some less known uses to escape the radars.
Possibly however, a reasonably useful selection can be made, for instance starting from the most familiar and well known to today "historically informed practice" (HIP) performers.
An initial starting point could be to look at the systems by Couperin and Rameau for the keyboard, Marais for the viole and Hotteterre for the winds. As far as I know, violins and relatives had no specific ornament notations and used "generic" ornaments included in the preceding list.
1.1) Selection Criteria
A very important point in this matter is separating a) the glyph shape from b) the semantic value and c) the positioning policy. Some cases:
A) Glyph shape may change, but the intended meaning AND how the glyph is placed do not change: I propose this to be considered ONE ornament, one shape is chosen as "default" and, perhaps, other shapes are considered stylistic variants. For instance, Marais' bat(t)ement is in some engravings an x-shaped cross and in others a somewhat slanted cross, while keeping exactly the same meaning.
B) On the other hand, the same glyph can have different semantic values in different contexts: I believe these should be considered different ornaments. An example could be Hotteterre's battement and Rameau son coupé (which is actually an articulation, similar to modern staccato).
C) The same should apply for very different placement strategies: Marais' battement is placed at the left side of the notehead, while Hotteterre's is placed above/below the stave; while their meaning is rather similar, they should be considered two different ornaments.
D) This is also true for ornaments which have the same (or very similar) shape as a modern symbol; for instance, the "plus" symbol used today as an articulation, but ubiquitous in the Baroque period as a cadence / battement (something oscillating between a prall and the initial part of a trill), or Hotteterre's port de voix, quite similar (but shorter) to violin's up bow symbol and so on.
They all shall be added with their specific ornament meaning. If convenient, they can share the same font glyph as the existing modern symbol, but they are different symbols.
2) Anchors
Currently ornaments follow articulations in being anchored to chords. This is an unfortunate choice, as ornaments belong to notes and chords may have multiple ornaments attached to specific, different notes. This is not frequent, but does occur.
J.-P. Rameau, Pièces de clavecin en concert (1741): Deuxiéme Concert — Premier menuet.
J. Morel, Pièces de violle (1709): Suite première — Sarabande “L'Agreable”.
3) Glyphs vs. images
The current way of implementing symbols is via glyphs in a font. However, neither SMuFL or Bravura include a significant support for French ornaments; there have been talks about this years ago, but eventually nothing came out of it. It seems there is no interest.
So, to follow the usual way, Emmentaler has to be extended with more, extra-SMuFL, glyphs and this may or may not suit current policies.
Another possibility could be setting up a way for defining a symbol out of an image (or a suitable font glyph, similar to FSymbol
s) and some meta-data (name, anchor, placing strategy, etc...). This would have some added bonuses:
*) as any implementation is likely to be incomplete, it would be possible to allow the user to define his own symbols out of his own images with some kind of automatic placement (images may already be attached to noteheads, but default to (0, 0) placement and have to be positioned one by one; just to give an idea of the task involved, a single _Suite à 2 dessus_ by Hotteterre may contain more than 300 unsupported ornaments requiring manual positioning);
*) they could be internally classified not as ornaments (actually, belonging to the Articulation
class), but as (an extension of?) BSymbol
(FSymbol
?), freeing them from the current limitations of the Articulation
class and, for instance, allowing to properly attach them to notes.
4) Placing strategies
As far as I can tell, there are at least 5 placing strategies for French ornaments:
a) Unconditionally above the stave; example: Hotteterre's Port de voix (J. Hotteterre, Pièces pour la Flute Traversière (1715): Première suitte — Prélude).
b) Above/below the stave according to the notehead side, always OUTSIDE the stave; examples: the Cadence or Hottererre's Battement (J. Hotteterre, ibidem).
c) Above/below the chord on the notehead side, also INSIDE the stave; this is quite rare for ornaments, but applies to some articulation, like the staccato dot or dash.
d) At the left of the notehead; examples: Marais' battement and plainte, Rameau's port de voix and coulez (sic) (M. Marais, Piéces à une et à deux violes (1686): Prélude p. 10).
e) At the right of the notehead; examples: as far as I know, this only applies to Marais' tremblement and Rameau's pincé, which have the same shape and a very similar meaning; in their respective context, they are quite common though. Note that, if the note is dotted, the dot is displaced and the ornament inserted between the notehead and the dot. Another complexity of this (pair of) ornament is that, in keyboard music (Rameau) is always vertically aligned with the notehead, while in viole literature (Marais) tends to always cross the stave line, being aligned with a notehead on a line, but moved somewhat up or down beside a notehead on a space.
(M. Marais, Piéces à une et à deux violes (1686): Prélude p. 8)
(J.-P. Rameau, Pièces de clavecin en concert (1741): Premier Concert — La Livri, keyboard-only version)
As far as I know, no ornament goes unconditionally below the stave, but it may make sense to add such a possibility, just in case.
4.1) Position distances
Distances require a more sophisticated system than currently implemented. At least 6 different distances need to be specified (all values are purely indicative and come from my practice/experience):
a) min. distance between the ornament above the notehead in the first stave; empirically, I arrived at a 0.25 / 0.5 sp range;
b) min. distance between the ornament above the first stave; again, empirically, I use values in the 1.75 / 2.5 sp range, depending on the global score density;
c) min. distance between the ornament above the notehead in non-first stave; this can be at the minimum of the corresponding range for the first stave, as subsequent staves usually have less air above;
d) min. distance between the ornament above a non-first stave; my practice is in the 1.5 / 2.0 sp range;
e) distance between the ornament and a notehead at its right; comparable to the distance between accidental and notehead;
f) distance between the notehead and the ornament at its right; same as previous.
In my experience, ornaments below the staves may use the above distance for non-first staves. For some optical reason, symbols moving away from the stave "get lost" at a smaller distance below than above the stave.
5) List of proposed ornaments
A) Couperin (ref.: Explication des Agrémens at the end of Pièces de clavecin, Premier Livre)
Assuming:
- the pincé can be rendered with the modern mordent sign,
- the tremblement with the prall, prall-prall or with the a symbol made out of the same image needed for Marais' flattement,
- the arpègement en montant/en descendant with the modern arpeggio signs with arrows,
- the tierces coulées (en montant et en descendant) with some ready-made line,
- the doublés with the (reverse) turn,
- the aspiration with staccatissimo sign,
as all of them have the same or very similar shape and a very similar meaning, the only required sign seems to be the suspension.
B) Hotteterre (ref.: Figure des agréments at the beginning of Premier livre de pieces pour la Flûte-traversiere... avec la Basse, 1715)
Practically all Hotteterre's ornaments are missing. Some notes:
-
As said above, the cadence is missing as an ornament; it may share the same font glyph as the "plusstop" symbol, but a new different symbol is required because of the different semantics and position policy (outside the stave on notehead side instead of above stave).
-
The double cadence coupée shares the 'plus' of the cadence; as the other part only occurs here, to me it make little sense to split the symbol into two parts: having a single, ready-made, symbol makes for a much simpler usage.
-
The demie cadence appuiée and the double cadence may be left undefined, for the user to make each time combining existing parts or prepared as ready-made symbols. I favor the second option, but practical reasons may suggest the first. To be decided at implementation time.
C) Marais (ref.: Avertissement at the begining of Pieçes a une et a deux violes, 1686)
Marais' ornaments are few but tricky:
-
as said above, the tremblement tends to be across a stave line, aligned with a notehead on a line but shifted up (occasionally down) after a notehead in a space. Details vary among engravers, even within the work of the same composer. I find particularly clear the solution used prevailingly (but not exclusively!) by Maris himself in his Premier Livre: tremblements on noteheads in a space are shifted up across the line above; used consistently, with chords with several notes or when several notes in a chord are given an ornament, this also ensures a precise indication about which ornament is for which note. However, even in the Premier livre, sometime the tremblement_in a space is shifted down and sometime it is left across the space. Engraving of works of other composers employing Marais' system (Boismortier's or Morel's _Pieces de viole) are even more inconsistent.
-
Note that, with dotted notes, the tremblement, usually (!) displaces the dot and is inserted between notehead and dot.
-
The battement is normally placed at the left of the notehead, but may be placed above if the notehead is preceded by an accidental.
-
The pincé, which is always above the stave, 'looks better' if less distant from it than other ornaments (don't ask me why: it is something I have to do).
-
The coulé de doigt probably may be merged with Hotteterre's port de voix (what other viol players out there have to say?).
D) Rameau (ref.: Noms et figures des agremens at the beginning of Piéces de clavessin, 1724)
-
The pincé has the same shape as Marais' _tremblement but, as it has a rather different meaning and a simpler placement policy (it is at the right side of the notehead but always vertically aligned with it), it is best treated as a different ornament.
-
The suspension has the same shape and meaning of Couperin's suspension and can be considered the same ornament; it is included here to show its wide application. Note that it has nothing to do with a fermata: it marks a note which begins later than it is notated.
-
Arpegements can be implemented as some kind of line and can already be created; the open point is whether creating them as new symbols for speed of use or expect the users will ‘forge’ a specific kind of line each time (and/or maybe storing it in a palette).
-
For the other symbols, modern glyphs might not be exact replicas of Rameau's shapes, but are similar enough to be reused.
6) Questions
6.1) To other fellow developers: which seems to you the best way to implement these ornaments? Extending Emmentaler? Using images? Making ready-made Symbol
s out of images / existing glyphs?
6.2) For line-shaped ornaments, it is preferable to use lines or to prepare images / glyphs, as the line length and slope of each ornament is constant in most cases?
6.3) To HIP players: are there ornaments you propose to add, or could be removed? Keeping in mind that completeness is not a real goal and for the rare ornament that some obscure composer used in a few occasions we may assume the patient user will create a special image to be placed manually.
Thanks for reading so far and for any comment you may have!!
Comments
This is a lot to ask on top of your "lot to ask", but nailing this into C++ code seems unwise. No one should use these ornaments unless they "truly understand them" in historical context, i.e., are somewhat HIP to them (sorry) themselves. I suggest consideration of a way of making this extensible, to be able to define these ornaments as "macros" equivalent to written-out note-sequences (diatonically "floating") that the user can supply in a hidden staff/parallel score somewhere (including loadable by other scores). What you/we supply should be the "starting set". Ornaments should be a simplifying, "macro" tool (as they were in their historical time) for an invisible staff with all the little noticules written out (which is exactly what I do in many pieces I post here). Ornaments are note macros. The classic ornament tables are macro definitions. You should be able to feed them (including custom graphics for the notation) into MuseScore via an appropriate mechanism, and thus define them. Also take a look at the UI for my "triller" plugin (downloads/plugins/articulation and ornamentation/triller).
In reply to This is a lot to ask on top… by [DELETED] 1831606
Hello BSG and thanks for your reply.
A possible misunderstanding? I do NOT propose ANY REALISATION of these ornaments: the ones already "realised" are ugly enough... In fact, I immediately turn off ornament "playing" in any Baroque piece as the result has very little to do with any sensible realisation.
If you notice, I have completely avoided any mention of how they (should/would/could?) sound, only how they look and where they are placed in the sources.
My goal is to have them DRAWN in a score, not played. For this there is little to debate: one will use them while transcribing a historic score as he would find them used in the source (of course, one could use them also while, for instance, composing a piece of contemporary music, but then it would be his responsibility to come out with any sensible meaning or not).
Currently, it is possible to have them to show up in a score, but it is a long, tedious job, where consistency is hard to reach. One has to draw images for them outside of MuseScore, then attach the proper image to each note requiring an ornament and finally manually move each image into the proper position with respect to the note. I have transcribed one of the Hotteterre's Suite à 2 dessus and it took me days!
This is why I propose a way to make the process quicker, easier and ultimately also more consistent.
Under those respects, do you have suggestions and/or comments?
In reply to Hello BSG and thanks for… by Miwarre
Well, clearly one can realize with hidden staves (today) and equally clearly envision macroizing that process, but ok, fine, ... how unreal!
One should be able to load such images (individual ornament images) as score "supplements" and use and place one multiple times, and I see no reason not to harvest any symbol Bach, D'Anglebert, or anyone else felt compelled to document into a high-quality font drag-droppable into the ornaments palette (as well as getting included in the mscz bundle), and let that be the end of it. If the user doesn't know how to place them (why should he or she not if looking at a quality score), he or she shouldn't be working with that music. I guess I'm in favor of anything you might do in these regards – you are clearly expert in the area.
It looks like SMuFL contains at least some of ornaments you have mentioned, like the following ones (from this page, maybe some more can be found in other parts of that document):
These symbols are included to fonts coming with MuseScore (they can be found in Symbols section of Master Palette searching by their names) so it should probably be possible to use them directly. Some other ornament symbols seem to be missing though.
In reply to It looks like SMuFL contains… by dmitrio95
Thanks for your reply and for spending time in looking for the glyphs: it is appreciated.
In fact, I did look at that page, but for some reason not all dots connected...! So, some slot can be filled (as Hotteterre's port de voix) and other slots given a more appropriate place (like the cadence) or a more ‘HIP’ glyph (lke Couperin's pincé). Thanks!
Summary of open questions:
for glyphs which are still missing, shall we:
wherever the new (or existing) shapes comes from, how are they turned into score elements?
Articulation
class, as current ornaments are? This is not entirely satisfactory, asArticulation
s are attached toChord
s, while ornaments should be attached toNote
s (see above for examples of multiple ornaments per chord). Also, I do not thinkArticulation
s can currently be created from images rather than from font glyphs.ObnoxiousOrnament
? ;) )It is important to highlight that the placement of an ornament symbol is an integral part of it; sources follow rules (or at least tendencies) which is important to mirror in modern editions; and scores need to be clear to read and consistent.
Doing everything by hand is rather heavy (the Première Suitte à 2 dessus by Hotteterre, whose transcription started all this research, ended up containing 508 unsupported ornaments to place manually!) and open to imprecision. So, some sort of support would be very welcome by peoples dealing with this kind of music.
Suggestions about other ornaments to support.
Thanks for reading!
What text font are you using? It's a beautiful font. Thanks
In reply to What text font are you using… by lucanor81
Thanks. It is not (yet?) a font, it is still just a collections of SVG images I use to test the result.
In reply to What text font are you using… by lucanor81
The text face appears to be Garamond.
An easy (and already doable) way to do this would be a new font. Place your svgs wherever you want in the Unicode. For example, the
pincé
sign could be in the"P"
slot.You could also use substitutions in your font. For example, "pincé" could be substituted with your glyph.
About sharing it with other users, I don't knowe if the MuseScore team would be willing to publish a new extension (like the MDL), for it, containing the font (and some palette elements?).
In reply to An easy (and already doable)… by ecstrema
Thanks for the suggestion. However, the issue is not about having the signs shown in a score, this is easy and can be achieved in a number of ways (a custom font being one of them; a collections of separate SVG's another). All my above examples are score excerpts from MuseScore and show that it can be done.
The issue is having them properly placed! This is what takes a LOT of time and is difficult to do consistently. Anyone having tried to engrave a score from Marais or from Hotteterre knows the pain. So, the point is to have MuseScore to do the job (ITS job after all...).
Several glyphs already exist, but MuseScore has no notion of their usage; some exist and are "known" to MuseScore, like the "cross" articulation, but in a different way, which is correct for some other context, but "wrong" as ornament (as a cadence, the cross should be notehead-side, not unconditionally above the stave). Other do not even exist as glyphs and, of course, MuseScore has no notion of how to manage them.
This is the main point I am trying to solve.