muparkkra
commented
5 years ago The following is about the first item, Mup option to output MusicXML.
I downloaded musicxml-tutorial.pdf and musicxml-schema.zip. So far I've read through the tutorial.
There are several things we don't directly have. Fortunately, all are optional. Some of them we could probably deduce with reasonable accuracy, but we may want to have a way for the user to designate strings with special keywords or something. work-number (This is like an Opus number, of Bach BWV number) work-title (maybe can usually deduce as the first string in header or top) movement-number movement-title (could maybe guess the second centered string in header or top, if there is one?) creater (composer and poet. Maybe first "right" in header/top is likely to be the composer, especially if it looks like "Name Lastname" or other variations, and not something like an opus) rights (can probably deduce by using all strings containing (copyright)) encoder (name of person who did the Mup inputting. On Unix we could look up their user's "real name" from the password file, or at least their login name. On Mac, it looks like something like "dscl . -read $HOME RealName" would do it. I assume Windows probably has some way to get the "user's name."). encoding-description (some explanation of why someone input it) source (where original manuscript came from) part-name (we could just call it "staff S voice V" or maybe deduce from staff label, but it would be harder if multiple voices)
For grids, they want the meaning broken into several fields, so G6/D would map to three fields. We can probably parse it accurately enough most of the time. But do we need a way for the user to override if we get it wrong?
We have lots more headshapes than they do, and they have some we don't. For the ones we don't support, we'll just never generate those, but I'm not sure that to do with the others; I guess just leave as normal. (Or maybe they do support more and I just haven't found them yet.)
Default is UTF-8 encoding, which would not include most of the extra PostScript we now support. I'm not sure yet how to deal with that.
What command line option do we use for generating MusicXML? The obvious choices would be -x -or -m, but those are already taken. -X would be available, but for the other output file types we have -f/-F and -m/-M pairs, so we should have something similar for consistency. So I guess -l/-L may be the best available choice.
Currently we allow either MIDI or PostScript. Now we would have a third. Is there any reason to support allowing more than one of those three in a single run, or is it fine to just make user run once for each kind?
Since MusicXML supports both printing and MIDI things, we might need to run all of placement along with MIDI. Today, if doing MIDI, we only do placement up to before abshorz. And MIDI things are pretty much generated on the fly, not kept around for another phase to print out, so we might either neither to save more around, or be call midi code from the xml code.
They use units of tenths of a stepsize. Fine, we can deal with that.
Lyrics are associated with specific notes, so maybe we would best get to them via the "downward" chord links. Hopefully we can somehow reuse what we know about which voice to associate them with.
We may have to associate "between" things with some voice on the staff above?
I haven't found yet how they deal with cross-staff things or pedal or octave marks.
They support recognizing dynamics like "pp." I guess we use "dynamic" if user said "dyn" and use "direction" for everything else. Not sure what we do about music symbols in such strings. Just pass though like "(up4n)" ? Or maybe there is some way to map things that I haven't found yet.
They support a "compressed" format, but I think that just adds some more tags and "zips" that file along with an index file and optional other files, like pdf or MIDI renderings. So I suppose we could do our normal Unix way of saying a zip program already exists, so user can zip it themselves rather than make Mup dependent on some zip library, although I suppose it there is a free public domain small implementation that we could ship along with Mup code, we could do that. It would only have to encode, and not need any fancy options.
Given that the XML is text, and anything that might be hard is optional, we could punt on anything that seems too hard, and say if user doesn't like what we do, they can post-process the output. And we could say partial MusicXML support and list the subset we support, and potentially add more in later releases.
I think the best way is to have some general-purpose XML-generation functions to handle indentation and matching up tags and such. In my prototyping, I'd say a dozen of so small functions should handle everything we need. Then basically start from the tutorial and generate everything that covers. Then check the spec and see what else we should support. Then see if we can think of anything Mup can do that we didn't cover, and if so, either try to cover it or document what info is lost. From my prototyping, I think most things will be very straightforward. It could end up being a few thousand lines of code just to cover everything, but most of it will be just taking something Mup already knows and printing it out with XML tags around it, possibly massaged in some way.
The only area that I see having a potential to be difficult is that I think when doing XML we would need to do all of placement first, then during the XML phrase we might need to sort of have the XML code run most of the MIDI code in a special XML mode. So that could require moving some functionality around and break some current assumptions in the midi code. If that turned out to be just too horrible, worst case we could potentially back off and say the MusicXML output only covers notation, not MIDI, or at least only a subset of MIDI.
Support a Mup option to read the normal Mup input and output the equivalent music in the MusicXML format. Also, provide a separate program to input a file in MusicXML format and output the equivalent music in the Mup format.