LibMEI is a C++ library for reading and writing MEI files

To avoid the need of conflict resolution with merging commits one by one, this pull request supersedes #111, #112, #116 and #117.

This includes changes that were made to the libmei shipping with sibmei. For example, the RemoveChild() method was added with 24f5b43 in 2015, but was never added to the libmei generator.

Goal is that we can generate libmei for sibmei without having to manually merge changes every time.

Hi,

I have just tried to build the Python bindings after succesfully having compiled and installed libmei.

I followed the instructions on https://github.com/DDMAL/libmei/wiki/Installing-the-Python-bindings

:~/gitreps/libmei/python$ python setup.py build
running build
running build_py
running egg_info
writing pymei.egg-info/PKG-INFO
writing top-level names to pymei.egg-info/top_level.txt
writing dependency_links to pymei.egg-info/dependency_links.txt
reading manifest file 'pymei.egg-info/SOURCES.txt'
writing manifest file 'pymei.egg-info/SOURCES.txt'
running build_ext
building 'pymei/_libmei' extension
x86_64-linux-gnu-gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/usr/include/python2.7 -c src/_libmei.cpp -o build/temp.linux-x86_64-2.7/src/_libmei.o
cc1plus: warning: command line option ‘-Wstrict-prototypes’ is valid for C/ObjC but not for C++ [enabled by default]
src/_libmei.cpp:24:20: fatal error: Python.h: No such file or directory
 #include "Python.h"
                    ^
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1

It doesn't find Python.h. Where would that file be located?

I use Python 2.7.

Thx.

I get the following runtime error while importing an MEI that has an itemList element: That element name itemList was not registered with the factory and could not be created.

Python lists of MeiElement/MeiAttribute objects do not play well with the python bindings of the C++ functions.

for example:

attrs = nc.getAttributes()

# manipulate the array somehow
attrs.pop()

nc.setAttributes(attrs)

Results in:

MeiElement.setAttributes(MeiElement, list)
did not match C++ signature:
    setAttributes(mei::MeiElement {lvalue}, std::vector<mei::MeiAttribute*, std::allocator<mei::MeiAttribute*> >)

Currently the CMake script assumes that the GoogleTest framework is installed, and will fail if not. We should remove this as a dependency and make it optional to run the tests.

This issue happened using either python2 or python3. Using the libmei code from the develop branch (and from the previous release, the 2.0.0 version) when I do python setup.py build I got the message:

Library not found for -lboost_python-mt

Even though I did export CFLAGS="-F /Library/Frameworks -I /usr/local/include -L /usr/local/lib" to tell the system where lboost_python-mt is, as indicated in the Troubleshooting section of the python bindings in the wiki.

refs #88

A few small changes should be made to parseschema2:

1. Print out diagnostic information if any of the languages put in using the -l flag are not supported.

1.1) @AFFogarty also wants the -l flag to no longer be case sensitive so -l Python and -l python and -l PyThOn would work identically.

1.2) Change the --help flag to show that you can do multiple languages at the same time.

2. In the case where neither -sl OR [compiled] are present in the invocation (such as python parseschema2.py -l cpp), the warning message defaults to a message about -sl if the user has input other parameters. This is an edge case for misuse, but I think the default should be a message about the [compiled] parameter if it's missing. @ahankinson can correct me if he thinks otherwise.

Filed here so I don't forget:

Now that we have a flattened representation, it's also possible to do "lookback" methods. For example, we tell a note to find its layer, measure, and staff number by starting at the note and working backwards through the list until we find the first previous occurrence of that element.

This has the advantage of being outside of the normal hierarchy, so we can search for things that aren't normally related to that element. For example, if we want to find the system # that a note is on, we can look back until we find the first sb element. Since sb is normally a milestone (i.e., <sb />) element, the note has no direct relationship to it.

This will likely be a class of methods, since most objects will have different things they want to look back to find. For example, rests, notes, clefs, etc. will want to access measures, layers, systems, staffs, sections, etc., while staffDefs will want to find out if they're a member of a staffGrp.

We may also want to add an extra optional parameter for checking if it's also an ancestor. Imagine if we had:

...
<staffGrp>
      <staffDef />
      <staffDef />
</staffGrp>
<staffDef />
 ...

If we don't check for ancestry, then the last <staffDef> would be mistakenly included in the previous <staffGrp>.

For implementation, we may need a number of methods to support this.

