W dniu 12 lutego 2012 15:13 użytkownik Graham Percival <gra...@percival-music.ca> napisał: > On Sun, Feb 12, 2012 at 12:03:48PM +0100, Janek Warchoł wrote: >> 2) Adding comprehensive MusicXML import and export features, together >> with test suites for it. Requirements: ? (no idea in which language >> this would be written), MusicXML, basic LilyPond and music notation >> knowledge; familiarity with other scorewriters would be a nice bonus >> (for cross-testing). The goal would be considered achieved when a >> (previously chosen) not-so-complicated score could be imported from >> MusicXML and exported back with no (unintentional) loss of data. > > umm, you know that we already have musicxml2ly import, right?
Yes. I had some issues with it - dynamics got attached to wrong notes. So i basically meant "improve import and add export". > I agree with having this on the ideas list, but it should > definitely mention musicxml2ly.py and basic familiarity with > python. Sure. >> 5) Build System Improvement: if we want to ever move away from make, >> this would be a good opportunity. Issues like thousands of errors and >> warnings during compilation should be removed, all dependancies fixed >> (so that one doesn't need to remove fonts folder to have fonts >> rebuilt). Requirements: Python, Make and (optionally) another build >> system. > > I think this item needs rewriting. If Phil and Julien want to > highlight exactly what is left, great; otherwise I'd be tempted to > leave it out. > > Then again, it's just possible that Phil or Julien might be > interested in being student in GSoC, in which case we should > definitely include this as a project. Students can add their own proposals, ideas list is more like a guideline. So there will be no problem leaving this out and then having Phil or Julien formulate their own proposal when they apply. > I'd add another item to the list: > n+1) clean up compiler warnings, static code analysis, and > valgrind warnings. Automatic code analysis tools (warnings in g++ > and clang) and analysis tools like valgrind memory leak detection > and callgrind code profilers provide valuable information about > possible flaws in C++ code. It would be great if somebody could > clean up those warnings, as this would allow us to automatically > reject any patch which introduced extra warnings. Once compiler > warnings are fixed, analysis of memory leaks and profiling would > be great. that's nice. thanks, Janek _______________________________________________ lilypond-devel mailing list lilypond-devel@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-devel
