Can we improve MNX score content names

[joeberkovitz]

@mscuthbert wrote:

btw -- am I the only one who has trouble following what all the MNX beyond simple MNX mean? Would it be better to call them "MNX-Classical" "MNX-Graphic" etc.?

[joeberkovitz]

The acronyms are unwieldy and I personally don't love them. But I can explain my view of how they were proposed:

• We wanted to avoid using the term "Classical" to refer to CWMN, since it covers a much broader set of idioms than classical music. And calling it MNX-CWMN seemed to repeat "MN" in an objectionable way.

• The term "Graphic" seems like it could work, except that #67 does seem to begin to point at GMNX being about instantiations of any kind, not just graphical ones.

[clnoel]

As I replied in #25: It's my understanding that GMNX is "General" MNX (not "Graphical"), meant to be a scheme by which ANY music score could be visually and audibly reproduced, regardless of culture of origin. This will by nature likely have a heavy graphical component.

Perhaps, to avoid confusion on that last bit, we rename it GenMNX? It's just as fast to pronounce and moderately clearer in meaning.

[joeberkovitz]

+1 on that direction @clnoel.

[mscuthbert]

+1 on Gen. I’d like to propose having MNX first and then the subtype after so MNXGen or MXN-gen or something like that. If for no other reason than in an alphabetical list of formats that software supports all the MNX dialects will be grouped together:

E.g.: (Making up future MNX dialects) ABC Enigma MEI MIDI MNXchant MNXcw MNXgen MNXtibet MusicXML NoteworthyXML

Rather than having them scattered.

[clnoel]

+1 @mscuthbert .

You're right. That's better. It also better emphasizes that these are siblings in a family, with the fact that they are all MNX being more important than their differences. I prefer the hyphenated approach, though.

MNX-CW, MNX-Gen, MNX-Chant, MNX-Modern

I think it reminds me of the language specifiers: "en-us" means English, US-Style. "MNX-CW" means "Music Notation X, Common Western Style". I'm flexible here, though, if others have strong opinions.

Though the X doesn't mean XML these days, necessarily, but more like "neXt". I definitely don't want to drop it though. :)

[clnoel]

Ooh... X for "eXchange"!!

Christina

[joeberkovitz]

We do also need to think about how this nomenclature will map onto element names in the schema.

At the moment we have musical body elements like <cwmnx> and <gmnx>, which are either children of <score>, or provide the root element of a standalone document included via <score src="..."/>. These could potentially be renamed as <mnx-cw>, <mnx-gen> if the above proposal flies.

[mscuthbert]

I think that the choice of hyphen or lowercase or nothing or whatnot will likely come down to what is allowed inside xml:ns tags to be a valid namespace. But any of these would be acceptable to me, and the hyphen is very legible.

And i'm also super +1 on X for exchange. (As someone said recently about the acronym "AJAX" -> A stands for "asynchronous", JA stands for "javascript", X stands for "JSON". :-) )

[joeberkovitz]

namespaces may contain hyphens: https://www.w3.org/TR/REC-xml/#NT-NameChar

[notator]

The local name given to a namespace is really only an alias for its URI. To explain that a bit: Every namespace is uniquely identified by its URI. In the case of CWMN, we could freely define the URI as something like "http://www.someWebsite.de/cwmn.html" (whereby the file might or might not actually exist). Individual SVG files declare their own local alias for this URI in the namespace declaration. In the Faure example, I used xmlns:cwmn="http://www.someWebsite.de/cwmnNamespace.html", but I could have saved a key kilobytes by using xmlns:c="http://www.someWebsite.de/cwmnNamespace.html". Its important to be able to define the local alias' name freely, in order to avoid namespace conflicts in future. So I dont think it would be a good idea to take local alias names into account when defining names that are to be used outside the file. On the other hand, it would be a very good idea to keep all the external names consistent with the (freely chosen) name of the file in the namespace's URI.

[bhamblok]

When reading all those potential MNX-variants, I wonder how we can embed all those different variants, nested, into each other, into one composition. I could imagine a composer is making a composition in which one part complies with MNX-CW, some other parts/instruments comply with MNXtibet (but maybe only after point x in time) and at the same time other parts are playing in MNX-Gen ;-)

[joeberkovitz]

@bhamblok That's the purpose of the MNX container-level markup: to describe how these different components are embedded or combined.

