Re: [Lenmus-developers] Short term planning and medium term goals
LenMus is a free program for learning music theory.
Brought to you by:
cecilios
Menu
▾
▴
Re: [Lenmus-developers] Short term planning and medium term goals
|
From: cecilio <s.c...@gm...> - 2010-03-15 18:46:23
|
I agree on freezing lenmus program development if you understand this 'freezing' as 'not adding more features for now to the program'. But I do not agree if you understand 'freezing' as 'not touching' current lenmus code. In my opinion, the lenmus program solves the need for a real test case (not a testing environment) for the library. Although the library will be developed in a TDD approach, its real usability must be tested by using a real program. And lenmus is there for that! It apparently looks easier if we 'forget' about the lenmus program and start a new thing. But I'm not so sure if this is really true. The approach I suggest of using lenmus as a testbench, also provides a clear path to guide the library development and its specifications (the 'user stories' for TDD). And, while the library real usability and its API and specifications are tested, at the same time ... lenmus is changed to use it! The objective of using lenmus is not to debug code but to debug behaviour and guide specifications. Trying to use the library as soon as possible will help us to discover design problems that, otherwise, will remain undetected until all the library is built without any real roots. Code bugs will probably be all detected in a previous step, with the unit tests that drive the development, but not architectural and API problems. Developing first the library and then, when finished, start testing its real usability by modifying lenmus program to use it, will require probably much more time. And the risk of never modifying lenmus and continue working only on improving the library is real: lenmus application will die. As to the proposal of forking / starting a different project, I agree that the library should be a different project in a different repository. But if we use lenmus as a testbench while upgrading lenmus to use the library code, it is going to be easy if, at least for some time, we keep the library sources in the same tree than lenmus sources. This allow us to use directly the library sources without the burden of having to build the library and, then, building again lenmus to use the modified library. And having to do this for every test or change we do! So, my proposal is to start with the library sources in the same tree, removing and refactoring code in lenmus as the code in the library grows and provides the necessary functionality. Then, when we feel that the library is more advanced, we will split the source tree in two real independent projects. And this point can be reached soon. My understanding of the situation is that Carlos will continue working on lenmus until he finishes his PFC. Then, probably he will move to the library. Antonio will work only on the library. Chris is not affected for now by this. And I will work in the library and in changing lenmus to use it. Are these assumptions basically correct? For people that would like to work on the library but not on lenmus, sharing the source tree will not be a problem. And for me (who will be, quite probably, the only one to modify lenmus to use the library) it will be more convenient, at least at the beginning. I fully understand that it is more attractive to work only on the library. But I fear that if we freeze lenmus and fully split the two projects, I myself will forget very soon and definitively about lenmus. It is not appealing to work on lenmus (writing texts, designing exercises, dealing with translations, with the users, etc.) and definitively there is much more fun working on the library! On the contrary, if we keep both alive, lenmus will become, little by little, a better and useful tool for students and teachers. And at the same time, the library will be a good tool for the open source community, tested with a working application. In any case, I'm open to more comments and criticism before we take a decision. Regards, Cecilio El día 15 de marzo de 2010 16:05, Antonio Nicolás Pina <ant...@gm...> escribió: > I'm totally agree with this whole "library" thing, but you should > consider doing it as a fork or freezing the development of the main app. > I think it should be easier that way. Anyway, I'm willing to help on > this as much as I can. > > Antonio > > De la Fuente Cordoba, Juan Carlos escribió: >> Ok Cecilio; I agree with your idea of "segregating the underlaying >> music processing framework" in a SDK or similar. There are a lot of >> music manipulation classes and routines that can be used elsewhere. >> The concept might be similar to the jMusic library >> (http://jmusic.ci.qut.edu.au/index.html), which has originated many >> different projects: http://jmusic.ci.qut.edu.au/applications.html >> >> And It will also be better for LenMus, since it will 'enforce' a good >> structure. >> >> I'l try to support you as much as possible! >> >> Carlos >> >> >> >> -----Mensaje original----- >> De: cecilio [mailto:s.c...@gm...] >> Enviado el: viernes, 12 de marzo de 2010 17:57 >> Para: LenMus developers >> Asunto: [Lenmus-developers] Short term planning and medium term goals >> >> I have a proposal I would like to discuss with you. >> >> I'm going to undertake the re-design and re-build of all the complex >> and buggy issues, mainly score edition related code. I foresee that >> this will take me two-three months. I will take the opportunity to >> start a 'project split' in two sub-projects: >> >> * LenMus Phonascus, the current application for learning music theory, >> and >> >> * LenMus Library: a LGPL open source library (liblenmus.lib / >> liblenmus.dll) for rendering, editing and playing back music scores. >> It will be platform independent and will use only pure C++, no >> wxWidgets. >> >> Of course, LenMus Phonascus will use the LenMus Library for dealing >> with music scores. >> >> The library will use (I hope) modern, advanced C++: templates, design >> patterns, integrated tests, exceptions, etc. >> >> The split and re-design will be done keeping LenMus program fully >> operational, that is, maintaining functionality and compatibility with >> current code base. The SVN repository MUST always be in a build-able >> state so that we could release a new version, including patches or >> more functionality at ANY moment. No one currently developing new >> functionality (mainly Carlos) will be affected by this move. >> >> Therefore, this split will take time as it must be done in parallel to >> adding more functionality to LenMus Phonascus and keeping it fully >> operational. >> >> >> Library objectives >> ------------------ >> >> * Platform independent (Windows, Linux, ..) >> * Use modern advanced C++: templates, design patterns, integrated >> tests. >> * No dependency from wxWidgets: use std::strings >> * No GUI: >> - output will be bitmaps / SVG stream / file streams >> - input will be file streams, text commands >> * Internal music language will be LDP. Support for >> importing/exporting MusicXML will be included in the library. >> * The library will have a companion testing program for automatically >> checking all its functionality (Test Driven Development desirable for >> all the library, except for code re-used from current lenmus program. >> But even in this cases, some minimal integration tests must be >> included). >> * a wrapper so that the library can be used from wxWidgets will be >> included. >> >> >> Intended approach >> ----------------- >> >> - the internal score representation (lmScore, lmVStaff, lmStaffObjs, >> lmColStaffObjs, etc.) is going to be replaced by a new one, less >> complex, basically the LDP parsed node-tree. When I started lenmus I >> had strong concerns about performance and optimization. Also I did not >> have any idea about the problems for representing music and managing >> the representation. The result is that I created a too complex >> structure (lmColStaffObjs, lmContexts, lmVStaff, and others) that >> creates a lot of problems for code understanding and, therefore, give >> raise to a lot of bugs. >> >> - Create the new internal representation. I expect to have this ready >> for next weekend. It is, basically, to write a factory class, add a >> functor template and a small modification to current lmLDPNode class. >> >> - modify lmDocument to maintain the two representations for a score: >> the current one (lmScore) and the new one (basically the LDP parsed >> node-tree). This is, basically, adding a new member variable to >> lmDocument. >> >> And now the hard work starts: >> >> - Identify all points in which lmScore is used and replace its usage, >> in one or two phases. If replacement is complex it will be done in two >> phases: >> - Phase 1: instead of using the lmScore stored representation, >> build it on demand, at that moment, from the new representation. This >> way, soon lmScore could be removed from lmDocument, leaving only the >> new representation. This task is very simple: invoke current LDP >> parser providing the pre-parsed tree as input! >> - Phase 2: replace each current process on lmScore by a new one >> using directly the node-tree representation. >> >> Otherwise, if replacement is easy, phase 1 will be skipped, and I will >> move directly to phase 2. >> >> - My first objective is to replace the buggy part: all edition related >> parts, mainly the ColStaffObjs, and the ScoreCursor. I expect to reach >> this goal in three months, so next LenMus release, with a more stable >> editor, is planned for end June. In case of (probable) delays, I >> expect that at maximum, the next release will take place before >> beginning September. >> >> - As to the SVN repository, the lenmus source tree will be modified as >> follows: >> >> 1. I will create folder "src/library". And I will create >> subfolders under it to organize all library code. >> 2. All new code that, in future, will be part of the library will >> be created in this sub-tree. Also old code that should be part of the >> library will be moved there (but not now). >> 3. When the right time arrives, the src/library" sub-tree will be >> removed form lenmus to give birth to an independent sub-project: the >> library. At that time, the library will be built and lenmus program >> will be linked to the library. >> >> Also, I will create the source files containing the unit tests for >> the library in "src/tests/utests". >> >> Well, this is my proposal and I will start working on this if no >> deterrent comments or better ideas. As always your comments, >> suggestions and proposals are welcomed! >> >> Volunteers to work on the library and on writing the new code also >> welcomed! >> >> Regards, >> Cecilio >> >> ------------------------------------------------------------------------ >> ------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Lenmus-developers mailing list >> Len...@li... >> https://lists.sourceforge.net/lists/listinfo/lenmus-developers >> >> ------------------------------------------------------------------------------ >> Download Intel® Parallel Studio Eval >> Try the new software tools for yourself. Speed compiling, find bugs >> proactively, and fine-tune applications for parallel performance. >> See why Intel Parallel Studio got high marks during beta. >> http://p.sf.net/sfu/intel-sw-dev >> _______________________________________________ >> Lenmus-developers mailing list >> Len...@li... >> https://lists.sourceforge.net/lists/listinfo/lenmus-developers >> > > > ------------------------------------------------------------------------------ > Download Intel® Parallel Studio Eval > Try the new software tools for yourself. Speed compiling, find bugs > proactively, and fine-tune applications for parallel performance. > See why Intel Parallel Studio got high marks during beta. > http://p.sf.net/sfu/intel-sw-dev > _______________________________________________ > Lenmus-developers mailing list > Len...@li... > https://lists.sourceforge.net/lists/listinfo/lenmus-developers > |