Re: commenting for midi2ly?

2007-10-14 Thread Graham Percival

Kieran Coulter wrote:
I am curious, was anyone on here the one that originally wrote this part 
of the program?


According to the statement at the top of midi2ly.py, it was Han-Wen and Jan.

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


I highly doubt that they have the time to do this.  I'm afraid that what 
you see is what you get.  On the plus side, python is a very easy 
language to learn, and it's very easy to test things.  (no big compiling 
time, easy print() statements, etc)


Good luck!
- Graham


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel


commenting for midi2ly?

2007-10-13 Thread Kieran Coulter
Hello everyone on the dev list,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), butDuration is also a concern - a note that is long but had a staccato originally put o