As @notator pointed out, local alias names aren't really significant to an implementation: an encoder can pick anything they want to use as a namespace alias. It does help to have familiar, conventional aliases, though :-)

I think we'll need to have a separate conversation soon about whether and how namespaces are used to differentiate the various bits of MNX - this naming business can come first.

[joeberkovitz]

The chairs decided yesterday to promote this to Active Review in the interests of making a name change sooner rather than later, since this affects the quality of discussion.

We like the hyphenated scheme, and propose that the names of the existing components of the spec be changed as follows:

"MNX Container" -> MNX-Container (top level element would still be <mnx>) "CWMNX" -> MNX-CW (top level element <mnx-cw>) "GMNX" -> MNX-Gen (top level element TBD, pending resolution of #58 and #67).

The name change does not imply any change of scope or meaning for these terms.

[jsawruk]

I think that the names are too terse; you need to know what "CW" means, and I don't think that's a common abbreviation. I propose the following:

• MNX-General OR MNX-Generic
• MNX-Common OR MNX-Western OR MNX-CommonPractice

or variations thereof. Just a suggestion to improve readability and communicating.

[mscuthbert]

I don't think many medievalists would object to calling MNX-CW MNX-Western; MNX-CommonPractice seems too long to have to read in prefixed tags (yes, I know they can be aliased to anything we want, but in practice people don't). But I'm also okay with MNX-CW or anything. For MNX-Gen, I'm okay with leaving it as is since reading it as -General or misreading it as -Generic describes its purpose well (it's unlikely anyone will think it means MNX-Geneology)

[fablau]

I like the new changes @joeberkovitz

[jsawruk]

<mnxCw> looks odd to me since CW usually appears as uppercase. I would prefer <mnx-cw> in this case, or any of the variants that use Western instead of CW.

[clnoel]

@joeberkovitz, It's slightly off-topic, but if, as indicated here, the collection element is supposed to be able to group different representations of the same music from different mnx variants, then that should be one of the allowable collection types. Right now, we just have movements, sections, and parts. I suggest "presentation" for this type, as it's presumably the same audible music with different associated semantics (and possibly different visuals), but I'm flexible as far as that goes.

[CBoensel]

Even though the current proposal of <mnx>, <mnx-cw>, and <mnx-gen> is a huge improvement in terms of readability already, I agree with @jsawruk that getting rid of the abbr would make it even less cryptic. My favorites would be <mnx-generic> and <mnx-common-western>. The meaning of the tag-name would even make sense to people without any mnx-specific knowledge.

As I see it, it is very unlikely someone entering the markup manually. Supposing the format being computer-written and computer-parsed, with humans inspecting the xml encoding rather rarely, I don't see any necessity to keep it short. Especially since I anticipate this will be zipped similar to music xml, so file size wouldn't be an issue with the longer tag-names, right?

[clnoel]

Good point @cboensel. I had been leaning towards the shorter tags because I was anticipating typing into these forums over the next year and really not wanting to type out MNX-CommonWestern each time. However, that's a short period of time compared to how long we'll (hopefully) be using this standard and its variants.

Modern programming practice is usually to dump abbreviated variable and function names (e.g. sprintf) in order to save later programmer time by using the names to completely and accurately describe what the variable and function is supposed to do and represent (String.Format). Therefore, I second the opinion that we do <mnx-generic> and <mnx-common-western> in the MNX files themselves. And similarly, if we later have the option of an abbreviated, obscure element name or a longer, descriptive one, we choose the descriptive one.

The documentation surrounding these tags should probably represent this as well, and have MNX-Generic and MNX-CommonWestern as official names, with the understanding that we in the community are likely to abbreviate them to MNX-Gen and MNX-CW most of the time while typing and talking to each other in order to save our own time.

[jsawruk]

I really like the <mnx-generic> and <mnx-common-western> proposals as well. As @clnoel pointed out, my reasoning for longer names was the convention of more readable names (within reason). Clearly <xml> is better than <extensible-markup-language>, but I think the two tag names proposed here strike a good balance between being descriptive without being too long.

[mogenslundholm]

The name of the game? Do we need abbreviations? Do we need X? I think that e.g. MNS meaning Music Notation Standard (CWMNX) and MNE meaning Music Notation Extension (GMNX) would be better. But why not simply "MusicNotation" or "MusicData"? Is there a hard division between CWMNX and GMNX? I mean: If a file contains GMNX-stuff, then is it GMNX. If it contains only CWMNX-stuff, then it is CWMNX. But it could still be just "MusicData" with the file-extension ".musicdata". And "www.musicdata.com" be a place for common information. If the domain-name is still free today.

[mogenslundholm]

By the way: Western? I know I said this before - but why Western Notation? Consider the attached image. In the top you see "Hamparsum Notation" (Hamparsum notasi), next you see "Western Notation". The third example is also "Western Notation" - rather old. In the botton you see music data in form of MusicXML. It is not "Western Notation". It is up to the notation program to decide if this shall be shown as Harparsun-, Western- or Mediaval-Notation.

Sources: https://silpayamanant.wordpress.com/alt-strings/resources/scores/near-eastern-middle-eastern/ Codex Runicus Kemal Karaosmanoğlu. A Turkish makam music symbolic database for music information

[jsawruk]

@mogenslundholm: We are proposing either "Western" or "Common Western" as a shorthand for "Western Music Notation of the Common Practice Period". The two other examples you provide are not Western music notation of the common practice period; they could be encoded in GMNX or some other specialist MNX format, but not in CWMNX.

If a file contains GMNX-stuff, then is it GMNX

This might not always be true. For example, I could have an HTML file that contains both GMNX data and CWMNX. Using a single file and/or its extension is insufficient in such a scenario. This is not just a hypothetical: I really want to be able to display CWMNX within an HTML file, and I believe others want GMNX to also display this way.

But why not simply "MusicNotation" or "MusicData"?

This is an extremely valid argument. We are currently using MNX as a name to distinguish it from MusicXML. We don't have any other name at the moment, but I think it is important to consider names other than MNX which may be less cryptic.

Is there a hard division between CWMNX and GMNX?

My understanding is that yes, there is a hard division between the two. CWMNX has very strong semantics (e.g. "this item is a quarter note C4 with a staccato") that GMNX lacks ("this item is some graphic element that corresponds to this timecode"). The GMNX may display the exact same thing as the CWMNX, but CWMNX has more semantics.

[notator]

I also quite like <mnx-generic> and <mnx-common-western>, but there's an interesting asymmetry here that affects the consistent use of the names in contexts outside the MNX Container:

As the successor to GMNX (according to the official definition in §6 of the current Draft Specification) <mnx-generic> contains no semantic information, so there's no point in trying to use the name as the name of a namespace in an SVG containing "generic music notation".

In other words, we can define xmlns:cwmn="http://www.someWebsite.de/mnx-common-western.xsd" because there are semantics that can be put in the file's namespace, but there's no point in defining xmlns:generic="http://www.someWebsite.de/mnx-generic.xsd" because there are no semantics to add to the file.

We now know, that it would, by analogy to xmlns:cwmn="http://www.someWebsite.de/mnx-common-western.xsd" be perfectly feasible to define semantics for notation types like xmlns:hmp="http://www.someWebsite.de/mnx-hamparsum.xsd", xmlns:byz="http://www.someWebsite.de/mnx-byzantine.xsd", xmlns:ag="http://www.someWebsite.de/mnx-ancient-greek.xsd", xmlns:mnt="http://www.someWebsite.de/mnx-text.xsd", etc,

So its not really a question of either <mnx-generic> or <mnx-hamparsum>, <mnx-tibetan> etc.. It should be possible to have them all. <mnx-generic> might indeed be useful in some circumstances, but it is never going to be able to support all the use-cases that depend on a knowledge of a notation's semantics.

I think what's really needed is some way to allow new notation (=semantics) definitions to be added consistently to the naming scheme (and to the MNX Container, if it exists).

---

Note that it might be better to drop the mnx- from the above namespace names, and just put them all in the same directory, like so: xmlns:cwmn="http://www.someWebsite.de/mnx/common-western.xsd", xmlns:hmp="http://www.someWebsite.de/mnx/hamparsum.xsd", xmlns:byz="http://www.someWebsite.de/mnx/byzantine.xsd", etc. Is that also true, when the notations are in the MNX Container? Do we really need the mnx- for elements that are already inside an <mnx> element? Possibly, the mnx- is only really necessary (e.g. <mnx-common-western>) when that's the root node of a stand-alone file.

[joeberkovitz]

Naming discussions are always lively!

@clnoel: the collection issue that you raised is already noted as #58 (Need to model alternative renditions of scores). Let's carry on that discussion over there. We may need to promote that item to active review pretty soon since it's pretty fundamental.

@notator and others: I have broken out new issue #77 (Role of XML Namespaces in MNX) since namespaces are a really important topic, and we should discuss it independently of any changes in the "logical names" to the various bits of MNX. We'd need to figure that out even if we stuck with the old CWMNX/GMNX names. The chairs recognize the need for a clear extension mechanism for other semantic dialects as you propose, whether namespaces are part of it or not. (Personally, I think namespaces are probably needed, but the group and the chairs have barely grazed this subject.)

@mscuthbert: Given that you like "MNX-Western" in spite of its omitting "Common", it seems relevant for me to out you to the CG as an actual medievalist :-)

