Long note with changing dynamics exported to music xml

Code Questions
#1

I have a very long note which starts pp, has a crescendo to ff, and a diminuendo to pp. Playing such a note by using an envelope object for volume works fine. Put this isn’t exported to music xml. Using properties allows only for have pp and a cresendo hair pin over the whole note. A solution would be to play two notes with same pitch but half the length and using pp and crescendo hair pin in the first and ff and diminuendo hair pin for the second. But in the export these notes wouldn’t be tied together.

So any idea how to solve this problem?

1 Like
#2

This is a great point, and points to a larger issue: that properties are attached to note onsets and can’t occur at other points.

Unfortunately I can’t think of a simple workaround other than, as you say, playing two notes and then tying them after the fact in your music notation program. However, I’m curious: How would you (and any others reading this) want this to look on the user end?

It would be good, for instance to be able to attach dynamics or other properties during rests. But what should the code to do so look like?

#3

Hi Marc

Thanks for the quick answer.

I already thought that this isn’t possible. But I wanted to be sure.

The API could be extended by having a note property “tie” (and a corresponding Tie class).
About rests: I found that a None for the pitch in play_note() is turned into a rest in music xml export. But note properties seem to be ignored.

#4

As a work around I found the following solution:

from scamp import Session
from scamp.spanners import Spanner

from xml.etree import ElementTree
from pymusicxml.score_components import StopNumberedSpanner, StartNumberedSpanner
from pymusicxml.notations import Notation

class pymusicxmlStopTie(Notation, StopNumberedSpanner):
    def render(self):
        return ElementTree.Element("tied", {"type": "stop", "number": str(self.label)}),

class pymusicxmlStartTie(Notation, StartNumberedSpanner):
    STOP_TYPE = pymusicxmlStopTie
    def render(self):
        return ElementTree.Element("tied", {"type": "start", "number": str(self.label)}),
    

class StartTie(Spanner):
    START_MID_OR_STOP = "start"
    FORMATTING_SLOTS = {}
    def to_pymusicxml(self):
        return pymusicxmlStartTie(label=self.label, **self._get_xml_consistent_formatting())
    def to_abjad(self):
        return None

class StopTie(Spanner):
    START_MID_OR_STOP = "stop"
    FORMATTING_SLOTS = {}
    def to_pymusicxml(self):
        return pymusicxmlStopTie(label=self.label, **self._get_xml_consistent_formatting())
    def to_abjad(self):
        return None

s = Session()

violin = s.new_part("Violin")

s.fast_forward_to_beat(1000)
s.start_transcribing()

violin.play_note(60, 1, 4, ["pp", "start hairpin", StartTie()])
violin.play_note(60, 1, 2, [StopTie(), StartTie()])
violin.play_note(60, 1, 2, ["ff", "stop hairpin", "start hairpin >", "start hairpin", StopTie(), StartTie()])
violin.play_note(60, 1, 4)
violin.play_note(62, 0, 2, ["pp", "stop hairpin"])

s.stop_transcribing().to_score(time_signature="4/4").export_music_xml("tied-notes-test.xml")

After importing the created xml file into Sibelius I got what I want:

tied-notes-test
tied-notes-test1042×306 35.7 KB

This solution isn’t ideal because I have to do the quantization by myself. That is, I can not write

violin.play_note(60, 1, 6, ["pp", "start hairpin", StartTie()])

because the quantization process splits the 6/4 note into two notes. Unfortunately, the second note doesn’t get the StartTie() property.

#5

Btw, there is a not well documented feature that if you use a tuple for the note duration, it splits it into tied segments. e.g.

violin.play_note(60, 1, (4, 2))

The problem is that you can’t attach elements to the latter part of a tied segment.

I still come back to the question of: what would the ideal user-facing code look both in this situation, and in the situation in which you would want to add a notation to a rest. Any thoughts?

BTW, I’m impressed that you were able to dig into the code a create a workaround for yourself. I wonder if you’re interested in helping out from time to time with SCAMP? I’d like this to be a code-base that other people understand and contribute to as well, to help ensure it’s sustainable in the long term.

#6

I have tried the tuple idea. But the result is the same as if I had specified the sum instead of the tuple. That is, for example (6,6) is the same as 12. With a time signature 4/4 I get three bars each with a whole note instead of two halfs notes tied together in the middle bar.

But using tuples for the length together with tuples for the properties would be a sensible API extension. Another idea would be to do something similar as with Envelopes. Short notations could be something like "pp < ff > pp". Anyway, I think it is still useful of having notes with undefined pitch (using None) and properties for specifing rests. I think music xml allows this and it is up to the notation software what to do with e.g. a staccato rest.

#7

Ah! I seem to have changed something in the code that recombines tied segments, and forgot to make an exception of explicitly tied notes. I’ll fix it.