Skip to content

Commit

Permalink
Merge pull request #71 from axelberndt/develop
Browse files Browse the repository at this point in the history
Tutorial update
  • Loading branch information
axelberndt authored Feb 16, 2023
2 parents 60766a7 + 4a3c559 commit 8117c2f
Show file tree
Hide file tree
Showing 9 changed files with 66 additions and 63 deletions.
14 changes: 7 additions & 7 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# Contributing to MPM

While the seeds of this project were sowed by only a handfull of protagonists, watering and raising it is certainly not reserved to some privileged. If you like to contribute to MPM's growth do not hesitate. You are very welcome! With the following guidelines we hope to help you and us to orient more easily in the project's organization and formulate contributions fruitfully.
While the seeds of this project were sowed by only a handfull of protagonists, watering and raising it is certainly not reserved to some privileged. If you wish to contribute to MPM's growth do not hesitate. You are very welcome! With the following guidelines we hope to help you and us to orient more easily in the project's organization and formulate contributions fruitfully.


## How can I contribute?
Expand All @@ -20,7 +20,7 @@ The encoding guidelines and schema documentation are certainly not perfect or fi

## Contributing to the Sample Encodings

The major role of the sample encodings is to complement the encoding guidelines. The sample encodings demonstrate the capabilities of MPM. Users can consult them to see what the XML looks like and how certain features are applied. Hence, they have to validate against the latest official MPM schema. Each MPM must be accompanied by at least one MEI, MSM or MIDI file to which it is meant to be applied so that all users can reproduce the performance by use of the official performance renderer in [meico](https://github.com/cemfi/meico).
The major role of the sample encodings is to complement the encoding guidelines. The sample encodings demonstrate the capabilities of MPM. Users can consult them to see what the XML code looks like and how certain features are applied. Hence, they have to validate against the latest official MPM schema. Each sample encoding should be prepared as an MPM Toolbox project and contain all the necessary data so that any user can load and run it in the [MPM Toolbox](https://github.com/axelberndt/MPM-Toolbox).

To submit a sample encoding,
1. fork this repository,
Expand All @@ -29,7 +29,7 @@ To submit a sample encoding,
4. push it to your repository,
5. click the `compare & pull request` button and create a pull request.

Alternatively, you can also just email the files to [Axel Berndt]([email protected]). Your encoding will be reviewed internally and, if all is fine, merged into the MPM repository.
Your encoding will be reviewed internally and, if all is fine, merged into the MPM repository.


## Proposing New Features
Expand All @@ -40,7 +40,7 @@ Music theory has lots of terms for lots of performance concepts. But when lookin

Performance features should be as primitive as possible in that they are broken down to their absolute core characteristics. Articulation, e.g., is broken down to the effects that it has to the notes it is applied to, i.e. in comparison to a note that is played as notated without articulation. We identified a series of modifiers that have absolute and relative effects to the notes' attributes, such as duration, velocity and timing changes. Here are two examples of high-level features that MPM does already support, but by means of lower-level features: (1) "Musical agogics" is composed of tempo, rubato, dynamics, and articulation. (2) "Phrasing" is achieved by means of dynamics, tempo and articulation.

Nontheless, we are also very interested in higher-level performance concepts such as "agogics" and "phrasing". Although these are not the primitive building blocks that make up a performance, they do describe the mechanisms behind it, the aesthetic agenda, from which specific combinations of building blocks derive. They form the knowledge base, the rules which might be used to generate performances that you do not need to create manually in every detail. We regard such more generative application scenarios as a potential future perspective of MPM. Hence, any contribution in this regard is also welcome and will hopefully ultimately lead to new additions to the MPM format.
Nontheless, we are also very interested in higher-level performance concepts such as "agogics" and "phrasing". Although these are not the primitive building blocks that make up a performance, they do describe the mechanisms behind it, the aesthetic agenda, from which specific combinations of building blocks derive. They form the knowledge base, the rules which might be used to generate performances that you do not need to create manually in every detail. We regard such more generative application scenarios as a potential future perspective of MPM. Hence, any contribution in this regard is also welcome and will hopefully ultimately lead to new additions to the MPM format. So please do not hesitate to initiate discussions (and perhaps even dedicated research activities) on such subjects.


## Contributing to the Codebase
Expand All @@ -53,15 +53,15 @@ If you are used to working with TEI ODD and Schematron and want to support us wi

Your contribution will be reviewed internally and, if all is fine, merged into the MPM repository and, in the course of the next release version, also into the `master` branch. However, we ask you to pay attention to the following remarks.

In order to support readability and ensure smooth interplay with the continuous integration, please adhere to the coding conventions established so far. This includes the following points.
In order to support readability and ensure smooth interplay with MPM's software tools and `doc_generator`, please adhere to the coding conventions established so far. This includes the following points.
- Element specifications, attribute classes, model classes, and modules are implemented in individual files in the `src/specs/` folder. Feel free to create a subfolder that bundles your new files so they do not get lost in the plethora of files.
- The root document is `src/mpm.odd`. This is the place where these files are integrated in the `<tei:back>` section.
- From MPM version 2.0.0 on we ensure backward compatibility. Any MPM file that validates against version 2.0.0 schema must also validate against later versions.
- From MPM version 2.0.0 on we ensure backward compatibility. Any MPM file that validates against version 2.0.0 schema (e.g., all the sample encodings) must also validate against later versions.

There is more to the development of MPM's performance features than meets the eye, as you may have guessed already from reading the previous section (Proposing New Features).
- New features must be well documented so others can grasp them.
- Each feature is well researched and supported by emprical evidence. New additions should have an equally strong foundation.
- Each feature must be accompanied by a mathematical model that reproduce its characteristics. This is a necessary requirement to integrate it with the official API and performance rendering engine. Prefabricated Java code would help us a lot with this and is very welcome, see the [meico](https://github.com/cemfi/meico) project for more information on this.
- Each feature must be accompanied by a mathematical model that reproduces its characteristics. This is a necessary requirement to integrate it with the official API and performance rendering engine. Prefabricated Java code would help us a lot with this and is very welcome, see the [meico](https://github.com/cemfi/meico) project for more information on this.
- A feature's parameterization should be expressive and easy to understand. The raw mathematical parameters are often not very meaningful in a musical sense. A good example of this is MPM's dynamics model that boils the 8 coordinates of the Bézier curve down to two parameters `curvature` and `protraction`. The parameters should suffice to cover the whole bandwidth of incarnations of the feature. Avoid correlated parameters, i.e. parameters that interact with each other in a way that when one is changed another needs to be adapted.
- We are very critical about how features interact with each other. Imagine a timing feature that interferes with the tempo and destroys the synchronicity of musical parts that are meant to follow the same global tempo (despite any local micro timing variation).

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -278,8 +278,8 @@
<note xml:id="n70" pname="d" accid.ges="f" oct="4"/>
</chord>
<chord xml:id="c26" dur="16">
<note xml:id="n71" pname="c" accid.ges="f" oct="5"/>
<note xml:id="n72" pname="c" accid.ges="f" oct="4"/>
<note xml:id="n71" pname="c" oct="5"/>
<note xml:id="n72" pname="c" oct="4"/>
</chord>
</beam>
</layer>
Expand Down
Original file line number Diff line number Diff line change
@@ -1,5 +1,6 @@
<?xml version="1.0" encoding="UTF-8"?>
<?xml-model href="../../../../MPM/MPM%20(develop%20branch)/src/out/mpm.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://github.com/axelberndt/MPM/releases/latest/download/mpm.rng" type="application/xml" schematypens="http://relaxng.org/ns/structure/1.0"?>
<?xml-model href="https://github.com/axelberndt/MPM/releases/latest/download/mpm.rng" type="application/xml" schematypens="http://purl.oclc.org/dsdl/schematron"?>
<mpm xmlns="http://www.cemfi.de/mpm/ns/1.0">
<metadata>
<author>Axel Berndt</author>
Expand All @@ -16,6 +17,7 @@
<resource uri="score/page-07.png" type="png"/>
<resource uri="score/page-08.png" type="png"/>
<resource uri="score/page-09.png" type="png"/>
<resource uri="score/page-10.png" type="png"/>
<resource uri="Performance Score Maria Waloschek.png" type="png"/>
<resource uri="audio/Maria Waloschek - Moment Musical.wav" type="wav"/>
</relatedResources>
Expand Down
Loading

0 comments on commit 8117c2f

Please sign in to comment.