Quarks that solve common problems

Inspired perhaps by the tail end of the now-closed SC4 thread –

One feature of that discussion was the occasional assertion of some more or less intractable weakness in SC3… but some of these have reasonable solutions in Quarks.

That is… a problem with the Quarks system is that it’s difficult to find out what has already been done in Quarks. (This is not a SC-specific problem – I run into exactly the same problem in both Pure Data and Max – e.g. I was hacking at Pd for a good two years before being pointed toward the ELSE library as the best source for decent oscillators and filters. So my “thesis statement” here translates directly to Pd – intractable weakness: lack of some essential DSP goodies in Pd core; external library solution: ELSE.)

So, for example:

  • Signal routing and order of execution (perennial problem, especially for incoming users): ddwMixerChannel.
  • Voice management (cited in the SC4 discussion as tricky and/or messy): ddwVoicer. (Well… ddwVoicer contains some early code of mine and it certainly isn’t clean. But the primary use cases are significantly easier when calling public methods, compared to hacking up an ad-hoc voice manager.)
  • Flexible architecture: I do actually have a resource-management strategy in ddwChucklib, dating back to 2005. (The comment that “SC is best at fixed architectures” is the specific one that set me off on this topic, since my entire performance practice is based around dynamic instantiation of instruments and players! E.g. Slow paced rainy day improvisation – in which only the main mixer and reverb send channels are preloaded. All other synthesis is dynamically loaded. It’s possible I misunderstood the comment, but… I’ve got 20 years’ work suggesting that flexible architectures are very well workable.)
  • Dynamic patching into synth inputs: JITLib classically, and ddwPlug quark more recently.

Other authors’ work could include e.g. the Connection quark for GUIs, etc. etc.

So I’m thinking it might be productive to collect some of these bodies of work into one place. There are a lot that even I’m not aware of.



Now there is an advanced user tutorial I’d like to see! @Sam_Pluta and @tedmoore live performance instrument are inspiring too…

A sort of “how to get to grips with OO for realz to design flexible architecture performances/instruments” tutorial.

In the meantime I’ll poke at your code. You three are generously sharing it, so it is possible, but it still feels soooooo poweruser that I struggle to get from my mid-level-aspiring-proper-sc-ist to your level :slight_smile:

My chapter in the current SC Book talks about it, and there’s a simple tutorial on my website.



Main thing is, don’t overthink it:

  • Proto object
  • ~prep function to create resources
    • This can also stick constant values into ~event, so that the pattern doesn’t have to
  • ~freeCleanup function to remove the resources upon free
  • ~asPattern to define the behavior

… where people are already writing code to allocate resources, and (maybe) to free them, and Tasks/Patterns. The above only organizes these familiar steps. No need to worry about OOP design for basic usage.


1 Like

A quark I’ve recently found indispensable is SignalBox for e.g. reading a sound file into a Signal and doing fft manipulations on it in the language

I am also a fan of Connection, for streamlining MVC things

And miSCellaneous has so much good stuff, for me especially Fb1 for single sample delays

And, not at computer but I think DayTimer ? recently saved me. For starting a process at a particular time of day

(Can we include server extensions here?)

1 Like

Thanks, didn’t know about it. It’s an interesting approach. One could even extend it to use DoubleArray (64-bit floats).

Many not-so-complicated things could be done in the language as well.

– Connection and miSCellaneous are also good codes.