Hi all,
At various times I’ve wanted to embark on a process of removing things from csound to make a trimmed-down “diet” version. It’s probably OCD, but it also, I think, for me anyway, helps to not have distractions. There are currently, in a standard install, more than 1200 opcodes. Speaking personally, many of them have limited utility, and have the flavor of abandoned experiments, or are opcodes that I have estimated to be of limited musical utility to me (everyone is different, see below).
I’ve made a curated fork here: github.com/akjmicro/diet_csound
It’s a moving target snapshot of a process…it’s working well, and takes less time to compile, and about half of the opcodes are gone. I also gave the codebase some love by more logical re-organization of things that I touched that seemed to make no sense (e.g. spectra.c/spectra.h was a dumping ground)
I realize that what one person (me) considers essential might be the complete opposite of what others do. And what I think is essential to my own work is likely to change over time…things will get added back, or taken away. My hope by starting the project is that I can contribute back to the community in the following ways:
- general cleanup and logical placement of code
- prettification of code with beautiful formatting
- most of all: encouraging a system that is customizable by providing general instructions/techniques/scripts that allow lean builds tailored to individual taste. I’m just not into the current monolithic kitchen sink approach of the main repo (I think this is partly the approach since CMake was chosen as the build system? It’s possible, if one knows what one is doing, to customize, but it’s less obvious than back in the day when it was ./configure; make; make install)…
With that in mind, I’m happy to give back cleanups that are wanted/welcome and make sense to the main developers. This community has given so much over the years to us all, it would be the least I could do!
Otherwise, I consider this a separate curated subset of the main repo, one that satisfies my OCD and desire to not cater to the ideal of “well, if I wrote it 20 years ago, it needs to run today”…something which I’ve not found to be true even though it’s stated as a support goal. The fact is, Csound has broken old orchestras for me on many occasions as new versions have come out. Not a terrible thing, actually – normal in most software. My reasoning is: why not clean up the code, deprecate certain things, etc., while time marches on?
I only offer it as a template that might be useful for others who enjoy and/or desire a path w/re: customization hacking of Csound.
Cheers,
Csound mailing list Csound@listserv.heanet.ie https://listserv.heanet.ie/cgi-bin/wa?A0=CSOUND Send bugs reports to https://github.com/csound/csound/issues Discussions of bugs and features can be posted here