Packe [[email protected]] wrote: > > Hi again, > > I have now been given admin rights to this project (thanks Joachim). What I > understood from Joachim is that there is no active maintainer of the > JSynthlib project today. So I'm now willing to assume that role. >
Hi Pascal, Glad to see that you're prepared to revive the project! > > I've been sketching on sort of a roadmap and would like to get some feedback: > > Change project structure and fix ant script > Create system test cases to secure basic driver functionality - assuming that > the current drivers work as expected... > Fix existing bugs (can those of you who know any bugs please report them on > SF?) > 1.0 release - As discussed in this thread: 10th anniversary > I'm hoping to do that this year or early next > Once the 1.0 release is done I think focus should be on merging the refactor > branch to trunk and straighten up the API > My plans for the refactoring branch were to start by modularising the low level MIDI code in the core. Basically, I wanted to produce an interface and implementation class that defined the operations required for System Exclusive messages. For unit testing it would be good to have a dummy MIDI driver that could act as a mock - I don't know whether something like this already exists in another project, but it would be worth checking. I then wanted to produce interfaces for the various higher level operations that a patch editor and librarian performs, and to ensure they were free of GUI code to enable easy unit and integration testing. Then I wanted to look at the GUI related features that the drivers need to have implemented in the core. Finally, I wanted to work through each driver and reduce them to the minimum amount of code possible, with a separate class or classes for the MIDI/SysEx calls that contained no calls to the GUI parts of the core. As with the core, I wanted to have t he GUI code for each driver in separate classes to the code that deals with patch data to enable automated testing. > > If anybody still believes in this project help is very much appreciated! > If my ideas outlined above are similar to yours, then I would be very happy to become a contributor to the project. > > One thing though, I think a problem previously has been that code has been > delivered without prior review. Therefore I would like patches being > submitted through the patch page on SF instead of direct merges to trunk. I > (and possibly another volunteer) will monitor these patches and provide > feedback/merge the patches as they are submitted. > That sounds very sensible. I suspect that what has happened in the past, is that people have written a synth driver and where they needed access to something in the core they have broken the encapsulation rather than extending a clearly defined API. There also seems to have been a lot of cutting and pasting of code between drivers, where it would have been better to reduce duplication by again extending the core API. > I'll wait one week from now to let you get back with your thoughts before > starting any work at all. > > Chris, would you be able to explain what you did for changes to the ant > script on the refactor branch? > I'll make time this week to have a look again at my branch. I can add support for unit testing to the Ant script, as well as support for static analysers such as Checkstyle and PMD (I may have already added those). > > BR > /Pascal > Regards, Chris ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Jsynthlib-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/jsynthlib-devel
