many people, on discovering the quarks feature, immediately install dozens of quarks that seem interesting.
unfortunately, the reality is that the small size of the SC community has limited resources. people get busy and they move on from projects, and quarks fall out of use and bugs don’t get addressed. many quarks are incomplete, unreliable, and/or unmaintained.
i’m not trying to be a hater here. it’s understandable — hell, i’ve produced no shortage of abandoned class library code. plus, not all quarks are bad, and some quarks are useful despite their flaws. the point is not to put quarks or their authors on blast, but to acknowledge that there are risks to incorporating third-party code into your work. whenever you add a quark as a dependency, be aware of what can happen:
- any code you write that depends on that quark is less portable and harder to share with other people.
- some quarks add overhead to compilation and class library initialization.
- some quarks make dangerous overrides that silently change core behavior and/or introduce forward compatibility headaches.
- quarks can conflict with each other and break class library compilation.
these aren’t just theoretical. these are actual problems users have run into as a result of eagerly installing a whole bunch of quarks.
some of the pain points with quarks are side effects of SuperCollider not having namespaces or dynamic class library compilation. that’s an issue that, unfortunately, will have to be addressed on the scale of years. (remember that sclang has 27,000+ lines of code with no unit tests, and SC development is done entirely by volunteers ) until then, i have a few workflow recommendations to help deal with quark problems and prevent them from happening in the first place.
Help! A quark broke my class library!
i’ve dealt with a few bug reports where a user’s class library won’t compile due to quark-related issues, which barricades them from using
Quarks.gui to uninstall them. luckily, this an issue you can easily solve yourself.
whenever sclang boots up, it looks at an
sclang_conf.yaml file, which (among many other configuration options) contains a listing of directories that sclang compiles. that’s how quarks are installed: by adding to this listing. Edit→Preferences→Interpreter is essentially a GUI frontend to
so, to fix a quark emergency, first carefully inspect your error message and see which quark may be causing it. then go to Edit→Preferences→Interpreter and simply remove the directory of the quark.
Prevention of future issues
first, i’m asking you right now: do you have more quarks installed right now than you have fingers? maybe take a moment to disable the ones you aren’t using to help minimize the above risks.
second, consider doing a quick quality audit of the quarks that you do rely on. if something doesn’t seem reliable or well-maintained, or contains lots of features that you don’t need, remember that you always have the option of taking it into your own hands. copy out the parts of the quark that you like and install them into your personal class library, and modify them to your fancies.
finally, rather than installing large numbers of quarks in a single configuration, i recommend making use of different interpreter config files (see Edit→Preferences→Interpreter) so you can switch between sets of quarks desired for individual projects, and the damage done by a single malfunctioning quark is lower. a fictional example:
sclang_conf_bare.yaml: no quarks, just the default class library. sort of a “safe mode.”
sclang_conf_live.yaml: installs some class library code for live sets and some MIDI control related quarks
sclang_conf_studie_iii.yaml: installs some code / quarks for a specific work or set of related works
quarks are useful, but installing them has disadvantages. you’ll prevent frustration if you use quarks responsibly and be aware of the issues that can arise when depending on third-party code.
these days i actually work with no quarks at all, just a library of my own. my workflow and musical practice are different from yours, so take this as a suggestion, not necessarily advice!
i’ll readily admit that the way SuperCollider handles all this isn’t ideal. aside from the well-known limitations of sclang, a big part of it is that the UI/UX that the IDE provides for this is pretty makeshift and has a lot of room for improvement. proposals for how SC developers could make this experience easier for users are very much welcome.