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
>
>
>