Giter Site home page Giter Site logo

sibmei's Introduction

The Music Encoding Initiative

DOI GitHub release (with filter) GitHub Deploy Schema and Guidelines

The Music Encoding Initiative (MEI) is an open-source effort to define a system for encoding musical documents in a machine-readable structure. MEI brings together specialists from various music research communities, including technologists, librarians, historians, and theorists in a common effort to define best practices for representing a broad range of musical documents and structures. The results of these discussions are formalized in the MEI Source and customizations, a core set of rules for recording physical and intellectual characteristics of music notation documents expressed in TEI’s ODD language (One Document Does-it-all, cf. amongst others: Viglianti, 2019). As such, the MEI Source contains both, the specifications that can be compiled to schema formats for validating XML files, and documentation in prose, the MEI Guidelines, which provide detailed explanations of the components of the MEI model and best practices suggestions.

The MEI Source is not a schema in itself; rather, it can be used to build customized schemas, such as mei-CMN, mei-Mensural, mei-all, etc. (also see Customizing MEI). This repository already includes several customizations. While these can form an ideal starting point for creating your own customizations, you should also understand customization and building processes.

In this document, you will learn how to contribute to the development of MEI by building the schema and guidelines (you should also consider consulting the tutorial on "Understanding ODD"). For the pre-built schemas of the latest release of MEI, please consult the "schemas" section of the music-encoding website.

Structure of this repository

This repository contains all the source code of the MEI Schema and Guidelines:

  • .github: Configuration files for GitHub Actions workflows.
  • customizations: TEI ODD files that allow you to build customized MEI schemata.
  • source: Contains the source code, as expressed in TEI ODD. This includes the source code for the MEI Guidelines and the MEI schema modules.
  • submodules: A container for Git Submodules: third-party developments that are needed, e.g., for building this repository's contents, but which are not part of our codebase.
  • tests: Unit tests for the MEI Schemata.
  • utils: Helper scripts e.g. for compiling schemata and guidelines from this repository.

Important

For the sake of the continuous integration (CI) workflow, the build artifacts of the schemata and guidelines are no longer included in this repository, but are generated on every commit to the develop branch and automatically pushed to their dedicated repositories. For more information please see the section Additional Resources below.

Nevertheless, it is possible to build any customization locally in your working copy of this repository.

Validating MEI files against an MEI Schema

One of the core strengths of the MEI Schema is that it allows an individual to validate an MEI file against an XML Schema to ensure the MEI file conforms to expected encodings and behaviors. To validate an MEI file you need an XML validation engine. XML Authoring tools, such as oXygen, might have built-in validation tools. There are also several command line utilities, including xmllint and jing.

For example, you might validate an MEI file from the sample-encodings project using the xmllint command line tool:

xmllint --noout --relaxng schemata/mei-CMN.rng "sample-encodings/MEI 3.0/Music/Complete\ examples/Bach_Ein_festeBurg.mei"

Or, the same command using jing.

jing schemata/mei-CMN.rng "sample-encodings/MEI 3.0/Music/Complete\ examples/Bach_Ein_festeBurg.mei"

Customizing MEI

The MEI model may be customized to express and validate different types of music documents. Customizations are configured with individual ODD files. This repository already includes several customizations:

  • mei-CMN: Validates MEI files that express common Western music notation.
  • mei-Mensural: Validates MEI files that express white Mensural notation (will raise validation errors if elements like "measure" exist in the MEI encoding).
  • mei-Neumes: Validates MEI files that express Neume notation (like Mensural, will raise validation errors if elements that are not part of neume notation exist in an encoding.)
  • mei-all: The full MEI Schema. This is the most permissive customization of MEI.
  • mei-all_anyStart: A customization of mei-all, allowing every MEI element as the root element.
  • mei-basic: The purpose of mei-Basic is to serve as common ground for data interchange, both between projects using different profiles of MEI, and other encoding schemes

Why Customizations?

For those who are used to having a single DTD or W3C Schema to validate music notation encodings, the customization process may seem to be a complex way of arriving at a schema to validate music notation. However, customizations are a vital part of the expressive power of MEI, and when used to their full extent, can assist organizations in ensuring the integrity and validity of their data.

