[MEI-L] Page-based encoding

Tue Nov 5 03:14:06 CET 2013

Reading this discussion caused me inadvertently to think of a few
repertories that might be flipped in other ways:

1.       Benedetto Marcello psalm settings based on music from Hebrew
liturgy.  He attempted to render the music right to left.  As you can see,
a  modern rendering introduces lots of complexity to the process of
character formation.

2.       Calvinist psalters used in Turkey (current research by a young
German colleague), where the nature of the text has features similar to,
but not exactly the same as, those in Marcello, such as text underlay in
Turkish script. 

Granted MEI is not likely to be called upon to deal with these kinds of
cases in the foreseeable future, but since flippability is under
discussion, it may be worth thinking about the general issue of
extensibility at every tier-notes, lyrics, staff, system.

Best regards,

Eleanor

Eleanor Selfridge-Field
Consulting Professor, Music (and, by courtesy, Symbolic Systems)
Braun Music Center #129
Stanford University
Stanford, CA 94305-3076, USA
http://www.stanford.edu/~esfield/  +1/ 650 725-9242

From: mei-l [mailto:mei-l-bounces at lists.uni-paderborn.de] On Behalf Of
Laurent Pugin
Sent: Saturday, November 02, 2013 12:42 AM
To: Music Encoding Initiative
Subject: Re: [MEI-L] Page-based encoding

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131104/74358e3d/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.jpg
Type: image/jpeg
Size: 29183 bytes
Desc: not available
URL: <http://lists.uni-paderborn.de/pipermail/mei-l/attachments/20131104/74358e3d/attachment.jpg>