<div dir="ltr">Hi Raffaele,<div><br></div><div>Thanks for you comments, more below</div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Oct 31, 2013 at 8:52 PM, Raffaele Viglianti <span dir="ltr"><<a href="mailto:raffaeleviglianti@gmail.com" target="_blank">raffaeleviglianti@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi Laurent, thanks for sharing this, a few comments:<div><br></div><div class="gmail_extra"><div class="gmail_quote">
<div class="im">On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin <span dir="ltr"><<a href="mailto:lxpugin@gmail.com" target="_blank">lxpugin@gmail.com</a>></span> wrote:<div>
</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal"> </p>
<p class="MsoNormal">1) For the document structure to be encoded, we need to have
page and system elements. The content of a score becomes a list of /page. Each
/page contains a list of /system. In un-measure music /system contains a list
of /staff. In measured music, we can imagine a) /system containing a list of
/staff containing a list of /measure (and then /layer), or b) /system
containing a list of /measure containing a list of /staff. Solution a) seems
more natural to me (if we think how music is written on paper, we first have
staves and then add measure). Solution b) has the advantage of being closer to
the standard MEI focusing on content. This needs to be discussed.</p></div></blockquote><div><br></div></div><div>It makes sense that when the page hierarchy is flipped, the system hierarchy gets flipped as well, so that you can encode layout data on systems too. Though I don't think the same logic applies to staff and measure so I'd be tempted to go with b), because it would make switching between a page-based encoding and a "standard" encoding easier. </div>
</div></div></div></blockquote><div><br></div><div>I think this is the most difficult thing to decide. Your point makes sense and it would indeed make it easier to adopt. Any other opinion on this? Shall we have both options?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal"> </p>
<p class="MsoNormal">2) For the positioning, we need to add attributes the
elements that can have a position. Basically, any element with the @facs. We
can solve this by making the att.facsimile class member of att.coordinated.
This provides us with the necessary @ulx, @uly, etc. for specifying the
position. We also need to specify to which image the position refers to. A
simple approach is to add a @surface to /page. As mentioned before, all this
does not preclude to use the standard @facs and facsimile tree scheme at the
same time, for example if a higher resolution image needs to be added for
specific elements. We also need to have a @unit in /page and presumably also be able to specify if the positioning is absolute or relative.</p></div></blockquote><div><br></div></div><div>+1. Those would be good to have around even outside of a page-based module, I think.</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr">
<p class="MsoNormal"> </p>
<p class="MsoNormal">Another point to be discussed it if we want to keep this in
the score subtree or if such encoding could be put into another subtree. One
option would be a /pages element at the same level of /parts and /score. In
other word, this would be a third representation option in MEI.</p>
<p class="MsoNormal"><br></p></div></blockquote><div><br></div></div><div>Yes, I'd keep it in a different subtree, so that content can be linked in the same file if necessary.</div></div></div></div></blockquote><div>
<br></div><div>I agree. I do it for the next version of the customization.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><br></div><div>In general: I see why this approach to encoding is useful, though if we make it part of MEI, we should make quite clear when it's ok to encode in page-based fashion and when it's not. Basically we should discourage this approach unless it's required for specific (scholarly, justifiable) reasons. </div>
</div></div></div></blockquote><div><br></div><div>Agree too. I am sure people won't use it unless necessary ;-)</div><div><br></div><div>Laurent</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">
<div><br></div><div>Raf</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">
<div dir="ltr">
<p class="MsoNormal"></p><p class="MsoNormal">I already made a customization for unmeasured music and I am willing to do one for measured music for option a) or b) and when we agree where to put it. The sample file attached for unmeasured music was generated from the OMR output of Aruspix.</p>
<p class="MsoNormal"><br></p><p class="MsoNormal">Best,</p><p class="MsoNormal">Laurent</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
</div>
<br></div>_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de" target="_blank">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br></blockquote></div><br></div></div>
<br>_______________________________________________<br>
mei-l mailing list<br>
<a href="mailto:mei-l@lists.uni-paderborn.de">mei-l@lists.uni-paderborn.de</a><br>
<a href="https://lists.uni-paderborn.de/mailman/listinfo/mei-l" target="_blank">https://lists.uni-paderborn.de/mailman/listinfo/mei-l</a><br>
<br></blockquote></div><br></div></div>