When designing a music encoding system there are many contradictory and non-standardized practices associated with writing music notation. Different repertoires may have extremely different ways of expressing pitch or rhythm; for example, rhythm in Mensural notation is incompatible with the later systems developed in common Western notation.

Most attempts at addressing this complexity restrict a schema to only a certain subset of music notation and do not attempt to accurately represent the semantics of music notation that falls outside of its defined scope. So, for example, a system designed for common Western notation that depends on the existence of measures, duration, note shapes, or even staves, cannot semantically represent notations that do not have these features.

The MEI takes a different approach. With the customization system, schemas may be generated from an existing ‘library’ of well-defined musical behaviors, but each behavior may be mixed and matched according to the needs of the notation. In this sense, the MEI source functions more as a ‘library’ of music encoding tools by which many different types of notation can be expressed and not just a single monolithic schema.

Building MEI

The build process of MEI can produce several artifacts, as listed below. Depending on what artifacts you want to build, the build system has to meet additional requirements.

Artifacts Technologies Tools
Compiled ODD XInclude, XSLT 3.0 Saxon HE with Xerces
Schemata XInclude, XSLT 3.0 Saxon HE with Xerces
Guidelines HTML XInclude, XSLT 3.0, MEI to SVG Saxon HE with Xerces, Verovio Toolkit
Guidelines PDF XInclude, XSLT 3.0, MEI to SVG, HTML to PDF Saxon HE with Xerces, Verovio Toolkit, Prince XML

While it is possible to build the artifacts with other tools, the above are tested and thus recommended. Moreover, we try to support the building process on the most common operating systems (Microsoft Windows, Apple macOS and Linux), and currently have the following documented ways of building the artifacts:

  • command line: If your build system meets the prerequisites as described in Building MEI on the command line, you can build the artifacts natively.
  • Docker: MEI maintains a Docker image that meets all the prerequisites and can be used for building the artifacts via the command line. How to use the Docker image is described in the README of the docker-mei repository.
  • oXygen XML Editor: When the command line is not your preferred tool and you do not want to build the Guidelines PDF, you might consider using alternative environments, such as Synchrosoft’s oXygen XML software family. A description of how to set up corresponding transformation scenarios can be found in Building MEI with oXygen XML Editor.

Additional Resources

A live version of the MEI Guidelines is available on the MEI Website in the ’Documentation‘ menu:

In addition to the source files for MEI in this repository, there are other useful resources in other MEI repositories. The prebuilt release and development versions of:

And moreover

Referenced Material

  • Viglianti, R. (2019). One Document Does-it-all (ODD): A language for documentation, schema generation, and customization from the Text Encoding Initiative. Symposium on Markup Vocabulary Customization, Washington, DC. https://doi.org/10.4242/BalisageVol24.Viglianti01

License

Copyright 2017-2023 by the Music Encoding Initiative (MEI) Board (formerly known as "MEI Council")

Licensed under the Educational Community License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://opensource.org/licenses/ECL-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

This is a derivative work based on earlier versions of the schema © 2001-2006 Perry Roland and the Rector and Visitors of the University of Virginia; licensed under the Educational Community License version 1.0.

CONTACT: [email protected]

sibmei's People

Contributors

adrianholovaty avatar ahankinson avatar annplaksin avatar dependabot[bot] avatar martha-thomae avatar mjwalter avatar mss2221 avatar rettinghaus avatar th-we avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

sibmei's Issues

invalid MEI caused by beam containing a single note

A single note having its beam property set to 'endBeam' it will result in an invalid MEI.
It is possible that this is a mistake in the Sibelius file, still, it's not very nice to have invalid MEI at the output.

problem with split secondary beams

There is a problem with the way sibmei encodes beaming. Specifically, secondary beams.
Basically, what it seems to be doing is grouping the notes on which secondary beams begin to the end of the beamed group.
So, when I input something like this into sibelius:
screen shot 2015-05-22 at 9 31 30 am

sibmei turns it into this:
screen shot 2015-05-22 at 9 31 35 am

Another example:
screen shot 2015-05-22 at 9 29 51 am
screen shot 2015-05-22 at 9 29 56 am

quadruple dots

