Re: Semantic layout overrides

I've convinced myself to drop the second example in light of everyone's
feedback -- so it's gone now.

I am sure we're going to mine Chopin Nocturnes much, much more. The inner
voices in #2 m25 are also pretty interesting, but I think the same
semantic-override approach will work there as well without modification
(lay out a note as if it had some other note value)

.            .       .    .  . ...Joe

Joe Berkovitz
Founder
Noteflight LLC

49R Day Street
Somerville MA 02144
USA

"Bring music to life"
www.noteflight.com

On Tue, Apr 11, 2017 at 3:12 AM, Hans Vereyken <hans@neoscores.com> wrote:

> This example is one of the many engraving problems found in Chopin's
> Nocturnes Op.15. This specific problem can be found in no. 2 measure 25.
>
> A PDF can be found here: http://hz.imslp.info/files/imglnks/usimg/c/ca/
> IMSLP50497-PMLP02311-Chopin_Nocturnes_Schirmer_Mikuli_Op_15.pdf
>
> Hans
>
> *Hans Vereyken*
> Software engineer | neoScores
>
> *EMAIL* hans@neoscores.com <XXXXXX@neoscores.com>
> *PHONE* +32 (0) 4 <XXXXXX>72 52 75 59
>
> www.neoscores.com
> Facebook  <https://www.facebook.com/neoscores>| Twitter
> <https://twitter.com/neoscores>
>
> Gustaf  More room for music.
>
> *VISITOR ADDRESS* Designcenter De Winkelhaak, Lange Winkelhaakstraat 26,
> BE-2060 Antwerp, Belgium
> *INVOICING ADDRESS* neoScores NV, Sleutelstraat 13, BE-2550 Kontich,
> Belgium
> *VAT* BE 0536.406.040
>
> On 10 April 2017 at 18:27, Jan Rosseel <jan@scora.net> wrote:
>
>> Didn’t see a PDF, but I will counter with a similar example out of Rach3.
>> 6th measure after rehearsal mark 50. Look it up on IMSLP. Combination of
>> double dotted eights with 32nd notes, with tuplets of 8, 9 or 10 notes
>> in the left hand that end together with the 32nd notes in the right
>> hand.
>>
>>
>>
>> There are a few other challenges – both for engraving and MNX definition
>> - in that piano part as well J
>>
>>
>>
>> JanR
>>
>>
>>
>>
>>
>> *From:* James Sutton [mailto:jsutton@dolphin-com.co.uk]
>> *Sent:* maandag 10 april 2017 18:09
>> *To:* Hans Vereyken <hans@neoscores.com>
>> *Cc:* Joe Berkovitz <joe@noteflight.com>; Jan Rosseel <jan@scora.net>;
>> public-music-notation-contrib@w3.org
>>
>> *Subject:* Re: Semantic layout overrides
>>
>>
>>
>> Any chance of a pdf of the score so we can see what is being discussed?
>> Or did I miss this?
>>
>>
>>
>> James Sutton
>>
>> Dolphin Computing
>>
>> http://www.dolphin-com.co.uk
>>
>> http://www.seescore.co.uk <http://www.dolphin-com.co.uk>
>>
>> http://www.playscore.co <http://www.dolphin-com.co.uk>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On 10 Apr 2017, at 16:43, Joe Berkovitz <joe@noteflight.com> wrote:
>>
>>
>>
>> Yup. I see your point, perhaps this is not a very good example...
>>
>>
>> .            .       .    .  . ...Joe
>>
>> Joe Berkovitz
>> Founder
>> Noteflight LLC
>>
>> 49R Day Street
>> Somerville MA 02144
>> USA
>>
>> "Bring music to life"
>> www.noteflight.com
>>
>>
>>
>> On Mon, Apr 10, 2017 at 5:40 PM, Jan Rosseel <jan@scora.net> wrote:
>>
>> At the risk of ping-ponging:
>>
>>
>>
>> If Chopin’s intent was to have different rhythms, then the engravings
>> should clearly show that. This would mean that the notes should not align
>> to make this clear, and then the whole example becomes a non-example.
>>
>>
>>
>> Unless we’re entering in “you-have-to-guess-what-the-composer-meant” or
>> “whatever-you-play-is-OK” land, then I see no point in having solution 2.
>>
>>
>>
>> JanR
>>
>>
>>
>> *From:* Joe Berkovitz [mailto:joe@noteflight.com]
>> *Sent:* maandag 10 april 2017 17:09
>> *To:* Jan Rosseel <jan@scora.net>
>> *Cc:* Hans Vereyken <hans@neoscores.com>; public-music-notation-contrib@
>> w3.org
>>
>>
>> *Subject:* Re: Semantic layout overrides
>>
>>
>>
>>
>>
>> The second one only makes sense if you think (from an editorial
>> perspective) that Chopin meant to have completely independent rhythms. So
>> my point is that this is something of an editorial decision, and that it is
>> possible to represent this in two different ways.
>>
>>
>>
>> I think you are siding with Hans's editorial decision regarding correct
>> playback, and that's reasonable.  I'm merely showing that there's more than
>> one way to interpret the musical text (even if one of them seems unlikely),
>> and that MNX should be able to represent both interpretations. After all,
>> Chopin could have written quintuplets in both voices. But he didn't.
>>
>>
>>
>> So we don't have to argue about how this piece of music should be played.
>> That argument would be decided by whoever decides which way this is encoded.
>>
>>
>>
>>
>> .            .       .    .  . ...Joe
>>
>> Joe Berkovitz
>> Founder
>> Noteflight LLC
>>
>> 49R Day Street
>> Somerville MA 02144
>> USA
>>
>> "Bring music to life"
>> www.noteflight.com
>>
>>
>>
>> On Mon, Apr 10, 2017 at 5:04 PM, Jan Rosseel <jan@scora.net> wrote:
>>
>> Joe,
>>
>>
>>
>> I’m going to side with Hans here.
>>
>>
>>
>> I’m assuming that the composer’s intent is that these last notes are
>> played at the same time – which is the reason why the engraving must put
>> them aligned, to exactly suggest/communicate/enforce this.
>>
>>
>>
>> Turn it around: if it’s not the intent that they are played together,
>> then there is no reason to align the notes, no?
>>
>>
>>
>> In that light, the first version gives not only a correct engraving, but
>> also allows a correct playback.
>>
>> The second version only gives a correct graphical representation, but
>> does not allow correct playback.
>>
>>
>>
>> Ergo, the first version is not only preferable, the second one is just
>> dead-wrong.
>>
>>
>>
>> I just can’t see the use case you describe for the second version where
>> the semantics do not match the engraving. What would be the point in having
>> the visual semantics differ from the playback one?
>>
>>
>>
>> Regards,
>>
>>
>>
>> JanR
>>
>>
>>
>>
>>
>> *From:* Joe Berkovitz [mailto:joe@noteflight.com]
>> *Sent:* maandag 10 april 2017 16:39
>> *To:* Hans Vereyken <hans@neoscores.com>
>> *Cc:* public-music-notation-contrib@w3.org
>> *Subject:* Re: Semantic layout overrides
>>
>>
>>
>> Hi Hans,
>>
>>
>>
>> Thanks. I think there's lots more room for discussion here, so I'll try
>> to clarify my motivation rather than argue in favor of anything :-)
>>
>>
>>
>> The intention of "offset-ref" is *not* to change the semantics at all,
>> but to say something about visual presentation only: that a given event
>> should be horizontally aligned with some other event. (It feels wrong that
>> this is not a style property, and perhaps it should be.)
>>
>>
>>
>> Thus the playback of the second version is perfectly well defined by the
>> non-visual semantics: the top voice is performed as a dotted eighth plus
>> 16th.
>>
>>
>>
>> Hope this clarifies things.
>>
>>
>>
>> Best,
>>
>>
>> .            .       .    .  . ...Joe
>>
>> Joe Berkovitz
>> Founder
>> Noteflight LLC
>>
>> 49R Day Street
>> Somerville MA 02144
>> USA
>>
>> "Bring music to life"
>> www.noteflight.com
>>
>>
>>
>> On Mon, Apr 10, 2017 at 1:12 PM, Hans Vereyken <hans@neoscores.com>
>> wrote:
>>
>> First: Big thanks to Michael, Joe and Daniel for all the hard work on
>> MusicXML SMuFL and MNX! Doing this, you are fixing problems for developers
>> in the world.
>>
>>
>>
>> After going through the proposal, I found some things I'd like to
>> discuss, this being the first:
>>
>>
>>
>> In the proposal there are two examples of how the 'Chopin-esque example
>> of a two-voice passage' can be encoded.. But they are not doing the same
>> thing, and imho, one of them is preferred..
>>
>>
>>
>> In the first example, the semantics represent the notes as they are
>> mathematically correct, with an 'appearance' attribute to 'fix' the
>> simplified appearance. So the visuals are distorted (for good reasons)
>>
>> In the second example, the semantics do not represent the notes as they
>> are mathematically correct and on top of that, we need an 'offset-ref' to
>> 'fix' the simplified appearance. So both the visuals and the semantics are
>> distorted.
>>
>> Try to imagine on how to accurately playback both examples.
>>
>> I'd like to ditch the 'offset-ref'-method of encoding this. Because it
>> enables us to encode things that don't add up in a semantic way. The
>> semantics should always represent the notes as they are, but extra 'visual'
>> information can override there appearance.
>>
>>
>>
>> example 1:
>>
>> | <measure>
>>
>> |     <sequence staff="1">
>>
>> |         <tuplet actual="5/16" normal="1/4" bracket="no"
>> show-number="no">
>>
>> |             <event value="4" appearance="8*">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |         </tuplet>
>>
>> |     </sequence>
>>
>> |     <sequence staff="1">
>>
>> |         <tuplet actual="5/16" normal="1/4">
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |         </tuplet>
>>
>> |     </sequence>
>>
>> | </measure>
>>
>>
>>
>> example 2:
>>
>> | <measure>
>>
>> |     <sequence staff="1">
>>
>> |         <event value="8*">...</event>
>>
>> |         <event value="1/16" offset-ref="n5">...</event>
>>
>> |     </sequence>
>>
>> |     <sequence staff="1">
>>
>> |         <tuplet actual="5/16" normal="1/4">
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event value="1/16">...</event>
>>
>> |             <event id="n5" value="1/16">...</event>
>>
>> |         </tuplet>
>>
>> |     </sequence>
>>
>> | </measure>
>>
>>
>>
>>
>>
>>
>>
>> *Hans Vereyken*
>>
>> Software engineer | neoScores
>>
>>
>>
>> *EMAIL* hans@neoscores.com <XXXXXX@neoscores.com>
>>
>> *PHONE* +32 (0) 4 <XXXXXX>72 52 75 59
>>
>>
>>
>> www.neoscores.com
>>
>> Facebook  <https://www.facebook.com/neoscores>| Twitter
>> <https://twitter.com/neoscores>
>>
>>
>>
>> Gustaf  More room for music.
>>
>>
>>
>> *VISITOR ADDRESS* Designcenter De Winkelhaak, Lange Winkelhaakstraat 26,
>> BE-2060 Antwerp, Belgium
>>
>> *INVOICING ADDRESS* neoScores NV, Sleutelstraat 13, BE-2550 Kontich,
>> Belgium
>>
>> *VAT* BE 0536.406.040
>>
>>
>>
>>
>>
>>
>>
>>
>>
>
>