When exporting from Sibelius, accidentals lose their editorial function

[karend27]

In the Sibelius file, the accidentals are marked as being on the staff, or above the staff (i.e., editorial or suggested accidentals).

In the export, these distinctions are lost. Can editorial (above the staff accidentals) please receive the attribute func="edit", i.e., as follows:

<accid xml:id="m-323" accid="s" func="edit" />

[karend27]

Hi Thomas - thanks for your comments on these issues. I wonder if you think you might have time some time soon to work on this issue of the accidentals (ficta), because this actually affects the pitch content of my encodings substantially. Martha Thomae has been working on the tuplet issue, and I had another student write a quick script to fix the syllable issue on the files post-processing, but the accidental issue is one that needs to be fixed in the SibMEI export, because once these distinctions between on the staff and above the staff accidentals are lost, there is no way to fix this with a script, and the only way to fix is to go into the files one by one and compare them to the printouts of the Sibelius files and then do a search for <accid in the exported MEI files and type in func="edit". I'd be really grateful if you might have a few minutes to look at this issue and see whether it is a relatively straightforward fix, or if it would be more complicated. All the best,
Karen

[th-we]

Could you provide a small sample Sibelius file (best saved as version 7 or 8)? I think you have to put it in a zip file and just drag it onto your reply to my message.

[RichardFreedman]

We have solved this problem. The MEI Massaging routines (Python) include a module that allows the editor to mark notes involving ficta as "red" in the Sibelius file. These are then corrected by the Massaging routine to read correctly. See https://github.com/DuChemin/MEIMassaging.

View demonstration of the system here: https://docs.google.com/presentation/d/1GepHyGz_ViiiTL72z7lr4H5IvNyMeTIeWhLUDTIvxe4/edit#slide=id.g3293d4610c_1_156

[karend27]

Thanks Richard. That is a possibility but at this point I'd love to get it solved within the SibMEI export if at all possible since going back in to Sibelius and marking the notes in red will take almost as long as going into the code and adding func="edit". Also, we already use red color notes to indicate red color ink in the original manuscripts with respect to duration changes.

[RichardFreedman]

I understand. But note that the use of red on these notes does not preclude the use of red for other purposes. The massaging routine for ficta only modifies notes that also have accidentals.

[karend27]

Thomas - I'm attaching a sample file in Sibelius 7.5 and a PDF. It has both on the staff and above the staff accidentals.
hugo.pdf
hugo.sib.zip

[karend27]

Rich - thanks for the link to your scripts - that's a really useful resource.

[th-we]

Thanks for the upload! The main problem is that there is no proper semantic built-in functionality for ficta accidentals in Sibelius. The plugin that comes with Sibelius (and that you are probably using) merely hides the visible accidental and creates text above the note. Unlike for figured bass, there is no dedicated text style for ficta accidentals.

So, some context analysis (or should I say guessing) would be involved in detecting ficta accidentals. There is some chance of false positives and false negatives. That's why I'd agree with Richard that "massaging" the data is the preferable option here. It puts you into control and makes sure you get what you want.

If coloring is required for massaging, you don't have to do that one-by-one. Sibelius' filter feature can help you with that. The following will select all Technique text with a b in it:

You can then color them all in one go. For sharp, you have to search for "#", and for natural for "§". You will still have to look through the file once to see if nothing was turned red unintentionally.

[RichardFreedman]

Thanks for this useful tip, Thomas! Richard

…

