Steal this Sound

Creative Process Thinking About Music
1

Not sure if Thinking About Music is the right place for this. There probably needs to be a synthesis section.

Anyway the idea is to create a preset library with decent sounds for SuperCollider. Anything goes within reason:

  • Post Recipes that you want converted into SuperCollider
  • Link to tutorials that you think could be useful.
  • Post code!
  • Improve somebody else’s code (but explain why).

Useful effects are also cool - but maybe a different post for them.

Also think about what a preset manager would look like? Should there be a GUI? Does it store synth defs, functions? (how do we support SynthDefs and things like JitLib)? Tagging? Descriptions? How do you search for a likely candidate. How should you store your presets. I’m happy to write the code for this, but I want something defined before I start.

Also, should a preset library separate out SynthDefs from parameters for those synthdefs? Is that desirable, possible, too complex? And how would that work.

1 Like
2

I’ll start with this very unconvincing cello.

Taken from Welch’s cookbook via this blog post: http://aempass.blogspot.com/2014/09/analog-and-welshs-synthesizer-cookbook.html

(
SynthDef(\cello1, {
  var freq = \freq.kr(440);
  var amp = \amp.kr(0.5);
  var gate = \gate.kr(1);
  var osc1 = Pulse.ar(freq, 0.1);
  //var osc1 = Saw.ar(freq);
  var osc2 = Pulse.ar(freq);
  var lfo = 0.1 * SinOsc.kr(7.5);
  var out = (osc1 + osc2) * 0.5;
  var aenv = EnvGen.ar(Env.asr(0.06, 1, 0.3), gate, doneAction: Done.freeSelf);
  out = DFM1.ar(out, EnvGen.kr(Env.adsr(0, 3.29, 0.78, 3), gate).linexp(0, 1, 40,  10000), 0) * aenv;
  Out.ar(\bus.kr(0), out * (1 + lfo));
}).add
)

(
Pbind(
  \instrument, \cello1, 
  \degree, Pseq([0, 2, 4, 2], inf),
  \octave, 4,
  \dur, 1,
  \amp, 0.4
).play)
4

sccode.org has a really phenomenal system of managing code snippets, with search, tagging, votes, etc. And, we have a browser built into the IDE and sclang. One straightforward path:

  1. Expose sccode.org in the IDE help browser, and as a standalone window in sclang (this probably amounts to some formatting stuff, some minimal UI around search, and maybe some shortcut ways to insert a snippet into your project).
  2. The definition of what a “preset” or a “synth” might be is pretty open-ended in SuperCollider. If we wanted to have a database if JUST e.g. relatively standalone SynthDefs, factored according to some kind of loose standard so they’re widely usable, we could tag these on sccode so they can be easily searched from whatever our browser front-end is.
5

That’s a good idea. The only thing that worries me about sccode.org is that it’s dependent upon one guy. If for whatever reason he loses interest…no more synths.

The other possible issue is curation. I think if there’s going to be a collection of suggested synths, then there should be a minimal level of curation. At the very least it should be discussed, and synths should meet some minimal standard.

My preference for a standard would be: the synth should follow guidelines for parameters that work with patterns (this seems pretty minimal) and the example code should be vanilla for novices (e.g. maybe a function, with minimal examples of creating a synthdef and a proxy with it).

Then some demo patterns so it’s easy to get a sense of what the synth does/sounds like.

Nice to haves: A brief description of the synth (phat bass), additional tags that follow some kind of standard (bass) and maybe some additional details on how it works, or interesting tweaks.

6

Agreed - but it’s much easier to talk to him (he’s still around :smile:) to make sure we have a plan for handing off / preserving things, than it is to build a NEW place to host code snippets with all of the features that sccode.org has.

The curation component is interesting - we don’t want to expose users to low quality stuff. But, the more we delineate what does and does not count, the more we make it off-limits to some of the huge variety of workflows in SuperCollider. What about basic guidelines, ala:

  1. Executing code should return a SynthDef
  2. The SynthDef should have ControlSpecs for every parameter to define an acceptable range.
  3. The SynthDef should not depend on things outside of the core lib or sc3-plugins.
  4. The SynthDef should have reasonable defaults that allow it to make a representative sound with no arguments.

I think with those rules, we get things that are actually minimally unit testable (we can run each of them, validate arguments / specs, and even run the synth to make sure it works), are not total black boxes, and are open-ended enough to fit in most of the common ways of working (JITLib, cruciallib, patterns/events, plain old Synths, tidalcycles or third party scsynth clients, etc.).

I still think that works with sccode.org - add a tag to signify that something is a “plain SynthDef” or “preset ready” or whatever we want to call it. One in a while, there will be one that isn’t properly specified or doesn’t work, and we can remove the tag or have someone fix it. it would also work with other kinds of hosting, but again - I feel like we’d end up just reproducing things sccode already does, or adding a lot of overhead (we can barely keep up with github PR’s right now - the last thing we need is 50 auto-generated “SynthDef preset” PR’s that need to get merged into a “preset repository”).

7

Yes this makes sense. Those guidelines seem very reasonable. Can always adjust later if it becomes a problem.

My thought for hosting was just create a quark - but SCCode is better. Lot more visible and easy to link to.

By review I just meant people post them on here first really.

8

IMO:

Firstly, I don’t think that Steal this Sound is a good name because it is both a name of a book and a built-in example.

My suggestion is that we use the tag SynthDEFaults as a way to organize it in sccode.org .

For the beginning it think that we should use tag hierarchy based on tradicional instruments:

  1. Piano
    1.1. Grand Piano
    1.1.1. Concert Grand Piano
    1.1.2. Baby Grand Piano
    1.2. Upright Piano
    1.3. Fortepiano
  2. Organs
    2.1. Tonewheel Organ
    2.2. Reed Organ
    2.3. Pipe Organ
    …
    .
    .

First things first: we begin by uploading our SynthDEFaults into sccode.org with the proper tags and structure, then go on testing and improving the model, then we can go further and think about a quark or plugin.

Just some ad-ons :

1.Executing code should return a SynthDef;
2.The SynthDEFaults should have ControlSpecs for every parameter to define an acceptable range;
3.The SynthDEFaults should not depend on things outside of the core lib or sc3-plugins;
4.The SynthDEFaults should have reasonable defaults that allow it to make a representative sound with no arguments;
5. SynthDEFaults symbol should be always be like \babyGrandPiano_ZeCraum_001 ;
6. SynthDEFaults must be written using NamedControl Style;
6.1. Additional arguments besides from amp/dur/pitch default events must be written as local variables and must have comments;

9

@capogreco Could you create a specific category here in the forum to hold the discussion? I would suggest the name SynthDEFaults

10

ok so I’ve restructured things a bit:

Learning Resources is now just Resources, with Learning, Libraries and Quarks, and SynthDefs subcategories.

1 Like