[clnoel]

Given @mogenslundholm's confusion about what we mean when we say "Western", I don't think we can drop the "Common" off of our descriptor.

As a side note, MEI drops the "Western" and uses "CMN" for "Common Music Notation" to describe the portion of it's spec used to encode "Western Music Notation of the Common Practice Period." I dislike CMN, too, because it's too Euro-centric for what we are trying to do here.

From what I've been seeing here, "CW" is too short and unclear, "Common" and "Western" are too imprecise.

If we want to clarify better than "MNX-CommonWestern", then I maybe we could use "MNX-WesternCommonPractice". But I still think that "MNX-CommonWestern" is the best option.

The question about whether to keep the X is important. I think it's kind of necessary to have something more than MN (for Music Notation), since that is too vague to describe what we are doing, which is creating a format by which we can represent music in machine readable and presentable fashions. I happen to like X for eXchange, and I'd also be okay with E for encoding (like MEI), but we need something!

[joeberkovitz]

Note: this issue is not about renaming MNX overall. At this point the moniker has pretty much stuck out there in the world. This issue is about how to name MNX's components (and I think we're gathering some great input from the CG on that point).

[notator]

@clnoel, @joeberkovitz and others. This posting is informative. Its probably unlikely to affect the name we choose for CWMN since that is so deeply entrenched, but I thought I'd post anyway.

