I think everyone should know I met Jan in August to demonstrate the software we are developing at Ottawa University in Canada that uses Lilypond as a pre and especially post-display tool for what is essentially starting out as a practice aid.
We are going to be leaving our database completely open regardless of how the business around the software ends up shaping itself, since our priority is going to be getting as much music to be available to anyone and everyone as possible, and to make it easier for everyone to learn or improve at the piano.
This means we are trying to smooth the path from the starting MIDI file or Lilypond script all the way to the files a user would need to use our software. I am going to be working on all the scripts relating to the midi2ly function in order to improve this transition (which still requires considerable manual editing).
I am curious, was anyone on here the one that originally wrote this part of the program? I am strong only in MAX/MSP and Lilypond programming, but I am picking up Java and C/C++ and by the look of it, should be able to pick up Python as well (these languages do not seem to be extremely different from one another).
I was really hoping someone knowledgeable about the scripts could take the time to heavily comment them and send them to me to go over (AFAIK there are three scripts involved: python/midi.c, scripts-lilymidi.py, and the midi2ly.py file itself).
This would save me a lot of time to make sure I know what every bit and line of code does before I consider how the changes I want to make can be integrated into the appropriate scripts and tested.
=============================
I can outline the changes I think need to be made (some for the software, but some for a general improvement of the overall reliability of the process as well):
1) Assure that the MIDI file itself is able, and does (with the appropriate syntax and header structure) contain the information needed for the script to access and make a decent conversion.
So we will probably be building a special MIDI file conversion utility that will read a MIDI file, query the user on a number of factors, and re-write the MIDI file so that it complies with all of the syntactical and structural factors that the Lilypond scripts would require. I expand on this below:
a) I have noticed upon testing that usually, lacking elements in the conversion process have to do with the sub-par MIDI file standardization and not the script itself. People complaining on the list over the years have probably not realized this. We are going to try and catalogue (this will be painstaking but it will be worth it) the various bits of information that should be in a MIDI file if they are essential to the piece, and how many different ways different MIDI file creation processes lead to this information being included in the file (or not).
i) There is no accommodation for instance, of anacruses/pickup beats in the MIDI protocol. The only way around this is to insert empty space in measure 1 and use that as the pick-up beat. Much like how MIDI standard never enforced the CC 0-127 over the years and some manufacturers used 1-128, we will have to make a similar accommodation here as well.
ii) Time signatures and key signatures actually get picked up less often by the commercial Finale (and I am running 2006) than they do by Lilypond. Nevertheless, we are going to investigate how many ways these can be written into the headers and bodies of the MIDI files (for when changes occur), and make sure our utility can track them all and re-write them to the one way Lilypond will consistently catch.
iii) Perhaps the most crucial lack in MIDI file standards is accommodation for enharmonics - we are most worried about this part of the process of all. It may end up being that we will have to push for a new MIDI file standard with the manufacturers association in the long run, finally distinguishing between MIDI files intended for notational display and ones where only acoustic pitch accuracy is important. A rather tedious workaround might be to have our utility query the user on all the black notes one at a time, and have them repair the #/##/b/bb white notes by hand, which would probably be our best option for the time being.
iv) PPQ resolution varies widely from file to file. The oldest files will usually have a PPQ of 96, whereas the most modern ones are usually 480. The ones I most commonly see (perhaps because this is what Lilypond generates) are 384. We are not totally sure yet how huge of a factor this is but we are considering having all files be converted to the same resolution. It's a low-priority issue for discussion whether Lilypond should be using the 480 resolution when it generates MIDI files, but 384 is still pretty darn good.
v) Note alignment along a quantized grid is a must (as already indicated in Lilypond docs), but
Duration is also a concern - a note that is long but had a staccato originally put on it, might be re-converted as a shorter note, etc. This could also possibly be resolved with our utility, perhaps we will allow the user to do separate "passes" through the file (enharmonic, duration) or combine them together (both at once, in tandem). This will still theoretically be less work than doing all these repairs to the resulting lilypond file.
vi) Multiple voices - This will be a tricky one. We are hoping for pieces like fugues to have voices have their own track, and we will need to investigate the MIDI files for fugues out there. If we can keep the voice concept separate from the staff concept, it should be no problem having 3-5 voices, etc., "wandering" the two staves.
***We are hoping to make a universal standard for "digital editions" of pieces where all (default) RH material is always on the top staff, and all LH material is on the bottom staff. If there is material that is shared between hands that is a voice unto itself, we are hoping to treat it as a special case where unique identifiers for hand changes (ie \ls and \us) can and will be placed to indicate which hand is playing the material.
vii) Hand Distribution and MIDI tracks - Generally placing RH data on Track 1 and LH data on Track 2 will be a requirement, I have seen files where LH data is for whatever reason split between track 2 and 3, and these can be merged. We are hoping to resolve minor hand distribution issues within the edit mode of our software, when the structure below becomes the rule and is then a reliable grid for file manipulation and management. In Debussy, etc., where there can often be three staves appearing, we will have to see what we can do about it when we get to them.
In conclusion for 1), there are many challenges involved in working with the current quality of MIDI files (it is a shame the association never enhanced the standard in the 90s before we had so many MIDI files be created by people around the world. Despite this, we are going to try our best, and we are going to work our way *up* in level of difficulty/complexity so we can hopefully establish a universal system to how we think a 21st century MIDI file should be structured.
We will then take our case to the manufacturers association and see what can be done, so hopefully everyone will be able to "up-convert" existing MIDI files rather than have to re-write them from scratch again.
The next aspect of our work is determining how the resulting lilypond file should be structured:
2) Lilypond files, whether converted from MIDI after being passed through our pending utility, or written by hand for compatibility with our software (I think it would be great to write files this way anyways, simply as a matter of establishing "style" for Lilypond-user music scripts), should :
a) As Jan and I have discussed, there should be at all times, the maximum number of voices for the entire piece. Where voices disappear, s should be used until the end of the piece, or until they reappear. I am not sure yet whether it would be better to write multiple voices (melody/harmony) generally sticking to one staff with the << {} // {} >> style, and fugue voices with entirely their own voices, but I believe this will probably be the case.
b) There would be strictly one line per measure, and pieces should always be written in relative mode. c) All chords *must* be written from the lowest note to highest!
We will add more to this list as we determine more ways to create an ideal universal style that will be reflected in the midi2ly output when we have worked with it as much as we can before getting anywhere with the MIDI guys.
3) How the resulting Lilypond file gets prepared for our software (another automatic utility that requires everything in 2) to be true)
pass a) <>'s get placed around all single (untied) notes so the \tweak command will work for them (this is the change the colour of the noteheads on all notes in a piece)
pass b) block comments %{%} get placed before every (untied) note for note indexing at 4)
pass c) another set of block comments %{x%} get placed before every set of <> for rhythmic indexing. Notice the x in the comment that will distinguish them from the empty ones above.
*** rhythmic values might get explicitly written into the files if that helps with 4) below.
4) Here we will do the actual indexing of note and rhythm blocks to reference for post-displaying We will end up with three types of indexed files - practicing for the RH, the LH, and both. The challenge here will be developing an algorithm that can track the file using the laws of relative mode to determine where and when voices cross, overlap, etc., and how far each voice has progressed into a measure relative to another. This will be a complex task but it is sure better than indexing files manually! (believe me, I know!)
So in the most complex case scenario, indexing for HT will grab one line at a time from all voices into a buffer, with as many variable placeholders as there are voices, and map out the lines for that measure moving forward by whichever voice has the shortest rhythmic value at any given point in time, and then scanning from there. It will be able to determine when events in the voices align and when they do not, and although it will generally stick to the tendency that the lowest voice written in the file will produce the lowest notes, and the highest the highest, when voices do cross, the placeholders will switch, for as long as they are crossed, and then will return to normal afterwards. When voices merge, ie a double-stemmed note, index values will be written for both voices, which will be caught later on by our index verification script we are already working on to proof our manually indexed pieces in the database so far.
In the end, we are hoping to more or less smoothly transition MIDI files or hand-written Lily files (with our standards in mind of course) to MIDI and Lily files compatible with our software. While we have been testing our prototype, we are getting confirmation that this is really worthwhile as I have never had more efficient (and fun) practice sessions in my life! My students are getting used to it too now, and they love the fun we can have with it.
===============
I am working on an (open) method book series as well combining OpenOffice and Lilypond, that will generate separate post-displays for all the exercises encountered in the book itself.
We have a special tracker in our software that prompts a special dialog when all expectations have been met for an exercise. It will be a very logical and fun type of method book, i have taught kids with the rest and they are too old-fashioned and boring now to keep their attention I think.
In this way parents might actually be able to teach kids the basics themselves before sending them to a teacher to learn all the human aspects of music if they seem to be having fun.
Anyways, that's enough info. for the day...
Looking forward to being a part of the Lilypond team!