Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Default ornamentation style? #73

Open
pfefferniels opened this issue Feb 6, 2025 · 1 comment
Open

Default ornamentation style? #73

pfefferniels opened this issue Feb 6, 2025 · 1 comment

Comments

@pfefferniels
Copy link
Contributor

In many performance styles, a uniform manner of playing is applied throughout the whole performance. The defaultArticulation attribute of <style> thus allows defining e. g. a continuous non-legato style. Wouldn't it be consistent to also allow defining a defaultOrnamentation? In particular, I am thinking of performances like that one, which applies a rather uniform style of arpeggiation to (almost) every single chord – a feature, which is kind of typical for early 20th-century performances.

@axelberndt
Copy link
Owner

axelberndt commented Feb 7, 2025

Interesting case. Thanks for bringing it up. Hm, a defaultOrnamentation sounds dangerous, esp. since the ornamentation part of MPM is still in its infancy and we don't know what formalisms will come to enable more complex (e.g. melodic) ornaments. I would feel less worried if I knew that we would not put any obstacles in our way that become insurmountable later without breaking backward compatibility. Anyway, I am open to the idea, we should just think it through more thoroughly. Let us have a more direct discussion in Zoom.

In the meantime, I did some quick experimenting and was able to emulate the effect and its variations using <imprecisionMap.timing>. Maybe this is the even more attractive solution for your case. Here is what I did:

...
<performance name="my performance" pulsesPerQuarter="720">
    <global> ... </global>
    <part name="piano right hand" number="1" midi.channel="0" midi.port="0">
        <header/>
        <dated>
            <imprecisionMap.timing>
                <distribution.correlated.brownianNoise date="0.0" stepWidth.max="3.0" limit.lower="0.0" limit.upper="100.0" milliseconds.timingBasis="300.0"/>
            </imprecisionMap.timing>
        </dated>
    </part>
    <part name="piano left hand" number="2" midi.channel="1" midi.port="0">
        <header/>
        <dated>
            <imprecisionMap.timing>
                <distribution.correlated.brownianNoise date="0.0" stepWidth.max="5.0" limit.lower="-100.0" limit.upper="0.0" milliseconds.timingBasis="300.0"/>
            </imprecisionMap.timing>
        </dated>
    </part>
</performance>
...

And here comes the explanation. The right hand got an imprecision with positive offset and the left hand an imprecision with negative offset. The distribution is always spread between the lower and upper limit, so, all left hand notes are played before all right hand notes. When there are more than one note played at a time (e.g. chords), their timings are "shaken", see method meico.mpm.elements.maps.ImprecisionMap.shakeTimingOffsets() in the meico repository. This gives you this constantly varying arpeggiation effect as in your recording. That constant variation would be missing when using ornaments, by the way, and would require <imprecisionMap.timing> anyway. Instead of <distribution.correlated.brownianNoise> you might use <distribution.list> and place your measurements in it.

There are some further advantages to this approach. But there is also a problem. In the current implementation of the performance rendering algorithm the shake/arpeggiation order is not retained by the shaking mechanic, i.e. left hand does not necessarily always start with the lowest note and the right hand does not necessarily end with the highest. But this is solvable ...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants