Re: Pömmelchen

Hi Joe,

I would say that your question takes an approach quite different from MEI's. In MEI, we would first ask about the purpose of the encoding. If your intention is to render the thing again, why not use the original scan in the first place? If you want to talk about the semantics, we're talking about a quite different encoding. There is some overlap between the two approaches, and one may even try to put everything in one single encoding, but those are all different things, and by not being specific about the purpose, it's easy to not get what you want.

Actually, my impression from this whole discussion is that people have very different expectations and motivations for MNX, and without a clarification of its mental model, it seems impossible to proceed. I'm aware that you're trying to get there, but it doesn't seem to get through. In my experience, music encoding should not be modelled with a specific application in mind, but instead should try to replicate the concept inherent to the music as closely as possible. This concept clearly differs between repertoires, and even CMN is way less standardised than we all would like it to be. Of course such an encoding might be harder to support in an application, but I wonder how clever it is to develop an application that contradicts its subject?! (and yes, measures are an inherent part of CMN…).

I believe it's this type of thinking about edge cases in music notation that Andrew mentioned as being better addressed by MEI (compared to MusicXML – MNX is not mature enough to tell, I'd say).

All best,
Johannes

> Am 04.04.2017 um 23:16 schrieb Joe Berkovitz <joe@noteflight.com>:
> 
> Hi Andrew,
> 
> On Tue, Apr 4, 2017 at 4:56 PM, Andrew Hankinson <andrew.hankinson@gmail.com> wrote:
> Of course, complex non-standard Western  music notations and semantic musical structures are probably better suited to the flexibility that MEI provides, so there is always that representational option as well.
> 
> I think you are comparing MEI with an approach that hasn't been worked out here yet. So the "of course" feels a bit hasty to me.
> 
> I do in fact believe that MEI can represent these sorts of examples with some combination of its elements. The problem is, guaranteeing that applications will interpret those combinations in a way that reproduces the original. When flexibility applies to implementors as well as encoders, all bets are off.
> 
> Do you have an encoding of Alex's example and an application that will render that encoding? (I don't, but I'm not making any claim that we have a solution to the problem yet :-)
> 
> ...Joe