[MEI-L] Page-based encoding

[Laurent Pugin]

Hi Raffaele,

Thanks for you comments, more below

On Thu, Oct 31, 2013 at 8:52 PM, Raffaele Viglianti <
raffaeleviglianti at gmail.com> wrote:

> Hi Laurent, thanks for sharing this, a few comments:
>
> On Tue, Oct 29, 2013 at 11:02 AM, Laurent Pugin <lxpugin at gmail.com> wrote:
>
>
>>
>>
>> 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.
>>
>
> 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.
>

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?


>
>
>>
>>
>> 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.
>>
>
> +1. Those would be good to have around even outside of a page-based
> module, I think.
>
>
>>
>>
>> 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.
>>
>>
>>
> Yes, I'd keep it in a different subtree, so that content can be linked in
> the same file if necessary.
>

I agree. I do it for the next version of the customization.


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

Agree too. I am sure people won't use it unless necessary ;-)

Laurent


>
> Raf
>
>
>
>>  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.
>>
>>
>> Best,
>>
>> Laurent
>>
>>
>>
>>
>>
>> _______________________________________________
>> mei-l mailing list
>> mei-l at lists.uni-paderborn.de
>> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>>
>>
>
> _______________________________________________
> mei-l mailing list
> mei-l at lists.uni-paderborn.de
> https://lists.uni-paderborn.de/mailman/listinfo/mei-l
>
>
-------------- section suivante --------------
Une pi?ce jointe HTML a ?t? nettoy?e...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131102/4d2cb2af/attachment.html>