-
Notifications
You must be signed in to change notification settings - Fork 2
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #71 from axelberndt/develop
Tutorial update
- Loading branch information
Showing
9 changed files
with
66 additions
and
63 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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? | ||
|
@@ -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, | ||
|
@@ -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 | ||
|
@@ -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 | ||
|
@@ -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). | ||
|
||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.