I don't actually know if it's even possible to fix this, because it's mostly sibelius' fault I think, but quadruple dots don't show up in the mei files.
The problem is that sibelius only allows up to 3 dots on notes, so if you want any more, you have to get the symbol that looks like it and add it as the fourth dot, then hide a rest to make it look right. It's a weird work around, that makes the mei files end up with

<note dots="3" dur="2" dur.ges="960p" oct="4" pname="g" xml:id="p1cgd4n0v1b2s1"/>
<space dur="32" dur.ges="32p" xml:id="p1r960v1b2s1"/>
<note dur="32" dur.ges="32p" oct="4" pname="g" xml:id="p1cgd4n992v1b2s1"/>

in this file, which is technically right considering what we put into sibelius, but not actually what we wanted.

Accidentals in key signature still show up

The accidentals in the mei files are always written as just accid, so they show up even when they are already in the key signature and don't actually need to.
I think this is also related to issue #20 with the natural signs not being written in, because natural signs don't show up when they cancel out the key signatures either.

endings in repeats

Right now, endings show up grouped together in one <ending/> tag (labelled n="2" no matter what), rather than separated correctly. Also it seems like the last bar in the ending doesn't end up in this group. Here and here are the two files.

The examples are on this page.

Which note should have ornam attribute?

This:
screen shot 2014-06-18 at 12 38 45
translates to this:

<note dur="8" dur.ges="128p" grace="acc" ho="-3.1172mm" oct="5" ornam="A" pname="f" xml:id="p1cfd5n0g1800v1b2s1"/>
<note dur="2" dur.ges="512p" oct="5" pname="e" xml:id="p1ced5n0v1b2s1"/>
<note dur="4" dur.ges="256p" oct="5" pname="d" xml:id="p1cdd5n512v1b2s1"/>

I think the ornam attribute is on the wrong element, since according to the MEI guidelines the presence of an ornam attribute "indicates that this element has an attached ornament", so it shouldn't be on the grace note itself, but on the principal note.

Dangling ties

How should dangling ties be encoded? In any case, the current way of converting them in chords is flawed:

<chord xml:id="m-46" dur="8" dur.ges="128p" stem.dir="down" visible="false">
    <note xml:id="m-47" dur="8" dur.ges="128p" oct="4" pname="g" pnum="67"/>
    <note xml:id="m-49" dur="8" dur.ges="128p" oct="4" pname="g" pnum="67"/>
</chord>
...
<tie xml:id="m-48" endid="#m-49" startid="#m-47"/>
<tie xml:id="m-50" startid="#m-49"/>

I.e., the first tie goes from one chord note to the other, which does not make sense. The second tie is maybe O.K., but I wonder whether it would be even more reasonable to encode it as laissez vibrer. Maybe @lv should be allowed on <tie> as well, but that's a topic for the main MEI issue tracker.

The following test case is taken from a "real life" document, but it's a little strange and probably an input error in this case:

dangling-ties.zip

changed stem directions

When we change the stem direction in a sibelius file, it doesn't show up as stem.dir="up", like you'd expect, so the stems go back to their default positions in verovio.

Ties with chords with attributes

It seems that the attribute tie with chords are wrong. SibMEI puts value "i" only for one note in the first tied chord and them "m". All notes should have the value "i" and similarly all notes should have "t" in the last tied chord. See example ties-chords-2 in the MEI test-set

Editorial accidental ouput within a <supplied> element

Editorial accidentals placed above or below the staff are converted to /accid with func="edit" and place="above". This is fine, however, they are also placed within a /supplied element. I am not convinced that this should always be the case and being "editorial" and being "supplied" are actually two different characteristics. Ideally it should be an option (dialog box at the output?) for the user to decide if the editorial accid are supplied or if they appear as such in the source, unless there is a way to represent the difference directly it in Sibelius?

cross-staff notation

Sibmei doesn't seem to be encoding cross-staff notation.
This:
screen shot 2015-05-22 at 10 41 51 am
came out looking like this:
screen shot 2015-05-22 at 10 41 38 am
the ties and stem directions are another problem, though.

export of ornaments

While turns are exported quite nice, mordents are missing several attributes. There is missing @staff and @layer and most importantly @startid (@tstamp).
Long mordents won't get exported at all.
Notice that stroked turns are exported as inverted turns, while (normal) inverted turns will be ignored.

Preferably all ornaments should have a @startid instead of a @tstamp

