I’ve wanted to contribute to SC for a while now and, every now and again, I try to get a grip on how SC is put together by roaming around the SC source on Github. It’s a much bigger project than anything I’ve ever worked on myself and obviously many decades of work have gone into it, so there’s a lot of content.
To get more people who are kind of intermediate programmers but would like to contribute, even in smaller ways, to the main SC project outside of Pseudo Ugens, a general overview of the various parts of the source and how they fit together would be very helpful.
I understand that this may be quite a lot of work but I thought I’d mention it as something that might help more people be able to contribute in the long term.
There is a good chapter on the server in the SuperCollider book which is very helpful. I think it’s online somewhere. Also Brian Heim has also been working on better documenting the source.
A really good project might be to do it yourself. By documenting the code you’ll find you’ll develop a better understanding, and it will give you a good excuse to ask questions of the developers.
here are the directories i tend to visit the most:
server/scsynth/ - source code for scsynth
server/supernova/ - source code for supernova
server/plugins/ - source code for all ugens
HelpSource/ - help files
SCClassLibrary/ - class library
lang/LangSource - core sclang source
lang/LangPrimSource - most primitives
QtCollider/ - sclang Qt GUI primitives
editors/sc-ide/ - the IDE
there are some things i actually don’t like about this structure, like the qt gui primitives hanging out at the top level and the inconsistent capitalization of directories. in general there are too many top-level directories. i think we shoud reorg it at some point.
for new contributors i highly recommend looking at our “good first issues” tag. if you see one that seems within reach, many contributors including me would be happy to help you through the process.
Hi all! New to the forums, returning to SC. I’m in a similar boat as Adam was 6 years ago - I’d love to contribute as an beginner-intermediate programmer, but there are a lot of moving parts. I’m curious if the information, resources, advice, and links in this thread are still relevant.
I’m also curious if there are any diagrams (UML, flow, etc) that help describe the architecture of SC – both at a high inter-scsynth-sclang level, and at a low intra-scsynth one.
Thanks!
Keaton
ps - @joslloand - I’m forum posting! you can check that box now
I’d say informations provided here stay as relevant as they were 6 years ago because they are mostly incomplete . The best way to get a glimpse of SC’s underlying architecture is to read the SuperCollider Book’s last chapter. But I wouldn’t advocate beginning from there.
I think reading SC’s code shows that it is mostly a collaborative and decentralized project. Some parts are missing documentation. Some mistakes were made. Etc.
As mentioned previously, the best way to get involved is to take a look at current issues on GitHub, pick a simple one, and fix it. At first, you might not find what you’re looking for easily. This will force you to ask yourself questions about how SC operates. Second issue will be easier, third one even easier, etc… At some point, you’ll get a better understanding of the project, and you’ll be able to see the ‘bigger picture’: SC’s timeline, why re-factoring current class library is needed but super difficult, which essential features are lacking and why it’s problematic to implement them, etc.
I don’t think anyone can find ready-made ‘global’ documentation about SC. I think that people that have a good understanding of how it works achieved it empirically, fixing issues, reading code, developing Quarks, etc.
A related observation: the amount of help you get from the documentation is (partly) proportional to the size and depth of your mental map of the documentation. After 20+ years, my mental map of SC help is pretty thorough. But, if I have to look up something about LilyPond, if a web search fails, I’m likely to end up asking their mailing list because I don’t have even a tenth of a sense of where things are in their manual.
Improving documentation structure and searchability can make it faster to build the mental map, but it always takes time. In that sense, documentation will never be transparent enough.
Thank you for your thoughtful responses, @Dindoleon and @jamshark70! You make good points that I did not consider. The uniquely decentralized OSS nature of SC is fascinating, and I totally understand how that would greatly complicate any effort to document any global view. Glad the advice here still holds, too. Jumping in and getting started seems to be the best route, I’m looking forward to doing so
. The best way to get a glimpse of SC’s underlying architecture is to read the SuperCollider Book’s last chapter. But I wouldn’t advocate beginning from there.
