mx::api::PedalLineData carries only kind, tickTimePosition and positionData. MusicXML's
<pedal> also has a number attribute (number-level), which is what distinguishes concurrent
pedal lines on one staff -- a damper line and a sostenuto line overlapping, for example.
Today the number is dropped in both directions:
DirectionReader reads pedal.type(), pedal.line() and the position attributes, but never
looks at pedal.number() (src/private/mx/impl/DirectionReader.cpp:676).DirectionWriter::emitPedal sets type and line and never sets number
(src/private/mx/impl/DirectionWriter.cpp:322).
So a score with two overlapping pedal lines round-trips into a single ambiguous run of events, and
an author using mx::api has no way to say which stop closes which start.
proposed
Give PedalLineData a SpannerNumber number field -- the same identity type wedges and curves
already use -- and wire it through the reader and through NumberResolver in the writer the way
emitWedgeStart / emitWedgeStop do.
deliberately not part of this
<pedal> has no line-type, dash-length, space-length or end-length attributes; it is not in
MusicXML's line-type or dashed-formatting attribute groups (see the generated core::Pedal in
src/private/mx/core/generated/Pedal.h). There is therefore no LineData for PedalLineData to
carry, and a consumer that wants pedal line styling has to pick it itself. Recording this here
because a consumer coming from an older fork that modelled pedals as generic SpannerStart /
SpannerStop will have had a lineData member and may expect one back; that member could never
have round-tripped.
<pedal> also has sign and abbreviated. mx currently uses them only to choose between the line
form (PedalLineData) and the sign form (MarkType::pedal / MarkType::damp). Round-tripping
abbreviated -- the short P / S signs versus the full Ped / Sost -- is a separate gap and
should be a separate issue if it is wanted.
related
mx::api::PedalLineDatacarries onlykind,tickTimePositionandpositionData. MusicXML's<pedal>also has anumberattribute (number-level), which is what distinguishes concurrentpedal lines on one staff -- a damper line and a sostenuto line overlapping, for example.
Today the number is dropped in both directions:
DirectionReaderreadspedal.type(),pedal.line()and the position attributes, but neverlooks at
pedal.number()(src/private/mx/impl/DirectionReader.cpp:676).DirectionWriter::emitPedalsetstypeandlineand never setsnumber(
src/private/mx/impl/DirectionWriter.cpp:322).So a score with two overlapping pedal lines round-trips into a single ambiguous run of events, and
an author using
mx::apihas no way to say whichstopcloses whichstart.proposed
Give
PedalLineDataaSpannerNumber numberfield -- the same identity type wedges and curvesalready use -- and wire it through the reader and through
NumberResolverin the writer the wayemitWedgeStart/emitWedgeStopdo.deliberately not part of this
<pedal>has noline-type,dash-length,space-lengthorend-lengthattributes; it is not inMusicXML's line-type or dashed-formatting attribute groups (see the generated
core::Pedalinsrc/private/mx/core/generated/Pedal.h). There is therefore noLineDataforPedalLineDatatocarry, and a consumer that wants pedal line styling has to pick it itself. Recording this here
because a consumer coming from an older fork that modelled pedals as generic
SpannerStart/SpannerStopwill have had alineDatamember and may expect one back; that member could neverhave round-tripped.
<pedal>also hassignandabbreviated. mx currently uses them only to choose between the lineform (
PedalLineData) and the sign form (MarkType::pedal/MarkType::damp). Round-trippingabbreviated-- the shortP/Ssigns versus the fullPed/Sost-- is a separate gap andshould be a separate issue if it is wanted.
related
numberadded here is the same spanner identity that designis concerned with.