int pos MeiElement->positionInDocument(); 
returns the element's position in the flattened document representation vector

MeiElement* el MeiDocument->lookBack(int startpos, string elname);
returns the first MeiElement* matching elname, starting at startpos and working backwards.

MeiElement* el MeiDocument->lookBack(int startpos, string elName, bool isAncestor);
returns the first MeiElement* matching elName, but allows the user to specify if they want to include (or exclude) only matches 
that are ancestors of the found element.

This would then be implemented at the Mei Element Object level, e.g.,

MeiElement* el staffDef->getStaffGrp() {
    int pos = staffDef->positionInDocument();
    MeiElement* staffGrp = staffDef->getDocument()->lookBack(pos, "staffGrp", True);
    return staffGrp;
}

Currently, MeiDocument stores ids and pointers to elements in a weakly-ordered map (alphabetical ordering by key). This makes it very difficult to do operations like "get me all elements that occur between ID A and ID B".

Possible solutions:

1. Store the ID map in some sort of ordered form (2D array?)
2. Store a map and an ordered vector as a lookup table. "Get me all elements between A and B" would slice the vector, and then retrieve all IDs between A and B from the ID Map.

Use case: Retrieving all elements between a startid and endid.

An element should know what document it belongs to. This has been started in the branch element-doc-link. These things should work:

• If an element is added as a child and neither element is attached to a document, nothing happens.
• If the parent element belongs to a document, the child element should be linked to the same document
• If an element tree is added to a document (MeiDocument::setRootElement), all elements should have their document pointer updated
• When an element gets its document set, it should tell the document what its id is. The document then stores a map<string, MeiElement> for getElementById lookups

If IDs are required, we should give the ability to automatically generate one. Either on construction of the element, or with a generateId() method. This needs to work in with reading an xml file with existing ids.

I was able to install libmei without XCode using the following commands:

git clone https://github.com/DDMAL/libmei.git
cd libmei
mkdir build && cd build
brew install cmake
brew install ossp-uuid
cmake .. -DCMAKE_FIND_FRAMEWORK=LAST
make
make install

This could be useful to others who don't normally use XCode. It might also help to streamline the creation of a Homebrew package.

I am seeing a memory leak with the simplest example document:

test.cpp:

#include <mei/mei.h>
#include <mei/shared.h>

int main(){
    mei::MeiDocument *doc = new mei::MeiDocument();
    mei::Mei *mei = new mei::Mei();
    doc->setRootElement(mei);
    delete doc;
}

I compile with this command:

clang++ -Wall -Werror -Wextra -Wpedantic -lmei -O1 -g -fsanitize=address -fno-omit-frame-pointer -o test test.cpp

This is the output from clang about the memory leak:

=================================================================
==16660==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 80 byte(s) in 1 object(s) allocated from:
    #0 0x4fd927 in operator new(unsigned long) (/[dir]/test+0x4fd927)
    #1 0x7fd379584aa8 in mei::MeiDocument::setRootElement(mei::MeiElement*) (/usr/local/lib/libmei.so+0xf3aa8)
    #2 0x50065e in main /[dir]/test.cpp:7:10
    #3 0x7fd378f9e55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)

Direct leak of 80 byte(s) in 1 object(s) allocated from:
    #0 0x4fd927 in operator new(unsigned long) (/[dir[/test+0x4fd927)
    #1 0x7fd379584b4e in mei::MeiDocument::setRootElement(mei::MeiElement*) (/usr/local/lib/libmei.so+0xf3b4e)
    #2 0x50065e in main /[dir]/test.cpp:7:10
    #3 0x7fd378f9e55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)

Indirect leak of 37 byte(s) in 1 object(s) allocated from:
    #0 0x4fd927 in operator new(unsigned long) (/[dir]/test+0x4fd927)
    #1 0x7fd3793b7181 in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_assign(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&) (/lib64/libstdc++.so.6+0x145181)

SUMMARY: AddressSanitizer: 197 byte(s) leaked in 3 allocation(s).

This unused code won't work any more because the surrounding code has evolved away from it. Specifically, MEIFlattened is no longer a SparseArray and can not be used in the way these function use it.

Since some features are deprecated (and more possibly will be eventually), keep errors on warnings (-Werror) but also add an exception to just warn on deprecation (-Wno-error=deprecated) rather than fail.

This keeps deprecation warnings visible and also causes more serious warnings (like uninitialized variables/pointers) to error.

This addresses issue #110.