- Blogs and Sites
- Systems interfacing with SC
- SuperCollider Symposium
- Academic Papers
- Pieces with live instruments or voice
- Setting up your development environment
- Creating pull requests
- Issue Labels
- Unit Testing Guide
- Continuous Integration - GitHub Actions
- Reviewer Instructions
- Generating crash reports
- Contributing documentation changes
- Code style guidelines
- C++ code style guidelines
- C++ formatting instructions
- Commit message format
- UGen Quality Standards
- Project Structure
- git cheat sheet
- git workflow and guidelines
- Platform Support
- Setting up the IDE for easy contribution
- Miscellaneous project information
- Debugging Tips
- Translating the IDE
- Adding to QtCollider widgets
- Signing and Notarizing for macOS
- Plugins development
- scsynth development
- SuperCollider website wiki
Developer working documents
- Dev Team Meeting Minutes
- Notes for refactoring the server implementation
- PlayBuf 2017
- Undocumented classes and methods list
- sc-dev Meeting Procedure & Templates
- Project tasks organization
- GitHub Actions migration notes
Clone this wiki locally
If you are looking for information on using SuperCollider, including documentation, you may want the following resources:
- the project README has general information on the project including a description, a list of supported platforms, instructions for building and installing, and a list of good first resources.
- https://doc.sccode.org has project documentation viewable online.
If you are looking to meet and talk with other people using SuperCollider, check out Joining the community below.
If you are new to SuperCollider and want to contribute to the project, then first and foremost thank you for your interest! We appreciate that you want to contribute to SuperCollider. Your time is valuable, and your contributions mean a lot to us.
Depending on your skills, interests, and experience with other projects, you may want to review the following documentation:
- if you are totally new to this project, or to contributing, read "What does contributing mean?" first.
- our Developer Reference section has more reference documents on our project design, workflows, and practices.
SuperCollider users and developers communicate on a number of different channels. Here's how to access them:
- Sign up for a GitHub account and give us a star.
- Join the sc-users and sc-dev mailing lists.
- Join the forums for a more modern alternative to the listservs.
- Join our Slack channel. It's not mandatory, but it's very convenient for talking to other devs!
- Watch the above channels for announcements of our weekly-ish developer calls on Skype. Everyone is welcome to join them!
- Read our Code of conduct.
Creating an issue is the simplest form of contributing to a project. But there are many ways to contribute, including the following:
- Updating or correcting documentation
- Fixing an open issue
- Requesting a feature
- Reporting a bug (see Issues below)
- Translating the IDE into a language you know
- Creating a Request for Comments (RFC) to propose 'something big'
If you're new to this project, check out the issues tagged "good first issue" – fixing one of these is a great way to get started as a contributor!
If you'd like to learn more about contributing to open source projects in general, the Guide to Idiomatic Contributing has a lot of useful information.
The purpose of the issue tracker is not just to report that there's a problem with SuperCollider, but to effectively communicate what the problem is so that others can easily help reach a resolution.
Investigate the issue: What is the minimum effort or code required to produce the issue? Does it happen every time? Can you get it to happen on someone else's computer? Someone else's operating system?
See if a ticket already exists: Search SuperCollider's open issues. If an issue for your problem already exists, it may be appropriate to leave a polite comment stating that you can reproduce it on your system, plus any additional info that isn't already known in the issue thread.
Ask the community: If you feel that you need some help investigating the issue, it may help to ask sc-dev, sc-users, or Slack.
Fill out the issue template: Once you feel that you have information for an effective issue, file an issue on the GitHub issue tracker and fill out the template. Please don't erase the template — it's there to help structure your report effectively.
Be sure to create your issue in the appropriate repository. Note that sc3-plugins are maintained in their own repository separate from SuperCollider.
One ticket at a time: If you have multiple issues to report, please open separate tickets for each one.
We have provided an issue template for you to fill out so that the basic gist of the issue is easily determined at a glance. Please don't erase the template. It's there for a reason.
When an issue involves a crashing or unresponsive executable and you don't know why, providing a crash report can give developers a very helpful first step toward resolving the problem. See "Generating a crash report" below for instructions for your platform.
Here are some tips for creating idiomatic issues. Taking just a little bit extra time will make your issue easier to read, easier to resolve, more likely to be found by others who have the same or similar issue in the future.
- Take some time to learn basic markdown. This markdown cheatsheet is super helpful, as is the GitHub guide to basic markdown.
- Learn about GitHub Flavored Markdown. And if you want to really go above and beyond, read mastering markdown.
- Use backticks to wrap code. This ensures that code will retain its format, making it much more readable to others
- Use syntax highlighting by adding "supercollider" or the appropriate language name after the first "code fence" ("```supercollider")
Before working on a pull request, consider whether it might be better to go through the Request for Comments (RFC) process first!
SuperCollider uses the git-flow branching model. We use the
develop branch for new features, deprecations, and breaking changes, and we use the
3.12 branch for bug fixes for the next 3.12.x patch release that have no chance of breaking anything.
If you aren't too familiar with git, please see our guide: Creating pull requests.
Check the sidebar for a full list of reference documents for SuperCollider development. Here are a few that are particularly good for new contributors. You don't need to read and understand all of this before contributing! We are happy to help guide you through your first contributions. If you run into confusion or need help, you are always welcome to ask.