Advice/tips on maintaining larger SuperCollider projects

Questions
1

Hello everyone

Several times now I have tried (and largely failed) to create and maintain larger SuperCollider systems for myself. I have thought a bit about why I find it difficult and what can be done about it and I was wondering if anyone out there has nice tips on being able to maintain a larger system of sorts for a longer time?

I had a few experiences lately where I got back (after the summer vacations) to using and maintaining systems of my own where I had for example started work on a feature and not finished it (and then forgotten what that feature was, how far I had gotten etc) making it very frustrating for me when I just want to make music with it. And then, additionally SuperCollider’s error system becomes increasingly harder to use the more complex the system becomes in my experience. I hope I have learned my lesson, so for now these are the things that I have forced myself to do in order to maintain some kind of order and hopefully find myself in this situation less often:

  • Use a version control system like GIT
  • Keep the main branch of the project clean - this should always be able to run and compile as it is.
  • Keep a seperate branch(es) for developing new features or changing existing ones, and then when they are done, merge them in the main.
  • Use unit tests to automatically test the features of your system so that you can easily detect when something breaks.

Most of this I guess just comes down to good software practice but I unfortunately have a tendency to neglect some best practices when it comes to my own stuff for myself. Hopefully not anymore.

What’s your top tip for maintaining a larger system in SC ?

1 Like
2

Great topic! I do essentially the same things (though I could stand to be more disciplined about writing tests) and experience essentially the same kinds of friction around them. Other things that have helped me are:

  • Use git tags to designate the version of a codebase that was used for a particular performance or recording.
  • Maintain some rough documentation / examples / todo lists as you go. I mostly work in nvim with scnvim, so I like vimwiki for this, though I suppose that it would probably be better practice to write schelp files directly.

Looking forward to hearing more suggestions from other users!

2 Likes
3

I really like the tagging idea!

4

Thanks! I originally came to SC without a programming background and started using git several years ago after having toured a piece realized entirely with SC for the first time.

I have the usual bad computer musician’s habit of constantly tinkering with the set during whatever downtime I have on the road and after a couple terrifying close calls in which I discovered at soundcheck that I’d broken something and had to race to troubleshoot it before doors, I came home thinking “there has to be a better way!” Enter git.

I think I’ve said this elsewhere on this forum before, but in my opinion (and I say this as a musician who is not “really” a developer), one of the greatest strengths of SC compared with most other computer music tools is that to a large extent your technical difficulties become the technical difficulties of software development and you can take advantage of tools and resources like git that, while not specifically designed for music, can solve problems that one encounters as a musician in novel and exciting ways. (“I need to render a 20-minute version of this piece as it would have existed in October 2018”, “I think I can improve the spatialization of this multichannel effects return in time for tonight’s performance, but I’m not 100% sure it’ll work”, etc.)

1 Like
5

Great tips!

I’m struggling a lot with the same.

What has helped me is to have some kind of central lookup system of recources (resource could be a library of samples or wavetables, a handy function, a physical controller, outboard fx etc) and in this lookup system be able to ‘deprecate’ the use of a resource with a warning the same way I can do with methods. Then it’s much easier for me to remove an old piece of my project without making a complete mess.

I also try to not put too much functionality inside patterns, even if it can be very convenient. Very often I find the Pattern classes to be great as a ‘music notation’ tool, but if they grow too big or complex it’s much harder to see the musicality in them. A benefit of trying to keep the patterns simple is that it’s easier for me to just focus on the music when that is called for without breaking stuff.

2 Likes
6

It may sound very boring but (as a musician with no programming background) i try to stick to standarts i made up myself. I had some informatics guys rofl about my bad style…but who cares. It helps a lot ) Also i try to reduce complexity even if that is what supercollider is absolutely fantastic for.

7

I’d also like to go back to this point:

TL;DR Use to-do list software. It’s better if it has rich features for calendars, item status, embedded notes etc. – I use org-mode in Emacs.

In 2010, I was working with three dancers and a video artist on a 45-minute work that was meant to be interactive (but ended up not being so… anyway…). Also at that time I was relocating to China – so, much of the workflow was that I would send sketches to the team by e-mail, and wake up the next day with comments, and new ideas to incorporate… sometimes a lot of them. It got overwhelming very quickly.

I was using Emacs heavily at the time, so I started putting some of these notes into org-mode outlines.

  • A-B-C priorities.
  • User-definable status tags e.g. “todo,” “inprog”(ress), “done,” “canceled,” anything you need, with active statuses shown in red and completed statuses in green.
  • Arbitrary tags for outline headings, e.g. :bug:, :maybenot: etc. – you decide the tags (not limited to a predefined set).
  • Calendars: three kinds of timestamps – generic, scheduled, deadline.
  • “Agenda” views to search for and display relevant items (all customizable by emacs-lisp).
  • It’s an outline structure, so everything can be nested.
  • Every outline heading can contain as much free text as you want, including bullet and numbered lists.
  • Outline headings fold, so you can hide what you’re not working on at the moment.

So if somebody had an interesting idea, I could estimate when it would need to be done and put in a TODO with a deadline. Then, a week or two before the deadline, the calendar view would show this item “due in 5 days.” Or, if I started on something but had to switch to something else, I could leave notes in the tree explaining the current state.

Similarly, when I was starting on chucklib-livecode (the core is now about 10000 lines), I had outline sections for brainstorming design, implementation plan, and to-dos.

You get a nice endorphin hit when you switch an item to “DONE” :smiley:

I wouldn’t globally recommend org-mode to everyone, because Emacs’ key bindings are weird. If you are already accustomed to them, org-mode is genius level software – I can’t say enough good about it. It’s incredible. If you don’t want to deal with emacs, there are other options.

Offloading organizational tasks outside of your brain is much more valuable than you might expect.

hjh

1 Like
8

Have a magic shortcut on your board… & two files show:

  • TODO.txt
  • IDEAS.txt

Damn… I would almost work in emacs just to see what you’re talking about.

What’s out there for vim etc.

9

Yeah, I don’t think I’m alone among committed vim users in feeling a bit of envy there.

Think I mentioned it above, but I quite like vimwiki for maintaining project notes. Been using it for years.

10

This is great wisdom, James. And yes, I’d wish we had something like this in VIM. I have been using task warrior (and the vim plugin for it) to do something like this but I’ve never been fully satisfied with it, but maybe it’s time to revisit that kind of organization to keep me sane.

11

An SCM, I use fossil as it has a wiki and a forum. Then “literate programming”

12

Damn… I would almost work in emacs just to see what you’re talking about.

What’s out there for vim etc.

Not vim, but you can use evil-mode for vim keybindings in emacs for a hybrid experience. Doom Emacs has excellent defaults and evil mode support, + easier config.

1 Like