Uninstall your quarks

Resources Learning
1

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 :slight_smile: ) 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 sclang_conf.yaml.

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

Conclusion

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.

3 Likes
2

As Nathan said, there are many quarks that are unmaintained, or poorly organized.

Many of these quarks have useful pieces of functionality buried in them, but are burdened by other unrelated or highly user-specific functionality. Others may be in good shape if they were given a quick sweep and some minor fixes. If a quark you use has not been updated in a while, take it upon yourself to put some effort into cleaning it up:

  • Install it with a new version of SC, step through its help files and functionality to make sure everything works without issue.
  • Add some simple unit tests to make it easy to verify it’s working in the future.
  • Propose these changes as a pull request to the original repository, and contact the original author.
  • If a Quark seems hopelessly broken, contact the author and file GitHub issues - or, change the description in the quark file to include “NOT MAINTAINED” and propose it as a pull request.
  • If you see a piece of functionality that would be useful outside of the Quark that contains it, turn it into a standalone Quark!
    • Make sure you test the new standalone Quark WITHOUT the Quark you removed it from, to ensure it’s working correctly.
    • Take a look a the “Using Quarks” help file for help on creating a new Quark. The QuarkEditor quark can make building a quark easier as well.
1 Like
3

All warnings mentioned here are absolutely legitimate. As an author of a Quark which seems to be used by some people I’d like to add some remarks.

Of course I try to write my quark extensions in a way to avoid breaking things:

.) I don’t overwrite core stuff
.) I check class names to avoid clashes with other quarks
.) For private methods I prepend the prefix “miSC_” to reduce the probability of name clashes with other quarks
.) If my extensions alter core behaviour they must explicitely be turned on (e.g. the EventShortcuts functionality)

In spite of all measures, unforseeable things can always occur, this is inherent to an open source project like this one.

If you encounter any incompatibilities of miSCellaneous_lib with other quarks or any changes occuring in usage with certain SC versions (haven’t had the time to extensively test with 3.10 yet) please let me know. If incompatibilities with other quarks can’t be avoided I can at least place a remark in the README.

PS: Currently MethodOverride.printAll shows up a self-overwrite of miSCellaneous_lib’s ‘lincurve_3_9’, it stems from a copy and paste error and doesn’t harm.