Thanks for your work, I take the initiative of answering you here also and not only on Github because your thoughts can give other programmers the will to participate and as I told you, I would appreciate to see Csgrouper become the project of a team.

Your idea about refactoring by separating the musical model from the Tk presentation is important and I hope we can realize it soon, but I'd probably need more of your help in that. I think that this operation could involve only the csgrouper.pl executable and not the library classes.

As you know there is already a package CsgrouperInter at the end of csgrouper.pl but it's only dedicated to giving the user a place to overwrite the comparison routines without altering the core of Csgrouper that is made principally of permutational functions from the object classes.

What the newcomers may not realize immediately, is that these permutational functions are objective, part of them are described in mathematical books such as Modern Algebra by Franck Ayres Jr., Schaum ed., the others are derived from the former ones.

I gave less importance to what you call the "musical model" because it was conceived only as a way to adapt these permutational functions to music. This model has been made empirically.

As long as the ouput of permutational functions is kept (i.e. the succession of the notes), the constructions can claim to some degree of mathematical purity. It means that everything else that is connected to the musical model: mostly the notes octaves, their rythm, their sound parameters (like amplitude, duration, attack, crossfade, etc.), can be changed. This is where your refactoring proposal fills a gap, because having not made the separation clear from the start makes users think that Csgrouper is a program that makes music, when it should be understood as a program that yields permutational forms for music, packed in a changeable way, which is quite different.

I think that we could perhaps begin by separating the package CsgrouperInter from csgrouper.pl (the Tk GUI) and give it its own file that can later receive x-functions and y-functions responsible for sound parameters modifications and sequences relations.

What do you think about that?

Exactly my thought. I think that is the way to go - provide an API to the permutation engine, and the the UI just calls those functions as appropriate. The same engine can then be used in any program that wants it, as the details of presentation are then completely separate from the generation of the permutation sets.

That could even be its own separate CPAN module if you wanted to do it that way.

OK, let's work that way. I'll be delighted to merge your fork if you find some time to contribute. Today I replaced 'Moose' by 'Mouse', it helped gain a few seconds at load time and requires less dependencies. Thanks for this advice too.

That's cool,
you can download the tarball at Github. I'm sure that if you take a look at it you'll want not only to tweak the English but the code itself! Currently I'm thinking about getting rid of Moose because in spite of my efforts the program is not well object oriented and too fat, but that's another question.

The manual pages and the balloon help messages where your help would be most needed are in the process of being written but far from being done yet. You could first take a look at what has been done and then we could proceed package by package until everything is written. The manual pages are pod text included in the code. The balloon help messages are in csgrouper.pl (menu_balloon()).

Many Thanks!

Well, I just forgot to log in. (By the way let me precise that I didn't intend to criticize Moose, it just might be too elaborate for the kind of object orientation I was able to design.)

Looking forward to reading from you, either here or by email.

Emil