<?xml version="1.0" encoding="UTF-16" ?>
<mei xml:id="m-1" meiversion="3.0.0" xmlns="http://www.music-encoding.org/ns/mei" xmlns:xlink="http://www.w3.org/1999/xlink">
<meiHead xml:id="m-2">
    <fileDesc xml:id="m-3">
        <titleStmt xml:id="m-4">
            <title xml:id="m-10"/>
            <respStmt xml:id="m-11">
                <persName xml:id="m-12"/>
            </respStmt>
        </titleStmt>
        <pubStmt xml:id="m-13">
            <availability xml:id="m-14">
                <useRestrict xml:id="m-15">Copyright © </useRestrict>
            </availability>
        </pubStmt>
    </fileDesc>
    <encodingDesc xml:id="m-16">
        <appInfo xml:id="m-17">
            <application xml:id="sibelius" isodate="2017-2-3T16:13:22Z" version="7500">
                <name xml:id="m-19" type="operating-system">Windows 7</name>
            </application>
            <application xml:id="sibmei" type="plugin" version="2.0.2">
                <name xml:id="m-21">Sibelius to MEI Exporter (2.0.2)</name>
            </application>
        </appInfo>
    </encodingDesc>
    <workDesc xml:id="m-5">
        <work xml:id="m-6">
            <titleStmt xml:id="m-7">
                <title xml:id="m-8"/>
                <respStmt xml:id="m-9"/>
            </titleStmt>
        </work>
    </workDesc>
</meiHead>
<music xml:id="m-22">
    <body xml:id="m-23">
        <mdiv xml:id="m-24">
            <score xml:id="m-25">
                <scoreDef xml:id="m-26" lyric.name="Opus Text Std" meter.count="4" meter.unit="4" music.name="Opus Std" page.botmar="12.7mm" page.height="297mm" page.leftmar="12.7mm" page.rightmar="12.7mm" page.topmar="12.7mm" page.width="210mm" ppq="256" text.name="Plantin MT Std">
                    <staffGrp xml:id="m-27">
                        <staffDef xml:id="m-28" clef.line="2" clef.shape="G" key.mode="major" key.sig="0" label="" lines="5" n="1">
                            <!-- keyboard.piano.grand.bright -->
                            <instrDef xml:id="m-30" midi.channel="1" midi.pan="63" midi.volume="100"/>
                        </staffDef>
                    </staffGrp>
                </scoreDef>
                <section xml:id="m-31">
                    <measure xml:id="m-32" label="1" n="1">
                        <staff xml:id="m-33" n="1">
                            <layer xml:id="m-34" n="1">
                                <note xml:id="m-35" dur="4" dur.ges="256p" oct="5" pname="c" pnum="72" stem.dir="down"/>
                                <note xml:id="m-36" dur="4" dur.ges="256p" oct="4" pname="a" pnum="69" stem.dir="up"/>
                                <note xml:id="m-37" dur="4" dur.ges="256p" oct="4" pname="f" pnum="65" stem.dir="up"/>
                                <note xml:id="m-38" dur="4" dur.ges="256p" oct="4" pname="a" pnum="69" stem.dir="up"/>
                            </layer>
                        </staff>
                        <mordent xml:id="m-39" form="inv"/>
                        <mordent xml:id="m-40" form="norm"/>
                        <turn xml:id="m-41" form="norm" layer="1" staff="1" tstamp="3" vo="5.25mm"/>
                        <turn xml:id="m-42" form="inv" layer="1" staff="1" tstamp="4" vo="5.25mm"/>
                    </measure>
                    <measure xml:id="m-43" n="2">
                        <staff xml:id="m-44" n="1">
                            <layer xml:id="m-45" n="1">
                                <note xml:id="m-46" dur="4" dur.ges="256p" oct="5" pname="c" pnum="72" stem.dir="down"/>
                                <note xml:id="m-47" dur="4" dur.ges="256p" oct="4" pname="a" pnum="69" stem.dir="up"/>
                                <note xml:id="m-48" dur="4" dur.ges="256p" oct="4" pname="f" pnum="65" stem.dir="up"/>
                                <note xml:id="m-49" dur="4" dur.ges="256p" oct="4" pname="a" pnum="69" stem.dir="up"/>
                            </layer>
                        </staff>
                        <trill xml:id="m-50" layer="1" staff="1" tstamp="1" vo="5.25mm"/>
                    </measure>
                    <measure xml:id="m-51" n="3">
                        <staff xml:id="m-52" n="1">
                            <layer xml:id="m-53" n="1">
                                <note xml:id="m-54" dur="4" dur.ges="256p" oct="5" pname="c" pnum="72" stem.dir="down"/>
                                <note xml:id="m-55" dur="4" dur.ges="256p" oct="4" pname="b" pnum="71" stem.dir="down"/>
                                <note xml:id="m-56" dur="4" dur.ges="256p" oct="4" pname="a" pnum="69" stem.dir="up"/>
                                <note xml:id="m-57" dur="4" dur.ges="256p" oct="4" pname="d" pnum="62" stem.dir="up"/>
                            </layer>
                        </staff>
                    </measure>
                    <measure xml:id="m-58" n="4" right="end">
                        <staff xml:id="m-59" n="1">
                            <layer xml:id="m-60" n="1">
                                <note xml:id="m-61" dur="4" dur.ges="256p" oct="4" pname="f" pnum="65" stem.dir="up"/>
                                <note xml:id="m-62" dur="4" dur.ges="256p" oct="4" pname="e" pnum="64" stem.dir="up"/>
                                <rest xml:id="m-63" dur="2" dur.ges="512p"/>
                            </layer>
                        </staff>
                    </measure>
                </section>
            </score>
        </mdiv>
    </body>
