Create "MEI Go!"

[pe-ro]

It would be helpful to provide a more constrained version of MEI, comparable to TEI Lite or TEI Tite, for use in applications that don't require "full" MEI. A reasonable staring point might be a schema with only the following modules turned on --

MEI
MEI.cmn
MEI.cmnOrnaments
MEI.externalsymbols
MEI.figtable
MEI.fingering
MEI.harmony
MEI.header
MEI.lyrics
MEI.midi
MEI.ptrref
MEI.shared
MEI.tablature
MEI.text
MEI.usersymbols

Conversely, the following modules would be turned off --

MEI.analysis
MEI.corpus
MEI.critapp
MEI.edittrans
MEI.facsimile
MEI.frbr
MEI.mensural
MEI.namesdates
MEI.neumes
MEI.performance

[zolaemil]

+1

[ahankinson]

I'm all for this!

What's the justification for leaving tablature, ptrref, or harmony in there?

[pe-ro]

Now that there's a generic fingering element, tablature could go. I kept ptrref to facilitate linking -- even if it's not used in the body, it could be useful within the header. But, it could go away too. The harmony module is necessary to mark chord names (e.g., 'Cmin', etc.) and functional names (e.g., 'I', 'iv', etc.).

[pe-ro]

Beyond elimination of modules, we could also settle on a single method for encoding beams, accidentals, etc. I believe this means preferring elements over attributes in most cases and *Span elements over containers. Along with the former change, we may want to move some attributes, e.g., @beam and such on <note>, from the logical domain to the analytical one. This would make them disappear 'cause MEI.analysis would be turned off.

[kepper]

I'm not sure if I wouldn't prefer containers over spanners. This comes with some functional limitations, but the structures are much simpler (at least compared to @plist, which you would need for crossing staves).
We may also want to restrict controlEvents to either @startid / @endid or @tstamp. I believe simplicity is key here, and we shouldn't try to replace "MEI all", but instead provide a simplified solution for simple use cases. If someone wants to do more complex stuff, there's still the rest of MEI out there.

[pe-ro]

I readily agree that simplicity is the goal and that that "MEI Lite" is not a replacement for the breadth of MEI, so limiting controlEvents to @startid, @endid, or @tstamp and @tstamp2 (when available) is a good idea.

However, without either <beamSpan> and <tupletSpan> elements or the @beam and @tuplet attributes, beams and tuplets across barlines become impossible. This goes beyond mere "functional limitation". While they're useful for hand-encoding, there's nothing inherently simpler about <beam> and <tuplet>, especially in a graphical editing environment.

[kepper]

The question is how frequent barline-crossing beams and tuplets really are. I wouldn't mind to not support them, because they're probably not too common in real life. However, software which supports those cases should be able to support MEI beyond this "lite profile". I'd like to know what @donbyrd says about this…

[pe-ro]

I understand trying to limit the scope of MEI Lite, but I don't think we should allow a feature's frequency to completely dominate whether it's included in MEI Lite or not. It's more a question of handling the broadest scope with the simplest approach / smallest number of elements and attributes. Regardless of how often one might encounter barline-crossing beams or tuplets, the point is that if the *Span elements are used, a single syntax can be used. Providing only <beam> and <tuplet> forces a move to mei-CMN (with its attendant baggage) and requires a new encoding syntax. If only one method is provided, it should be the *Span one.

[donbyrd]

I'd say barline-crossing beams are fairly common from the late 19th century on, but bar line-crossing tuplets are rare in every repertory I can think of. Anyway, such beams are certainly far more common than such tuplets. In 10 minutes of flipping through the Norton Scores, 3rd edition, I see bar line-crossing beams in Brahms, Puccini, Schönberg, Ives, and Stravinsky; I don't see any bar line-crossing tuplets.

[zolaemil]

As much as I support this, I think it would be really important to be explicit about why exactly we are doing this. What are the problems we are trying to tackle?

• a subset that can be used more easily for data exchange?
• to facilitate conversion between MEI and MusicXML?
• to lower the barrier to entry in MEI?

[ahankinson]

Yes to all of the above.

I see MEI Lite as an effort to reduce some of the complexity associated with trying to learn the whole MEI schema. I can see it being immediately useful for, e.g., the Sibelius plugin, where I can have an approved subset of functionality that I can target, without worrying that I have not explored the possibilities of the whole spec.

[lpugin]

+1 for this idea too! Concerning the container vs span elements, I would be in favor of <tuplet> instead of <tupletSpan> since measure-crossing tuplets seem indeed to be quite rare. I am not sure what should be picked for the beams. I would lean towards <beam> since I see MEI Lite to be designed for simpler uses.

[zolaemil]

If we want MEI-lite to serve as a common denominator between main MEI and other formats which does not necessarily support the full functionality of MEI, then I think disregarding cross-measure beams will limit usefulness. If this is not a goal, maybe it's fine. Don't get me wrong, I do like the simplicity of <beam> and I don't think we should expel it from MEI-lite.

However, I think we have more options than choosing one element over the other exclusively. In my view, MEI-lite should embrace these principles:

1. Simplicity
2. Unambiguity

By (2) I mean that we should minimise the cases where two different encoding represent the same thing. For beams, in particular, this means that we should allow only one of <beam> or <beamSpan> in any given situation. If the rules are simple and well defined, we still satisfy both principles, while not restricting functionality:

• <beam> if all the notes are within one measure
• <beamSpan> if the notes are in more than one measure
  It could be debated whether one should use <beam> or <beamSpan> for a cross-staff, but single-measure beam, but this decision is beside my point. The important thing is that there's a simple enough rule to define the only valid encoding.

I have another example to show that exclusively opting for one attribute over the other could even result in incorrect encoding. Consider the @tstamp vs @startid question. If a dynamic marking applies to two staves, I don't see how @startid can be used effectively. In this case one really must use @tstamp combined with staff="1 2" - well, maybe there are other correct solutions too, but @startid is certainly not one of them. Therefore limiting controlEvents to @startid, @endid unconditionally is perhaps not a good idea. In the meantime, I do see the point in prescribing @startid over @tstamp for fingerings for example.

So the point, again, is to define unambiguously which solution to use in which situation. Otherwise, I think we will compromise correctness, which I don't think we should allow.

[pe-ro]

Zoltan is "dead on" here -- Simplicity and clarity should be the driving forces behind MEI Lite. Achieving these goals will require multiple actions -- reducing the number of encoding options and improving the Guidelines regarding particular situations, for example. "Correctness"; that is, conformity with "full" MEI should not be compromised, but taking a step back and re-assessing some markup practices may help improve "full" MEI with respect to simplicity and clarity. In other words, this undertaking is not simply a mechanical one; it should be an opportunity to make MEI better.

[pe-ro]

My goal for creating MEI "Lite" is to focus on simplicity and unambiguity (thanks for the terminology, Zoltan) while keeping the range of capabilities of the customization unchanged. That is, none (few?) of the notational features that MEI-all supports should be excluded. This is why I don't support providing only <beam> and <tuplet> -- doing so fits the first two goals but violates the third as it excludes cross-barline structures. What can be excluded is all the stuff that current notation software doesn't support, such as editorial markup, external digital resources (e.g. facsimile images, audio/video), repertoires other than CMN, etc. In other words, I'd like to make this customization of MEI mirror existing representations such as MusicXML (in functionality, not syntax) as much as possible. Once this is finished (or at least underway), creating other customizations somewhere between MEI-all and this one can be undertaken.

Regarding the name of this customization -- I'm not sure "Lite" is the best one as it implies that something of substance has been left out. Something will be left out, of course, but not the notational stuff. I think it would also be best to avoid the names of common TEI customizations -- "Lite", "Tite", and "Simple" -- as we don't want anyone to infer any connection between the TEI and MEI customizations. Other possible names include:

• common
• frequent
• prevailing
• prevalent
• typical
• general
• plain
• regular
• standard

[pe-ro]

Another possibility is to just make this new customization a refinement of mei-CMN.

[zolaemil]

I agree, for what you describe, lite may not be the best name. Maybe strict could be added to the list of candidates too, out of your suggestions my favourites are common and regular.

[lpugin]

What about MEI-exchange?

If the idea is not to restrict its possible use (and for example to use tupletSpan instead of tuplet), then the rule of thumb should be that elements (where available) should be used instead of attributes. That is, we should always have <keySig> and not use @key.sig in <staffDef>. Is this the idea?

I personally think that MEI-Lite should not necessary support everything in terms of notation (even in CMN) because this will make is difficult to keep simplicity. I would prefer us to agree on features to be supported. If we agree on a limit backward in time (mensural notation and older is excluded), why not forward? Or why not a limitation on specific features? Is 21st century music notation still what we call CMN? Cross-measure tuplets are a good example. It seems something pretty rare, or at least not appearing very early in music notation. Supporting them will indeed make MEI-Lite more comprehensive but certainly not simpler.

On the other hand I am aware that always choosing the most powerful encoding possibility will make the design of MEI-Lite much simpler since there is not need to discuss what needs to be supported or not (we just go for <tupletSpan>, <keySig>, etc.), so I can see pros and cons in both approaches.

[donbyrd]

I've come to the conclusion that cross-measure tuplets are a fantastic example of an unimportant piece of notation. The only piece I know of that uses them is Ives' Three Places in New England; cf. "More Counterexamples in Conventional Music Notation" (http://homes.soic.indiana.edu/donbyrd/MoreCMNCounterexamples.htm), Sec. 4k. I'm sure there are many other examples (suggestions, anyone?), but they're not just rare, they're VERY rare..

[ahankinson]

I've just updated the name to reflect the new name for this particular issue.

[bwbohl]

For general inspiration in streamlining MEI we might want to consider the MSM interim format that is used by the meico MEI to MIDI converter: https://github.com/cemfi/meico

(In the proces of converting MEI to MIDI the MSM interim-format can be saved to file; unfortnately we do not have a documentation to MSM at the moment)

meico also tries to resolve a lot of things when processing the MEI, e.g. @Dur vs. default duration, @accid.ges vs. @accid vs @keyAccid etc and might give some hints to what has to be simpified or "explicified more clearly" in MEI Go!

[pe-ro]

Thanks, Benni! We should definitely keep meico in mind when determining, as the Bob Seger song says, "what to leave in, what to leave out." :-)

[pe-ro]

See https://github.com/music-encoding/mei-basic-doc for the MEI Basic profile and documentation.