It suddenly occurred to me that "Western Music Notation of the Common Practice Period." is pretty vague about what "the Common Practice Period" is, and that we could, theoretically, narrow CWMN down to the notation that was available to Romantic composers (western or otherwise) at the beginning of the 20th century. In other words: after the invention of the metronome and (nested) tuplets. So, as far as I'm concerned, CWMN could be called "Romantic" notation.

The 20th century's notation problems begin with the end of the Romantic period, and the collapse of CWMN's underlying space-time assumptions. (This is the time of Einstein's famous paradigm change.) Also, mechanical recordings replaced the metronome during the course of the 20th century... Its a long story.

This is not the place to debate these - perhaps rather idiosyncratic - ideas. I just wanted to put "Romantic" on the table -- and to point out that there's no way to guarantee that MNX-CommonWestern is always going to be the most commonly used (Western) notation. However, I won't be too bothered if you decide go for a variant of "CWMN" after all! :-)

[mscuthbert]

This would seem to be a very narrow vision for what this notation could do. So baroque ornaments disappear from the spec? Chord symbols and Roman numeral support, gone. Support for microtonal accidentals and niente dynamics -- bye. It seems to be a rather narrow idea of what is generally used in common music notation.

In my seminar on notation (as a concept, practice, and history) the most frequently occurring terms we saw in the literature for the things we've talked about were "Common Practice Music Notation" "Western Common Music Notation" "Common Music Notation" and "Western Music Notation". Western was one of the most divisive terms: some authors writing about other notations of the world liked to see it used because it is an acknowledgement that this is just one of the many notations used world-wide. Other non-Western writers disliked it (preferring Common Music Notation) because it seemed to imply that it was a notational system that was not available to them to use, expand, and contribute to the history of. My thought is that of the many difficult terms to choose from "Common Music Notation" is as neutral as we're going to find -- like C.E. (Common Era) -- it leaves deliberately vague what is "Common" about it -- is it commonly used (undoubtably the most commonly used notation today worldwide)? Is it short for "Common practice"? Is it "common" in the sense that it is a low form that people coming from different traditions can use to communicate some ideas across traditions while loosing the nuances of either? So "Common" would be my preferred term, but "CommonWestern" or even "Western" is acceptable.

[jsawruk]

You are correct that "Common Practice Period" is ambiguous, but I think "Romantic" is far more limiting. Music notation is constantly evolving: "Common Practice Period" is a larger time span, and covers more notation than "Romantic". For example, I am not sure that jazz lead sheets would be considered "Romantic".

