http://www.perlmonks.org?node_id=978579

Csgrouper has been improved!

Thanks to the comments I could gather here and there (but mostly here), I have made some improvements in Csgrouper and now one can almost run it without knowing about Perl. Help balloons have been added, some bugs have been suppressed and most of all, Csound instruments are now loadable without having to mention params in any particular way. The window aspect has been simplified too.

Now I need someone of good will to help me correct my English in Help messages.

"Csgrouper is a music composition software at the intersection of polytonality, polymodality and serialism. Its aim is not to tell musicians how to compose, but to provide a permutational framework with scalable settings."

http://www.wix.com/emilbarton/data
https://github.com/emilbarton
  • Comment on Csgrouper : first important revision since release

Replies are listed 'Best First'.
Re: Csgrouper : first important revision since release
by pemungkah (Priest) on Jun 27, 2012 at 21:09 UTC
    Emil, I'd love to take a look at it and tweak the English if needed.
[reply]

      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!

[reply]

      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?

[reply]
        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.

[reply]

      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

[reply]

Back to Perl News