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.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 <http://www.noteflight.com/>
> 
> On Mon, Apr 10, 2017 at 5:40 PM, Jan Rosseel <jan@scora.net <mailto: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 <mailto:joe@noteflight.com>] 
> Sent: maandag 10 april 2017 17:09
> To: Jan Rosseel <jan@scora.net <mailto:jan@scora.net>>
> Cc: Hans Vereyken <hans@neoscores.com <mailto:hans@neoscores.com>>; public-music-notation-contrib@w3.org <mailto: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 <http://www.noteflight.com/>
>  
> 
> On Mon, Apr 10, 2017 at 5:04 PM, Jan Rosseel <jan@scora.net <mailto: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 <mailto:joe@noteflight.com>] 
> Sent: maandag 10 april 2017 16:39
> To: Hans Vereyken <hans@neoscores.com <mailto:hans@neoscores.com>>
> Cc: public-music-notation-contrib@w3.org <mailto: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 <http://www.noteflight.com/>
>  
> 
> On Mon, Apr 10, 2017 at 1:12 PM, Hans Vereyken <hans@neoscores.com <mailto: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 <mailto:XXXXXX@neoscores.com>
> PHONE +32 (0) 4 <tel:XXXXXX>72 52 75 59
> 
>  
> 
> www.neoscores.com <http://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
> 
>  
> 
>  
> 
> 

Received on Monday, 10 April 2017 16:09:50 UTC