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
>