Re: MEI Customisation

Hi Zoltan, All,
> I encourage you to post your questions to MEI-L for further discussion.
I'm going to do just that.
Think of this as the way the last round of discussion ended here: We all 
go off and work on our own for a bit.

Currently, I don't see the consensus that would be necessary for 
promoting this Contact Group to a W3C Working Group, so I think MNX 
should be put on hold until such a consensus can be reached.

I'll report back here in due course.

All the best,
James

Am 24.05.2016 um 15:34 schrieb Zoltan Komives:
> Hi James,
>
> Thanks for your questions! These kind of discussions are normally best 
> placed on the MEI-L mailing list, but I am happy that questions like 
> this are of interest in this group too.
> In answer to your questions:
> 1. In short, yes. Slightly longer: MEI separates logical from gestural 
> domain information. In this case I think @dur.ges is the attribute you 
> are looking for. This can express duration in a number of different 
> absolute units, including seconds (to floating point precision). In 
> MEI by default, no restriction applies to the symbolic or temporal 
> length of layers, but it would certainly be possible to impose such 
> restrictions if they are practical and required.
> 2. As far as I understand your point, this is basically already 
> implemented by the customization "hierarchy": mei-all allows all 
> possible symbols and modules with the least amount of restrictions, 
> while mei-cmn, mei-Mensural, and mei-Neumes define subsets.
>
> I encourage you to post your questions to MEI-L for further discussion.
>
> Zoltan
>
>
> On Tue, May 24, 2016 at 12:34 PM, James Ingram <j.ingram@netcologne.de 
> <mailto:j.ingram@netcologne.de>> wrote:
>
>
>     Hi Zoltan, All,
>
>>     Tido's recently published MEI customization
>>     <http://tido.github.io/mei-customization/> sparked a lively
>>     discussion...
>     and
>>     For more information on MEI Go! please keep an eye on the MEI-L
>>     mailing list for updates
>>     <https://lists.uni-paderborn.de/pipermail/mei-l/2016/001796.html> and
>>     discussions. While it may not be the solution that the Community
>>     Group is looking for, I would like to draw attention to this
>>     effort as point of reference.
>
>     I joined the MEI-L mailing list yesterday.
>     MEI customization <http://tido.github.io/mei-customization/> says
>>     *We hope that this customisation can also be the starting point
>>     for a common basic MEI customisation* to be shared between
>>     several projects in future. We welcome comments and suggestions
>>     through GitHub issues.
>     I've decidedto post my comments and suggestions (questions
>     actually) here, rather than on GitHub. Please repost there and/or
>     to MEI-L if you think that's a good idea.
>
>     I'm a beginner with MEI customisation, and need some help:
>
>     Briefly: My problem with current encodings of CWMN is that they
>     all assume that duration symbols have fixed meanings in a score,
>     and that measures therefore "add up" at the symbol level. This
>     ignores the performance practice tradition that is always
>     associated with any humanly readable notation. In Mozart, for
>     example, the last quaver under a slur is never played in the same
>     way as the first. Ignoring performance practice traditions goes
>     back at least to the invention of the metronome in the 19th
>     century. I'm old enough to remember how awful the first computer
>     renditions of Bach sounded in the early 1980s...
>     I also think that the famous collapse around 1900 had more to do
>     with the disintegration of fixed tempi, than with the exhaustion
>     of harmonic possibilities. The notation collapsed because the
>     conventions make no sense in the absence of humanly perceptible tempo.
>
>     Whether this analysis is correct or not is, however, immaterial. :-)
>
>     I want to make an MEI customisation that uses most of the symbols
>     that are used by CWMN, but without assuming tempo. If there is no
>     tempo, then neither tuplets nor grace-notes make sense. It should
>     also be possible for the description of /more than one/ temporal
>     instantiation to be stored inside the XML elements that represent
>     the score's graphics.
>     I think that CWMN (as defined by both MusicXML and your project)
>     could be regarded as a superset of such a customisation. If the
>     /default/ temporal realisation of such a score defined all the
>     duration symbols to have fixed meanings, then <measures> could be
>     made to add up at the symbol level by adding tuplet symbols (as
>     annotations) and turning some notes into grace-notes.
>
>     One advantage of having a tempo-less customisation would be that
>     lossless transcriptions of recordings can be made, without going
>     through "quantisation". I /compose/ with milliseconds...
>
>     So my initial questions are:
>     1. Can <measure> elements be redefined so that they do not have to
>     add up at the symbol level? The different <layer>s in the measure
>     must however add up in real time (milliseconds) in any one
>     temporal realisation stored in the score.
>     2. Can you imagine such a hierarchy of customisations? I'm also
>     thinking of the container hierarchy that could become part of the
>     W3C standard for describing /any /polyphonic music notation.
>
>     All the best,
>     James
>
>     -- 
>     http://james-ingram-act-two.de
>     https://github.com/notator
>
>
>
> www.tido-music.com <http://www.tido-music.com>
>
> Tido (UK) Ltd, 2–6 Baches Street, London N1 6DN, United Kingdom. 
> Disclaimer: The information in this e-mail including any attachments 
> is confidential and may be legally privileged. If you have received 
> this message in error, please contact the sender immediately and 
> delete this message and any copies from your computer and network. The 
> unauthorized use, distribution, copying or alteration of this e-mail 
> and any attachments is strictly forbidden.


-- 
http://james-ingram-act-two.de
https://github.com/notator