</music>
</mei>

ornaments.zip

problem with grace note groupings

This is a problem that only comes up if there are multiple notes with grace notes in a single bar.
If the first grace note in the bar is a single grace note, it works fine, but all the remaining grace notes, no matter what their original grouping was, get grouped together (with the right pitches, duration and order) onto the second note that contains a grace note.
However, if the first grace note is a group of grace notes, all the rest in the bar appear on that first note right away.
sibelius original
verovio

Check syllable elision

Currently sibmei spits out "_" for syllable elision. Use `@con="b"`` for syllable elision instead.

clef changes

It seems that when there are beams over clef changes, sibmei doesn't do it properly. It ends up grouping the changed clefs to the end of the beamed group.
(here, the clef should be changing every eighth note in the first half of each bar)
screen shot 2015-05-21 at 4 14 47 pm

Performed duration (@dur.ges) isn't affected by <tuplet>

The performed duration (@dur.ges value) of a note inside a element, is not affected by the tuplet. In other words, a note inside a has the same performed value that a note outside of a tuplet.

Here is an example:
You can see that both eighth notes, inside and outside the tuplet, have a @dur.ges = "128p".
The same with the quarter notes, they have a @dur.ges = "256p", independently of them being inside or outside the .
performed-duration_issue.zip

mid-bar repeats

Mid-bar repeats in sibelius end up on the closest barline in the mei files, instead of in the bar. Here for example. In these cases, <barLine/> should be used in the middle of the measure.

Grand staff label

Grand staff labels are directed to staffDef labels but should go to staffGrp

dynamics

<scoreDef meter.count="4" meter.unit="4" page.botmar="12.7mm" page.height="297mm" page.leftmar="12.7mm" page.rightmar="12.7mm" page.topmar="12.7mm" page.width="210mm" ppq="256">
  <staffGrp>
    <staffGrp n="1" symbol="brace">
      <staffDef clef.line="2" clef.shape="G" key.mode="major" key.sig="0" label="Piano" lines="5" n="1" xml:id="sd1"/>
      <staffDef clef.line="4" clef.shape="F" key.mode="major" key.sig="0" label="Piano" lines="5" n="2" xml:id="sd2"/>
    </staffGrp>
  </staffGrp>
</scoreDef>

One tuplet encoded as multiple <tuplet> elements

Some tuplets in the Sibelius file are encoded as multiple elements in the mei file, instead of just one element.

When the base of a tuplet is ‘2’, if its numerator is greater than 3; the tuplet is encoded as more than one element in the mei file. Compare measures 4 and 6 to measure 2 in “tuplets_1”.

I think that this can be the cause that certain tuplets even get merged together sometimes, as in measure 8 of “tuplets_1” and measures 1 and 2 of “tuplets_2”; in the latter, this merge of tuplets even change the order of the notes.

tuplet_issues.zip

Tails in dotted rhythms don't show up

When there's a dotted rhythm (e.g. a dotted quarter followed by eighth note), the eighth note gets wrapped in a beam. The beam doesn't show up, but neither does the tail of the individual eighth.
This also happens with smaller note values, and in compound time signatures with quarters and eighth notes.
It's not a problem, however, when the note values are small enough to be grouped together (e.g. dotted eighth followed by sixteenth note).

doubled tuplets

In following case the tuplet gets exported twice mysteriously. Both with the exact same contents, doubling ids.

grafik

<?xml version="1.0" encoding="UTF-16" ?>
<mei xml:id="m-1" meiversion="3.0.0" xmlns="http://www.music-encoding.org/ns/mei" xmlns:xlink="http://www.w3.org/1999/xlink">
<meiHead xml:id="m-2">
    <fileDesc xml:id="m-3">
        <titleStmt xml:id="m-4">
            <title xml:id="m-10"/>
            <respStmt xml:id="m-11">
                <persName xml:id="m-12"/>
            </respStmt>
        </titleStmt>
        <pubStmt xml:id="m-13">
            <availability xml:id="m-14">
                <useRestrict xml:id="m-15">Copyright © </useRestrict>
            </availability>
        </pubStmt>
    </fileDesc>
    <encodingDesc xml:id="m-16">
        <appInfo xml:id="m-17">
            <application xml:id="sibelius" isodate="2017-2-3T16:33:22Z" version="7500">
                <name xml:id="m-19" type="operating-system">Windows 7</name>
            </application>
            <application xml:id="sibmei" type="plugin" version="2.0.2">
                <name xml:id="m-21">Sibelius to MEI Exporter (2.0.2)</name>
            </application>
        </appInfo>
    </encodingDesc>
    <workDesc xml:id="m-5">
        <work xml:id="m-6">
            <titleStmt xml:id="m-7">
                <title xml:id="m-8"/>
                <respStmt xml:id="m-9"/>
            </titleStmt>
        </work>
    </workDesc>
</meiHead>
<music xml:id="m-22">
    <body xml:id="m-23">
        <mdiv xml:id="m-24">
            <score xml:id="m-25">
                <scoreDef xml:id="m-26" lyric.name="Opus Text Std" meter.count="2" meter.unit="4" music.name="Opus Std" page.botmar="15mm" page.height="297mm" page.leftmar="15mm" page.rightmar="60mm" page.topmar="15mm" page.width="210mm" ppq="256" text.name="Times New Roman">
                    <staffGrp xml:id="m-27">
                        <staffGrp xml:id="m-34" n="1" symbol="brace">
                            <staffDef xml:id="m-28" clef.line="2" clef.shape="G" key.mode="major" key.sig="2f" label="" lines="5" n="1">
                                <!-- strings.violin.ensemble -->
                                <instrDef xml:id="m-30" midi.channel="1" midi.pan="26" midi.volume="100"/>
                            </staffDef>
                            <staffDef xml:id="m-31" clef.line="4" clef.shape="F" key.mode="major" key.sig="2f" label="" lines="5" n="2">
                                <!-- strings.violoncello.ensemble -->
                                <instrDef xml:id="m-33" midi.channel="1" midi.pan="88" midi.volume="90"/>
                            </staffDef>
                        </staffGrp>
                    </staffGrp>
                </scoreDef>
                <section xml:id="m-35">
                    <measure xml:id="m-36" label="1" n="1">
                        <staff xml:id="m-37" n="1">
                            <layer xml:id="m-38" n="1">
                                <tuplet xml:id="m-42" endid="#m-47" num="6" num.format="count" numbase="4" startid="#m-39">
                                    <beam xml:id="m-41">
                                        <note xml:id="m-39" dur="16" dur.ges="64p" oct="5" pname="b" pnum="82" stem.dir="down">
                                            <accid xml:id="m-40" accid.ges="f"/>
                                        </note>
                                        <note xml:id="m-43" dur="16" dur.ges="64p" oct="5" pname="f" pnum="77" stem.dir="down"/>
                                        <note xml:id="m-44" dur="16" dur.ges="64p" oct="5" pname="e" pnum="75" stem.dir="down">
                                            <accid xml:id="m-45" accid.ges="f"/>
                                        </note>
                                        <note xml:id="m-46" dur="16" dur.ges="64p" oct="5" pname="d" pnum="74" stem.dir="down"/>
                                        <note xml:id="m-47" dur="16" dur.ges="64p" oct="5" pname="c" pnum="72" stem.dir="down"/>
                                        <note xml:id="m-48" dur="16" dur.ges="64p" oct="4" pname="b" pnum="70" stem.dir="down">
                                            <accid xml:id="m-49" accid.ges="f"/>
                                        </note>
                                    </beam>
                                </tuplet>
                                <tuplet xml:id="m-50" num="6" num.format="count" numbase="4" startid="#m-48">
                                    <beam xml:id="m-41">
                                        <note xml:id="m-39" dur="16" dur.ges="64p" oct="5" pname="b" pnum="82" stem.dir="down">
                                            <accid xml:id="m-40" accid.ges="f"/>
                                        </note>
                                        <note xml:id="m-43" dur="16" dur.ges="64p" oct="5" pname="f" pnum="77" stem.dir="down"/>
                                        <note xml:id="m-44" dur="16" dur.ges="64p" oct="5" pname="e" pnum="75" stem.dir="down">
                                            <accid xml:id="m-45" accid.ges="f"/>
                                        </note>
                                        <note xml:id="m-46" dur="16" dur.ges="64p" oct="5" pname="d" pnum="74" stem.dir="down"/>
                                        <note xml:id="m-47" dur="16" dur.ges="64p" oct="5" pname="c" pnum="72" stem.dir="down"/>
                                        <note xml:id="m-48" dur="16" dur.ges="64p" oct="4" pname="b" pnum="70" stem.dir="down">
                                            <accid xml:id="m-49" accid.ges="f"/>
                                        </note>
                                    </beam>
                                </tuplet>
                                <beam xml:id="m-52">
                                    <note xml:id="m-51" dur="8" dur.ges="128p" oct="5" pname="f" pnum="77" stem.dir="down"/>
                                    <note xml:id="m-53" dur="8" dur.ges="128p" oct="4" pname="f" pnum="65" stem.dir="down"/>
                                </beam>
                            </layer>
                        </staff>
                        <staff xml:id="m-54" n="2">
                            <layer xml:id="m-55" n="1">
                                <chord xml:id="m-56" dur="8" dur.ges="128p" stem.dir="down">
                                    <note xml:id="m-57" dur="8" dur.ges="128p" oct="3" pname="b" pnum="58">
                                        <accid xml:id="m-58" accid.ges="f"/>
                                    </note>
                                    <note xml:id="m-59" dur="8" dur.ges="128p" oct="4" pname="d" pnum="62"/>
                                    <note xml:id="m-60" dur="8" dur.ges="128p" oct="4" pname="f" pnum="65"/>
                                </chord>
                                <rest xml:id="m-61" dur="8" dur.ges="128p"/>
                                <chord xml:id="m-62" dur="8" dur.ges="128p" stem.dir="down">
                                    <note xml:id="m-63" dur="8" dur.ges="128p" oct="3" pname="a" pnum="57"/>
                                    <note xml:id="m-64" dur="8" dur.ges="128p" oct="4" pname="c" pnum="60"/>
                                    <note xml:id="m-65" dur="8" dur.ges="128p" oct="4" pname="f" pnum="65"/>
                                </chord>
                                <rest xml:id="m-66" dur="8" dur.ges="128p"/>
                            </layer>
                        </staff>
                        <tempo xml:id="m-67">
                            <anchoredText xml:id="m-68" ho="-4.0625mm">Vivace</anchoredText>
                        </tempo>
                    </measure>
                </section>
            </score>
        </mdiv>
    </body>
</music>
</mei>

BeamedTuplet.zip

Investigate tuplets

It seems that exporting tuplets does not work. This should be investigated.

Export to .mei with sibmei-1.4 in Sibelius 8.2

After trying to export a MusicXML file to .mei in Siblius with the stable release plug-in sibmei-1.4 I get the following (error) message in Sibelius 8.2:

screen shot 2016-04-04 at 12 41 20 pm

There are no problems using the 2.0.0-beta3 version of the plug-in in Sibelius 8.2.

Double sharps and flats

I think the current exporter is outdated, because double sharps and double flats show up in the mei files as "ds" and "df", when they should be "ss" and "ff".

beams across barlines

Beams across barlines are just encoded separately right now. It just shows up like this. Instead, there should probably be a <beamSpan/> that encompasses the notes in question.

Bug in sibmei-2.0.0-beta3

Hello,

I got the error with sibmei-2.0.0-beta3:

mei/sibmei2::GenerateLine:27:Field octl not found

It probably comes from the line:

line = libmei.Octave();

that should be replaced by:

octl = libmei.Octave();

Regards

tuplets with rests

When tuplets have rests in them, sibmei groups all the notes to the front, puts the rest in the tuplet, and at the end of the group.
screen shot 2015-05-21 at 12 12 21 pm

However, it seems to only be an issue if there are beams on the notes, because when they're separate, it works fine.
screen shot 2015-05-21 at 12 12 14 pm

What's weird, though, is that it does the incorrect tuplet placement with normal tuplets (i.e. when there are no rests involved), but somehow not all the time, and I can't really tell when.
screen shot 2015-05-21 at 12 18 53 pm

Word continuations not encoded correctly

In the newest version of the SibMei plug in, the word continuation attributes are not being encoded in the <syl> element. The attribute con="d" should be within the <syl> element:

<syl con="d" wordpos="i">TEXT</syl>

I think the region of the plug to word on is here:

sibmei/sibmei.plg

Lines 991 to 1019 in e99b0e5

// Sibelius only keeps track of 'end-of-word' or not;
// MEI has initial, medial *and* terminal.
// Thus we must work out the distinction ourselves,
// keeping track with a global variable.
if (lyricobj.SyllableType = EndOfWord)
{
middleOfWord = false;
libmei.addAttribute(syl, 'wordpos', 't'); // 'terminal'
// If this syllable lasts for more than one note...
if (lyricobj.NumNotes > 1)
{
libmei.addAttribute(syl, 'con', 'u'); // 'underscore'
}
}
else
{
if (middleOfWord = false)
{
libmei.addAttribute(syl, 'wordpos', 'i'); // 'initial'
}
else
{
libmei.addAttribute(syl, 'wordpos', 'm'); // 'medial'
}
middleOfWord = true;
libmei.addAttribute(syl, 'con', 'd'); // hyphen or 'dash' connector
}
libmei.addChild(v, syl);

Batch export not showing up

In version 1.2, there was an option "Export folder to MEI". Was the option removed in later version? Is there as way to put it back?

Octave designation

Hi Andrew,
I'm not sure if this is just a Sibelius issue or if it's something that's happening in the Sib to MEI export. Some of voice parts are in the wrong octave. It looks like it is in all the @oct attributes of note, and I think it's happening to voice parts that I changed the clef on (some I originally had in treble clef and changed to tenor, and had to transpose up down an octave to make them look correct in Sibelius). I saw the error when I tried to open the mei files in Laurent's MEI viewer. Looks like I can't attach MEI or Sib files here so I'll email you the MEI file where the motetus and tenor (voice 3 and 4) are in the wrong octave in the MEI version (though I changed the @oct attribute of the motetus first note to show where it's supposed to be); and the Sibelius file.
Thanks
Karen

accid vs accid.ges

The output in SibMEI does not take into account the key signature and add an accid attribute to all notes even if it is given in the key signature. For example, in G-major, all F (e.g., F-sharp) have an accid="s". F-natural have no accid attribute.

I am not sure the guidelines are very clear how to use accid and accid.ges, but this does not seems to be compliant with what we have in the MEI examples. The practice in all the examples I looked at is to use the accid attribute to encode what appears in the score and accid.ges for how it sounds. So in G-major, F-sharp have an accid.ges="s" but no accid. F-natural have an accid="n" (accid.ges is not necessary, I guess) and notes with accidental (sharp) not in the key signature have both accid="s" and accid.ges="s". (Only the first note in the measure will have and accid="s").

Slurs are one duration off for dur.ges

For example, if the duration of a slur should be 512, it is showing up as 256. If it should be 1024, it's showing up as 768. Something fishy is going on...

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.