Re: [Jsynthlib-devel] Change project structure

[<chr...@ch...> <chr...@ch...>]

Packe [pa...@ya...] 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 the 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