On Fri, Jun 22, 2018 at 11:05 AM, Thomas Weber ***@***.***> wrote: Thanks for the upload! The main problem is that there is no proper semantic built-in functionality for ficta accidentals in Sibelius. The plugin that comes with Sibelius (and that you are probably using) merely hides the visible accidental and creates text above the note. Unlike for figured bass, there is no dedicated text style for ficta accidentals. So, some context analysis (or should I say guessing) would be involved in detecting ficta accidentals. There is some chance of false positives and false negatives. That's why I'd agree with Richard that "massaging" the data is the preferable option here. It puts you into control and makes sure you get what you want. If coloring is required for massaging, you don't have to do that one-by-one. Sibelius' filter feature can help you with that. The following will select all Technique text with a b in it: [image: bildschirmfoto vom 2018-06-22 16-57-09] <https://user-images.githubusercontent.com/1147152/41783589-7d3ab766-763d-11e8-8295-ba6886c6ca7a.png> You can then color them all in one go. For sharp, you have to search for "#", and for natural for "§". You will still have to look through the file once to see if nothing was turned red unintentionally. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMeuHtZxR1Clv49-vJqrsRogrAiXv6pks5t_Qe-gaJpZM4T0Duh> .

-- Richard Freedman Professor of Music John C. Whitehead '43 Professor of Humanities Associate Provost for Curricular Development Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/users/rfreedma Schedule meeting time: https://goo.gl/3KN2hr

[ahankinson]

There is a built in function for attempting symbol to timestamp alignment. But it's far from perfect. On 22 Jun 2018, at 16:11, Richard Freedman <[email protected]<mailto:[email protected]>> wrote: Thanks for this useful tip, Thomas! Richard

…

On Fri, Jun 22, 2018 at 11:05 AM, Thomas Weber ***@***.******@***.***>> wrote: Thanks for the upload! The main problem is that there is no proper semantic built-in functionality for ficta accidentals in Sibelius. The plugin that comes with Sibelius (and that you are probably using) merely hides the visible accidental and creates text above the note. Unlike for figured bass, there is no dedicated text style for ficta accidentals. So, some context analysis (or should I say guessing) would be involved in detecting ficta accidentals. There is some chance of false positives and false negatives. That's why I'd agree with Richard that "massaging" the data is the preferable option here. It puts you into control and makes sure you get what you want. If coloring is required for massaging, you don't have to do that one-by-one. Sibelius' filter feature can help you with that. The following will select all Technique text with a b in it: [image: bildschirmfoto vom 2018-06-22 16-57-09] <https://user-images.githubusercontent.com/1147152/41783589-7d3ab766-763d-11e8-8295-ba6886c6ca7a.png> You can then color them all in one go. For sharp, you have to search for "#", and for natural for "§". You will still have to look through the file once to see if nothing was turned red unintentionally. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMeuHtZxR1Clv49-vJqrsRogrAiXv6pks5t_Qe-gaJpZM4T0Duh> .

-- Richard Freedman Professor of Music John C. Whitehead '43 Professor of Humanities Associate Provost for Curricular Development Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/users/rfreedma Schedule meeting time: https://goo.gl/3KN2hr — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub<#88 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AAJ9b2M3gbQWqW7YLITudDdv7Bp9dcdKks5t_Qj2gaJpZM4T0Duh>.

[karend27]

