SuperCollider 4: First Thoughts

Since we’re daydreaming, I’d personally like to see:

  • Runtime class definition, not so much for workflow reasons as for metaprogramming reasons. I also think that SC as a whole would benefit from there being a more natural “onramp” to new users learning to formalize their ideas as classes. The right implementation (imo) would look at what many of them currently try to do instead (usually difficult to scale/maintain hacks involving dictionary-based “pseudo-objects”) and bridge the gap between that sort of thing and the “standard” process of writing compiled classes.

  • A more modular architecture for sc in general, with a smaller “core”. This would ideally make it easier to create “distributions” of sc for particular use cases, and done right, could also make the distinction between the “core” and “periphery” of sc clearer to new users than it currently is.

  • A move (back?) to a more editor-agnostic paradigm, maybe focusing on maintaining a language server rather than an IDE.

  • Improved package managment. In particular, I’d love to see a simple way to have packages include both class definitions and ugens, with some provision for build scripts, pre/post-install hooks, etc.

Beyond that, I agree that being able to over/undersample parts of a synthesis graph arbitrarily would be very useful, I think the client/server paradigm is correct and valuable, and I agree that stronger typing would be great as long as it’s optional – I’d imagine it working similarly to the way type annotations currently work in Python.

4 Likes