Might I suggest "Common" or "Contemporary" (although that is certainly ambiguous as well) instead?

@mscuthbert just replied as I am typing this; I agree with everything he said.

[clnoel]

Disclaimer: I have never been formally educated in Music Theory or History. What I've got to work with is what I learned as part of taking years of piano classes during adolescence, generic history classes in high school and college, and the bits and pieces that I have picked up as a practical necessity to do my job as a programmer of music-performing and music-editing software for Musicnotes. Which covers a lot more theory and almost no more history. Please correct me if the statements I make below are inaccurate or incomplete. I have no objection to learning!

Therefore, I looked up "Common Practice Period" on Wikipedia, and found that it supposedly covers 1600-1920 Europe and the Americas, with vague boundaries around the times, and some adoption by artists from other countries. It DOES cover tablature, although using tablature for guitar did not really become popular until very near the end of that period. It does NOT technically cover "lead sheets" which is a 20th century jazz formulation (although lead sheets are usually written with the melody and chords recognizably in the Common Practice Period notation). I was unable to determine when it became usual to indicate guitar chords above the staves (either as letters or as chord frames).

I mention the above specific cases because a good deal of Musicnotes' business is Piano-Vocal-Guitar, Guitar TAB, and lead sheets. And because it was my understanding that CWMNX (whatever it will be named) was going to be able to represent each of those. I don't want the naming to get in the way of what will be included in the spec as we move forward, and I really don't want to have to encode two different import/export utilities in order to capture PVG and lead sheets as well as orchestral scores.

The problem I have with "Contemporary" is that as time goes on, "Contemporary" is going to get more and more inaccurate, since the year 1900, and even 2000, is going farther and farther into the past. "Common Practice Period" at least has a beginning and end, even if they are vague.

My suggestion is now that we use MNX-CommonPractice as a name, even if we are not going to stick to the notations developed during the exact defined time-limit and geographic area in order to meet the needs of modern music exchanges of newly written pop songs, movie scores, and instrumental compositions that still use that time-period's notations as their expected format.

--Christina

[jsawruk]

@clnoel Thank you for your reply. Your detailed descriptions are exactly why I felt that @notator's suggestion of "Romantic" was far too limiting. I am fine with Common or CommonPractice. My suggestion of "Contemporary" is ambiguous (as I noted), and only offered as a rhetorical counterpoint to @notator's suggestion of "Romantic". Contemporary COULD be used, but I think Common or CommonPractice is better.

Whatever name we agree on is less important than the meaning we assign to that name. I think the group as a whole is converging on either Common or CommonPractice; I have some preference for the latter.

[notator]

@clnoel Thanks also for your constructive reply.

I looked up "Common Practice Period" on Wikipedia, and found that it supposedly covers 1600-1920 Europe and the Americas

It looks to me as if CWMN is currently a mammoth catch-all, containing anything and everything any composer might have tried out in the given period. Maybe we should consider splitting CWMN into a few meaningful sub-formats. These could use many of the same symbols, but with different semantics. That might encourage the writing of more modular software. An editor for notes inégales should not have to cope with Ferneyhough.

I think such specializations might, like typefaces, simply be called after representative composers or schools: Rameau, Bach, Brahms, Classic, Romantic etc.. This naming scheme would just be an extension of the scheme already proposed for non-Western notations. This generalizes both backwards (Notre-Dame, Palestrina, deVitry etc. might be defined), forwards to incorporate semantics that have yet to be defined, and sideways to non-Western cultures (Okinawan-Sanshin, Hamparsum, etc).