Thanks for looking into it for us Thomas. I agree that a post-processing step looks like the safest, though we have quite a few post-processing steps now. (Perhaps we'll do blue for editorial accidentals though, to avoid conflict with our use of red for coloration.) Also - I think the advanced filter won't exactly work - because that will apply color to the above-staff accidental, but we would need to apply color to the actual note, right?

One question though - how is it when I export the file into MusicXML all the ficta accidentals appear to export correctly? Here I'm attaching the MusicXML file of the same piece I sent.
hugo.xml.zip

[RichardFreedman]

You can adapt the massaging scripts for any color you like.

On Fri, Jun 22, 2018 at 6:33 PM karend27 ***@***.***> wrote: Thanks for looking into it. I agree that a post-processing step looks like the safest, though we have quite a few post-processing steps now. (Perhaps we'll do blue for editorial accidentals though, to avoid conflict with our use of red for coloration.) One question though - how is it when I export the file into MusicXML all the ficta accidentals appear to export correctly? Here I'm attaching the MusicXML file of the same piece I sent. hugo.xml.zip <https://github.com/music-encoding/sibmei/files/2129326/hugo.xml.zip> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMeuLzHv2CDGiK3-rV0oJeCBXQdRkY9ks5t_XCtgaJpZM4T0Duh> .

-- Richard Freedman Professor of Music John C. Whitehead '43 Professor of Humanities Associate Provost for Curricular Development Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/users/rfreedma Schedule meeting time: https://goo.gl/3KN2hr

[th-we]

@karend27 The MusicXML-export just exports text, no proper ficta accidental. If I re-import the XML, the normal accidental is also no longer hidden.

[karend27]

OK - thanks Thomas!

[th-we]

Hope nobody minds me closing this issue then.

[th-we]

I had an idea on this issue that I'd like to discuss:

The ficta plugin that comes with Sibelius just uses the unspecific Technique style text that is used for other purposes as well and therefore makes it flaky to reliably identify ficta accidentals. What if we provided our own ficta creation plugin that adds the ficta accidentals using its own specific ficta style – let's call it "MEI Ficta"? The plugin would have to come with a template Sibelius file that has this style. The plugin would import it from there if the style is not already present in the edited file. I've used this style importing approach in other contexts and it works.

The conversion would work similarly to figured bass with the main difference that the figured bass text style is built in, the ficta style would be imported.

@ahankinson, what do you think? This of course raises the general question if introducing MEI specific text styles or symbols is sensible or opens a can of worms.

[ahankinson]

I think if it's a matter of more reliably detecting things, like ficta, I would have no problem with this technique in principle. We could attempt to detect the presence of the specific markup first, and then fall back to less reliable methods later. I wouldn't want to make it dependent on this plugin, but using another plugin to improve the MEI output would be useful.

What about a plugin called "MEI Pre-check" or "Editorial Normalization" that can give users the option of detecting any issues and, if desired, fix them to improve the output. Certainly ficta is one example, but also any objects connected to the master track (the exporter currently warns if this happens, and then just assumes it's connected to the first staff). Also detecting the use of symbols v. note attributes, etc.

[th-we]

We could attempt to detect the presence of the specific markup first, and then fall back to less reliable methods later.

What would be the logical flow? Are you suggesting:

1. If a text is of style "MEI ficta", convert it to func="edit" accidentals
2. If a text is of style "Expression", check if it is plausible to be a ficta accidental, i.e.:
   1. Uses Opus Text Std (not sure if other fonts might be used as well, e.g. legacy Opus Text)
   2. Only text it contains is a single accidental
   3. Has a plausible position (plausible Dx/Dy values)

Honestly, 2. is what I'd like to avoid. I'd prefer using 1. exclusively because it keeps the conversion simpler, more efficient (Expression is possibly the most frequent text style) and less prone to errors. Like this, we also wouldn't have to do this analysis for all repertoires as this is mostly specific to mensural music.

A separate plugin could

• provide the same functionality as the existing ficta plugin, however with a more specific style
• help users to transition to the more specific style if they already have differently styled ficta accidentals.

I wouldn't want to make it dependent on this plugin, but using another plugin to improve the MEI output would be useful.

Right now, users are dependent on the "other" ficta plugin. Their workflow would not change except for swapping out the plugin.

What about a plugin called "MEI Pre-check" or "Editorial Normalization" that can give users the option of detecting any issues and, if desired, fix them to improve the output. Certainly ficta is one example, but also any objects connected to the master track (the exporter currently warns if this happens, and then just assumes it's connected to the first staff). Also detecting the use of symbols v. note attributes, etc.

That might be really useful as well. However, I think a pre-check is not the solution for the ficta problem.

[RichardFreedman]

Friends, I think I've mentioned this before, and but we have a solution for this involving the post-processing of MEI (we call it 'massaging') with various Python scripts. In brief: for any note to which you add ficta in Sibelius, also add a color to that note (you can have any color, or make it a specific one). Then the Python script looks for notes that have editorial accidentals and color, and transforms them according to your preferred MEI encoding. There are various modules to the Massaging routines <https://github.com/DuChemin/MEIMassaging>, and you can turn them on or off as needed. The ficta module is here <https://github.com/DuChemin/MEIMassaging/blob/master/massage/transform/ficta.py> . I realize that this might or might not be the solution that works for everyone. But we have found it a very reliable way to deal with the problem that is simple for both editors and technical collaborators. Richard

…

On Mon, Dec 10, 2018 at 10:08 AM Thomas Weber ***@***.***> wrote: We could attempt to detect the presence of the specific markup first, and then fall back to less reliable methods later. What would be the logical flow? Are you suggesting: 1. If a text is of style "MEI ficta", convert it to func="edit" accidentals 2. If a text is of style "Expression", check if it is plausible to be a ficta accidental, i.e.: 1. Uses Opus Text Std (not sure if other fonts might be used as well, e.g. legacy Opus Text) 2. Only text it contains is a single accidental 3. Has a plausible position (plausible Dx/Dy values) Honestly, 2. is what I'd like to avoid. I'd prefer using 1. exclusively because it keeps the conversion simpler, more efficient (Expression is possibly the most frequent text style) and less prone to errors. Like this, we also wouldn't have to do this analysis for all repertoires as this is mostly specific to mensural music. A separate plugin could - provide the same functionality as the existing plugin, however with a more specific style - help users to transition to the more specific style if they already have differently styled ficta accidentals. I wouldn't want to make it *dependent* on this plugin, but using another plugin to improve the MEI output would be useful. Right now, users are dependent on the "other" ficta plugin. Their workflow would not change except for swapping out the plugin. What about a plugin called "MEI Pre-check" or "Editorial Normalization" that can give users the option of detecting any issues and, if desired, fix them to improve the output. Certainly ficta is one example, but also any objects connected to the master track (the exporter currently warns if this happens, and then just assumes it's connected to the first staff). Also detecting the use of symbols v. note attributes, etc. That might be really useful as well. However, I think a pre-check is not the solution for the ficta problem. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMeuNgkU0RZVpZk-IZpRHdmPTHWKdQiks5u3njtgaJpZM4T0Duh> .

-- Richard Freedman Professor of Music John C. Whitehead '43 Professor of Humanities Associate Provost for Curricular Development Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/users/rfreedma Schedule meeting time: https://goo.gl/3KN2hr

[th-we]

@RichardFreedman I agree that this is not the most pressing issue as there are ways to achieve the desired result. At the moment I see this as just an idea how to make the export better and work well in more situations. Say to make the ficta accidentals both suitable for traditional print and MEI export from Sibelius; or to make this accessible to people who don't know or care about how to use Github, the command line and Python scripts. (I hear there are musicologists falling into that category. If we can make the MEI world a little more inviting to them...)

[craigsapp]

I think I've mentioned this before, and but we have a solution for this
involving the post-processing of MEI (we call it 'massaging') with various
Python scripts.

or to make this accessible to people who don't know or care about how to use Github, the command line and Python scripts.

Related to this, you should be aware of how editorial accidentals are handled in the Josquin Research Project and the Tasso in Music Project. Both projects work with digital scores of Renaissance-era music with lots of editorial accidentals to deal with things such as musica ficta, and both originate their data from off-the-shelf music notation editors (Finale for JRP, and Sibelius for TiMP), where the scores are exported as MusicXML files.

When encoding the scores in Finale/Sibelius, editorial accidentals are encoded as accidentals within parentheses: http://wiki.ccarh.org/wiki/Josquin_Project_encoding_standards#Editorial_accidentals
The exported MusicXML data preserves the parentheses information for the accidentals (unlike editorial accidentals displayed above notes). These accidentals are then "massaged" in a process similar Richard's, but in a much simpler process illustrated below that can be handled by musicologists (provided they know how to use a mouse).

Here is an example TiMP score converted from MusicXML into Humdrum using VHV. Going to this web address: https://verovio.humdrum.org/?filter=tassoize will activate the "tassoize" filter when MusicXML files are dragged onto the webpage. Here is the result of dragging a MusicXML file onto the linked webpage:

The editorial accidentals are now correctly extracted from the MusicXML parentetical accidentals. You can try doing the same with the original MusicXML data which is attached to this message with this link:

Trm0047d-Non_e_questa_la_mano--Cortellini_1583.txt

If you want to convert to MEI, then type alt-c to finish the conversion (pre-massaged data is shown above), then alt-m to view the MEI conversion, and optionally alt-s to save the MEI to your harddisk; or otherwise, copy/paste into a Github repository, which I have successfully trained some musicologists to do as well.

---

There is a bug in the MusicXML export from Sibelius, where only the first parenthetical accidental of any pitch is exported to the MusicXML file. I wonder if SibMEI is prone to the same problem? The "tassoize" filter also fixes this problem, and it actually goes further and will automatically add editorial accidentals to all non-printed accidentals, according to the TiMP editorial policies (the TiMP editors will often forget them, and the tassoize filter catches these cases as well as the buggy output from Sibelius).

[ahankinson]

Thanks, Craig. My main worry is that imposing an interpretation of literal symbols in the MEI exporter makes assumptions that the user does not necessarily want. Interpreting parenthetical accidentals as ficta, for example, may negate the use of the same parenthetical symbols as a cautionary interpretation. If we're trying to keep the plugin as generic as possible, then I wouldn't want to impose a certain interpretation of a given set of symbols.

If, however, we can mark-up the ficta in a non-ambiguous way through the use of another plugin, then I would have no problem with building in detection of those. If, for example, we can attach a custom property to ficta notes that contain "mei-marked-as-ficta" or something along those lines, then that's fine. I think we could even extend that to other bits of 'semantic' markup; "mei-note-has-coloration" or "mei-note-is-brevis" (for, eg., mensural notations))

I also think that func=edit is more generic than just ficta; it can also include other editorial interventions, such as a supplied missing accidental. @th-we is that the only way you know of to mark a ficta?

The accidental handling code of the MEI exporter is probably the most complex bit; Until very recently (v7.1.3) Sibelius didn't actually give you the ability to determine whether a note had a visible accidental or not! So there are a lot of convoluted ways of figuring it out. Most of the code in this function, for example, tries to replicate the behaviour of the 'IsAccidentalVisible' built-in function:

https://github.com/music-encoding/sibmei/blob/master/src/ExportConverters.mss#L415-L554

So the answer to your question is "It might be prone to the same problem some of the time, but I'm pretty certain it's more accurate than the MusicXML export most of the time, and certainly on older versions of Sibelius."

[craigsapp]

My main worry is that imposing an interpretation of literal symbols in the MEI exporter makes assumptions that the user does not necessarily want. Interpreting parenthetical accidentals as ficta, for example, may negate the use of the same parenthetical symbols as a cautionary interpretation. If we're trying to keep the plugin as generic as possible, then I wouldn't want to impose a certain interpretation of a given set of symbols.

Yes, that is good. The general problem is that MusicXML is lacking editorial accidental export, so massaging is necessary—good luck if you can get direct access to such information via ManuScript. For my purposes, I have a "tassoize" and "jrpize" conversion post-processors that takes a generic MusicXML file conversion and then adjusts the accidentals and other non-MusicXML features according to the encoding conventions and editorial policies of both projects (similar to Karen and Richard mapping articulations to other MEI features).

Of note, I treat such cautionary accidentals as a subset of editorial accidentals in Humdrum, with the styling of editorial accidentals being controllable:

So if someone wanted the accidental placed in front of the note with parentheses again, they would add the text "parentheses" on line 17 in the above example.

**kern
*clefG2
=1
4f#i
4e
4f
=
4f#j
4e
4f
=
4f#Z
4e
4f
==
*-
!!!RDF**kern: i = editorial accidental
!!!RDF**kern: j = editorial accidental, bracket
!!!RDF**kern: Z = editorial accidental, parentheses

MEI conversion, where I am currently just treating the bracket and parentheses as graphical rather than functional:

<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="http://music-encoding.org/schema/4.0.0/mei-all.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mei xmlns="http://www.music-encoding.org/ns/mei" meiversion="4.0.0">
    <meiHead>
        <fileDesc>
            <titleStmt>
                <title />
            </titleStmt>
            <pubStmt />
        </fileDesc>
        <encodingDesc>
            <appInfo>
                <application isodate="2018-12-10T18:08:51" version="2.0.0-dev-b955670">
                    <name>Verovio</name>
                    <p>Transcoded from Humdrum</p>
                </application>
            </appInfo>
        </encodingDesc>
        <workDesc>
            <work>
                <titleStmt>
                    <title />
                </titleStmt>
            </work>
        </workDesc>
    </meiHead>
    <music>
        <body>
            <mdiv xml:id="mdiv-0000001764001604">
                <score xml:id="score-0000001031635790">
                    <scoreDef xml:id="scoredef-0000000038991904">
                        <staffGrp xml:id="staffgrp-0000001040242486">
                            <staffDef xml:id="staffdef-0000000475090987" clef.shape="G" clef.line="2" n="1" lines="5">
                                <label xml:id="label-0000000019728503" />
                            </staffDef>
                        </staffGrp>
                    </scoreDef>
                    <section xml:id="section-L1F1">
                        <measure xml:id="measure-L3" n="1">
                            <staff xml:id="staff-L3F1N1" n="1">
                                <layer xml:id="layer-L3F1N1" n="1">
                                    <note xml:id="note-L4F1" dur="4" oct="4" pname="f">
                                        <accid xml:id="accid-L4F1" accid="s" func="edit" />
                                    </note>
                                    <note xml:id="note-L5F1" dur="4" oct="4" pname="e" accid.ges="n" />
                                    <note xml:id="note-L6F1" dur="4" oct="4" pname="f" accid="n" />
                                </layer>
                            </staff>
                        </measure>
                        <measure xml:id="measure-L7">
                            <staff xml:id="staff-L7F1N1" n="1">
                                <layer xml:id="layer-L7F1N1" n="1">
                                    <note xml:id="note-L8F1" dur="4" oct="4" pname="f">
                                        <accid xml:id="accid-L8F1" accid="s" enclose="brack" />
                                    </note>
                                    <note xml:id="note-L9F1" dur="4" oct="4" pname="e" accid.ges="n" />
                                    <note xml:id="note-L10F1" dur="4" oct="4" pname="f" accid="n" />
                                </layer>
                            </staff>
                        </measure>
                        <measure xml:id="measure-L11" right="end">
                            <staff xml:id="staff-L11F1N1" n="1">
                                <layer xml:id="layer-L11F1N1" n="1">
                                    <note xml:id="note-L12F1" dur="4" oct="4" pname="f">
                                        <accid xml:id="accid-L12F1" accid="s" enclose="paren" />
                                    </note>
                                    <note xml:id="note-L13F1" dur="4" oct="4" pname="e" accid.ges="n" />
                                    <note xml:id="note-L14F1" dur="4" oct="4" pname="f" accid="n" />
                                </layer>
                            </staff>
                        </measure>
                    </section>
                </score>
            </mdiv>
        </body>
    </music>
</mei>

[th-we]

I also think that func=edit is more generic than just ficta; it can also include other editorial interventions, such as a supplied missing accidental. @th-we is that the only way you know of to mark a ficta?

@ahankinson You mean in MEI (func="edit" is what @karend27 asked for initially) – or an alternative way of marking ficta in Sibelius?

Assuming the latter: As Sibelius has no built-in ficta functionality, I think a dedicated text style is the best and most semantic way. We could of course add an options dialog or a preference file to Sibmei so the user can decide how to export parenthesized accidentals. However, from my perspective it would be nicer to implement and clearer for the user if there was one specific way instead of multiple options. If the user doesn't want the textual accidental to show when printing from Sibelius, it can be hidden.

[craigsapp]

Marking musica ficta notes explicitly, but separately from editorial accidentals, is not necessary. Historically speaking, musica ficta is a note outside of the gamut, i.e. other than A–G or B-flat (or a very high or low note of those pitch classes). The modern usage of the term musica ficta is equivalent to "added accidental", which basically means an editorial accidental. Since these are two subtly different definitions, labeling them as such can be problematic (compare with the two mordents which are called upper and lower in MEI as compared to regular and inverted which can have their meanings switched depending on the locale/time period).

https://en.wikipedia.org/wiki/Musica_ficta

Here are the main reasons for adding (supplying) an accidental in pre-chromatic notation. These would be of analytic interest, but would otherwise be a waste of time for manual categorization as there could be ambiguities or superpositions for the reasons:

(1) The note needs to be altered to avoid a melodic tritone, either with an adjacent note, or a structurally relevant note sometime in the recent past in the melody, such as singing stepwise between F and B, or B-flat and E.
(2) The note needs to be altered to avoid a harmonic tritone (particularly due to rule 3).
(3) The note needs to be altered because of a recent application of rule 1 or 2.
(4) The note needs to be altered to create a leading-tone for a cadence.
(5) There was an accidental on a recent previous note that should be repeated (note no barlines in the music).
(6) There is a probably incorrect key signature for the part (in this case it is perhaps a correction more than a musica ficta alteration, but it could be both at the same time).
(7) The note needs to be altered because it is a quotation of a famous melody that has an alteration for that note in the original source (I have seen one case of this).

[th-we]

@craigsapp But has this any technical implications? Anything to criticize about the text style approach? Do you imply that if we pursue that approach, we should use more careful naming or widen the perspective?

[craigsapp]

The main thing is that labeling an accidental as a musica ficta is not a good idea, since the term is overloaded in its meaning. In modern conventions, this means an unnotated implied accidental: it is an editorial intervention by an editor. For more recent music, all accidentals are expected to be explicit in the music (explicit accidentals can be hidden due to key-signature conventions), so when an editor adds an accidental, it usually has one of two purposes: (1) to correct a perceived error in the notation, and/or (2) to add a cautionary accidental to warn performs what the correct performance accidental should be.

The accidentals related to musica ficta fall in a broad third category of performance realization. MEI already handles this case reasonably well: There is note@accid which encodes the visual accidental, and [email protected] which encodes the performance accidental. Therefore, [email protected] is nearly identical to indicating that the note is a musica-ficta note (in the modern sense). There can be confusion between using @accid.ges for modern cases where the the accidental is explicit but implied by the key signature, and the musica ficta case where the accidental is implicit and cannot be inferred from the key signature.

Early music also uses the implicit accidental from key signatures and previous explicit accidentals, and these cases can be difficult to separate from the musica-ficta alterations (i.e., cases 2 and 3 cannot be fully isolated from each other). There are no barlines in early music, so a modern editor must decide how far a previous explicit accidental on a note applies further on in the music. This will depend on the time period and locale. The modern rule is that a barline clears invisible accidentals, with complications related to notes tied over barlines. The late Renaissance rule is that the continuation of an explicit accidental must be followed by the same diatonic pitch class to apply (but sometimes one different pitch can intervene). The rule for earlier music is more variable and could extend to the line-break in the music.

[th-we]

Oh, many thanks. Your elaboration made me discover a simple bug that might have been part of the problem: Hidden accidentals were output as @accid instead of @accid.ges. I just fixed that.

@RichardFreedman and @karend27, you both seem to have adopted the same approach of coloring notes for massaging. With a more proper output of @accid and @accid.ges, could massaging work without coloring or are there still cases that need a marker of some sort?

[RichardFreedman]

Dear Thomas, In our work on the CRIM and Lost Voices Project, we use the 'color notehead + massaging' as the solution for encoding musica ficta. See pages 12 and 17 of this guide for editors <https://docs.google.com/presentation/d/1GepHyGz_ViiiTL72z7lr4H5IvNyMeTIeWhLUDTIvxe4/edit?usp=sharing> . In The Lost Voices Project, we also use colored noteheads in conjunction with a different set of 'massaging' routines--in this case to create <app> or other relevant encodings for variant readings <https://github.com/DuChemin/MEIMassaging/blob/master/massage/transform/alt.py> among different sources. But of course musica ficta (since it is _editorial_ and not in the sources per se) is not part of this process. The musica ficta module <https://github.com/DuChemin/MEIMassaging/blob/master/massage/transform/ficta.py> in MEI massaging anticipates this, in that it only operates on colored notes that have accidentals. I would appreciate having the chance to test the proposed revisions to the Sib>MEI plug in to make sure that we can anticipate the results. It could easily be the case that this saves us some steps (eliminating the need for editors to color noteheads and for a subsequent massaging step). But I would like to be sure. The MEI community continues to impress me with the generous spirit of collaboration! Richard

…

On Fri, Dec 14, 2018 at 3:31 AM Thomas Weber ***@***.***> wrote: Oh, many thanks. Your elaboration made me discover a simple bug that might have been part of the problem: Hidden accidentals were output as @accid instead of @accid.ges. I just fixed that. @RichardFreedman <https://github.com/RichardFreedman> and @karend27 <https://github.com/karend27>, you both seem to have adopted the same approach of coloring notes for massaging. With a more proper output of @accid and @accid.ges, could massaging work without coloring or are there still cases that need a marker of some sort? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMeuHLGPDEHd0XR5RW8z-2saeDSg5VAks5u42HdgaJpZM4T0Duh> .

-- Richard Freedman Professor of Music John C. Whitehead '43 Professor of Humanities Associate Provost for Curricular Development Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/users/rfreedma Schedule meeting time: https://goo.gl/3KN2hr

[th-we]

@RichardFreedman Concerning the slides I sent you an e-mail earlier today to learn more about the workflow. I uploaded the current development state of Sibmei, if you want to give it a try.

[RichardFreedman]

@thomas: Sorry to clutter the GitHub conversation, but I did not receive your email! rfreedma at haverford dot edu

…

On Fri, Dec 14, 2018 at 9:21 AM Thomas Weber ***@***.***> wrote: @RichardFreedman <https://github.com/RichardFreedman> Concerning the slides I sent you an e-mail earlier today to learn more about the workflow. I uploaded the current development state of Sibmei <https://app.box.com/s/ckyp79f5ficx8updtgb3yz55gv1fp4t4>, if you want to give it a try. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#88 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AEMeuGmBDLN1RX-AiB5__Sw8EnzarPjZks5u47PwgaJpZM4T0Duh> .

-- Richard Freedman Professor of Music John C. Whitehead '43 Professor of Humanities Associate Provost for Curricular Development Haverford College Haverford, PA 19041 610-896-1007 610-896-4902 (fax) http://www.haverford.edu/users/rfreedma Schedule meeting time: https://goo.gl/3KN2hr

[craigsapp]

Related to comment #88 (comment), I have decided on 5 levels of accidental qualification in the Humdrum **mens (white mensural notation representation):

humdrum-tools/verovio-humdrum-viewer#190

The levels are:

(1) visual, but non-editorial accidental

Then four levels of editorial accidentals which can be converted into either @accid.ges or @accid+@edit when converting into MEI.

(2) the accidental is strongly implied (such as being in the key signature)
(3) the accidental is weakly implied (such as an unwritten cancellation of a written accidental)
(4) the accidental is a performance accidental which is not implied by the notation but by performance practice (i.e., a musica ficta accidental in the modern sense)
(5) a visual accidental is missing due to a scribal error

There are then controls on whether or not to display the accidental as an editorial accidental above the note, or to make it invisible (convert it to @accid.ges). The default is to only show level 5 accidentals as editorial, and levels 2-4 are converted to @accid.ges. When doing data entry, the level can be lowered to category 2, where all non-notated accidental are shown as editorial ones.