Care would, of course, have to be taken to prevent undue standards proliferation -- but (especially depending on the answer to #77) that might not be as serious a problem as it seems at first sight. Software that currently purports to support CWMN could quite easily support its subformats.

Can CWMN be split up into meaningful parts/eras that are characterised by their notational semantics, or am I just opening a can of worms here?

This issue relates to (at least) #58, #68 and #77.

[jsawruk]

It looks to me as if CWMN is currently a mammoth catch-all, containing anything and everything any composer might have tried out in the given period.

While CWMN is a large catch-all, I do not think it necessarily needs to capture every semantic nuance.

How do we define what is CWMN? However we (the group) decide to define it. There will always be an editorial hand in determining what this standard covers, but since it is an open process, everyone will have their say and hopefully we can reach a good compromise.

That being said, your comment about sub-formats is well within the broader scope of MNX. While I personally don't think we need that level of detail (i.e. by specific composer), I believe that MNX can support those formats if needed. I am not sure if these sub-formats would be part of CWMNX or MNX; perhaps this is a good case for namespaces #77 ?

[notator]

@jsawruk I think we agree that the number of sub-formats (if they exist) should be kept to a minimum. Its a question of code re-use and maximum interoperability.

To this end, the sub-formats should be designed around their semantic differences. It may well be possible to organise those in a kind of tree structure. Here's a little meditation on the subject:

A large number of (monophonic) notations simply consist of event symbols arranged in lines on a page, like words in ordinary text, but with each symbol being a 2-dimensional object, not just a 1-dimensional series of characters. So I think we might begin with the classifications diagram, monophonic and polyphonic. (A diagram would simply be a collection of event symbols that dont have a time-sequence.)

Then come the meaningful ancilliaries. Things like figured bass or articulation marks. Can these be classified as such, without restricting their meanings? Maybe all that's needed is a place to put the ancilliary's name, and the event symbol's meaning, rather than insisting that either should be anything in particular.

A guiding principle that I've always found useful, is to make an extremely sharp distinction between space and time in music notation. The graphical (spatial) aspects of event symbols should be kept hermetically sealed off from their (temporal) meanings. All such relationships are purely conventional, and are stored in people's minds. People (and applications) have to learn to read and write. It would be up to an authoring application to assign particular meanings to particular graphics. A simple example of that is the use of transposing instruments, but I think the same principle applies to ancilliaries like figured bass, staccato dots or neumes.

@jsawruk again:

I am not sure if these sub-formats would be part of CWMNX or MNX

I think (badly defined) CWMNX might simply dissolve into a few well-defined sub-formats that would be part of MNX.

I also think that the tree structure that holds the various well-defined parts of CWMN, could be supported using XML Schema include Elements. But that's a technicality that might be better discussed in #77. :-)

I'd like to spell something out here: If a powerful CWMN editing application produced a "guitar-tablature" file, then it would be quite feasible to have client applications that could only read that format. The client apps would not have to cope with all of CWMN.

[mdgood]

The profile attribute of the cwmnx element deals with subsets of CWMN. The subsetting discussion seems a bit off-topic once it goes beyond helping us select better names for the musical body elements.

[notator]

@mgood Please correct me if I'm wrong, but the profile attribute seems to apply only to what I would call "Romantic" notation. That's the notation whose semantic structure includes tuplets and metronomic tempo indications.

I think we need to define different semantic structures for other notations. Baroque music, for example, uses augmentation dots differently, and uses neither tuplets nor metronomic tempo indications (they weren't invented yet):

J. S. Bach: from Die Kunst der Fuge (1749-50)

J. S. Bach, Sarabande, from Partita BWV 829

The alignments in these two examples are the ones in the editions published by Bach himself.

[jsawruk]

For the top example, I personally think the 16th notes in the left hand are implied triplet-16ths. These would be encoded in MusicXML as triplet-16ths, with the number hidden, and I personally would encode them the same in CWMNX. That being said, I could definitely see a use case for encoding them as 16ths instead; I'm just not sure that such an encoding should be part of CWMNX.

As far as the second example, I don't see an issue. I'm not in expert in Baroque music, but to my eye, the notation presented looks correct and does not need any special encoding. I would certainly appreciate it if someone would explain to me why it needs a special encoding, as that would help me understand your position better.

[clnoel]

Part of the problem is that the profile attribute as currently written only has one option (standard). At the very least, according to things I've seen in other topics, we're going to need an option there for "unaligned" that will allow for different measure counts and time signatures in different parts, as long as the total time adds up the same in each part. But that's off topic for THIS discussion.

@notator I see your point about the first one. Even if you do as @jsawruk suggests and assume that each 8th is actually an 8th and turn some of the three-16th (or dot-16th+32nd) runs into triplet time, you get 2/4 time in the first two measures and 3/8 time in the last, all un-notated, which becomes a real pain when encoding. However, it still all lines up: there are still several definite locations that would be played at the same time. It just needs more interpretation by the encoder, just as it would by a musician playing it, to decide how it will sound. Perhaps you are right that we would need a profile setting to allow to allow for no time signatures at all, but that would assume that, across parts, the measures themselves line up, regardless of the number of beats in each measure.

@jsawruk, I think I see the issue with the second one. There are three voices (sequences). The RH-upstem voice has q-q.-e (3 beats), the RH-downstem voice has q.-e-q (3 beats), and the LH voice has e.-s-e.-s-e.-s (3 beats). Which you would think would be no issue, given the 3/4 time. However, the the RH-downstem 8th note is notated at the same time as the second LH sixteenth note, which is a sixteenth off of where it would be independently played. So do you play it at beat 1.5 as an 8th note (assuming that the notated vertical alignment was unintended), or beat 1.75 as a 16th (assuming that the notated q.-e was meant to be flexible)? There's a similar issue for the RH-upstem 8th note and the last LH sixteeth note. Once again, that becomes something that a musician, and therefore the encoder, would need to interpret. And something that later composers would probably make explicit, either by offsetting the 8th note to it's "proper" location, or by using a quarter note tied to a dotted-8th followed by a 16th. Honestly, I'd probably play it both ways on a piano to see which one I thought sounded better before deciding which way to encode or play it.

In this case, however, @notator, the existing "standard" profile can handle it. We don't have too many beats in a measure, we just have some odd alignments that can be handled using relative-x, and some choices to make in the semantics to decide how we, as the encoders, think it should be performed.

In any case, I would still considered both of those as legitimate pieces from the CommonPractice period that should be representable in the MNX-CommonPractice, although maybe not in the "standard" profile. They are not different enough to be considered a separate flavor of MNX.

[joeberkovitz]

This discussion of alignments and Bach is off topic (although a very worthwhile thread). Would the next person who wants to post on it, please move the discussion to the new issue #79. Please note my comment there which outlines the current proposed direction in CWMNX -- this sort of thing should be handily covered by the standard profile, although there's certainly room for discussion.

I plan on going into this question in the forthcoming discussion of CWMN layout mechanics, which is on the agenda at Messe.

[mdgood]

@notator, CWMNX handles all common Western music notation from the 17th century onwards. This includes baroque, classical, romantic, contemporary, jazz, pop, piano-vocal-guitar, guitar tablature, lead sheets, and much else that follows common notation. The scope is roughly the same as MusicXML's coverage. There may be some edge cases about what is "common" and what is not that will differ from MusicXML, but those are topics for other issues.

Profiles provide subsets. Our past attempt to do a profile (Open Score Format's PVG profile) was not a success so I think it is a very good idea to try one profile first - the standard profile - and see how useful it is before dreaming up multiple profiles. Let's see if profiles are actually of practical benefit rather than theoretical value.

Both MusicXML and CWMNX can handle these examples because they can represent the differences between how music is notated from a contemporary understanding and how it is performed. The mechanisms in the two formats for doing this are different - and Joe has just opened #79 for discussion of CWMNX's approach - but they both can represent this type of music with no need for separate profiles.

We are again moving far afield from the naming of body types like CWMNX which is the subject of this issue. Profiles and alignment both have their own issues and should be discussed there.

[clnoel]

Right. The discussion above has to do with naming only in that we have to decide that if we are using "Common Practice" as a descriptor, we had BETTER be able to represent the music from the common practice period, even if it's old and doesn't use tuplets and has a meter that isn't explicitly notated. I think we can pretty easily include that kind of thing, so I'm still sticking to "MNX-CommonPractice" as a good name for this variant of MNX.

Moving the rest of the discussion over there! Sorry for sidetracking!

[notator]

@mdgood Thanks for the list of notation types that CWMNX can handle, and for the information that profiles are currently at a rather experimental stage.

@mogenslundholm asked

Is there a hard division between CWMNX and GMNX?

I think the hard division is that GMNX consists of score instantiations. See above.

The instantiations can be of any notation type, including all the notation types that @mdgood mentions, and many others besides. A GMNX file can also contain semantic information specific to the particular notation type it contains.

[Edit 19.03.2018] If we all agree that GMNX files are going to be specialized SVG files, then I think GMNX could be renamed MNXSVG. SVG files are always instantiations,

[joeberkovitz]

Chairs: on our call today we selected MNX-Common and MNX-Generic as the names we'll use going forward. Future notation-specific encodings will also follow this pattern. Thanks and appreciation go out to all the thinking that took place about the names.

Note that the "Common" in MNX-Common is an abbreviation of "Common Western", and the spec will clearly describe it as such, not as a common global notational system per se.

This now requires some work on the spec, so moving to V1.