Hi, I have finally had some success compiling my first synthdefs. I have even figured out how the gate thingy works, which is quite handy when you play notes from a keyboard and want the synth to enter its release phase rather than just kill it once you release the key. I have not found much about this on in_thread, though I doubt this is a new thing. But if anybody wants more details, I’ll be happy to provide them. Just post a reply here, and I open a new topic for this.
I think that several people in this forum manage quite a bit of the Supercollider language, and I have also noticed that there have been several questions / initiatives regarding how to add new synths to Sonic Pi. There are some nice synthdefs out there on the Internet (most referring directly or indirectly to the sources of “Steal This Sound”), but apparently there is a license issue. Also, in several threads I have read about Sam’s intention to move off Overtone / Clojure and go to synthdefs in the Supercollider language. Here are my questions:
Can someone help me understand the license issue? The sources from “Steal This Sound” are GPLv3, and according to the Sonic Pi license page there are already some parts of Sonic Pi that ship under this license. Synthdefs are mentioned explictly in the main source section, which has the MIT license, but why can’t the synthdefs be moved to be covered by GPLv3 as well? Any new release should serve as an opportunity for that. This way, some of us could pick up all the cool synths from “Steal This Sound”, adapt them to SP and make them avaible for upcoming releases.
If the above is no solution, would it be possible to create an additional synthdef directory and put it under GPLv3?
How is the status of replacing Overtone synthdefs? Is this still an objective? If so, how could we go about it?
I can answer this one at least. As far as I know, there is no plan to directly replace any Overtone synths. We have preferred for a little while now to do all new synth development with SuperCollider directly. Others are free to still use one or the other if they wish, but we find SuperCollider much simpler to work with, and it allows some things that Overtone does not.
extending our set of synthdefs is something I’d absolutely love to see and hugely encourage. Compiled synthdefs are really small files, so we could easily throw in 100s more synths designs without much affect on the app download size.
The original Steal This Sound book is an excellent set of recipes for synth designs and a number of the existing Sonic Pi synths are actually based from ideas in the book.
Bringing in synth designs that are licensed under GPLv3 is totally fine and works within the licensing structure of the app. I think it would make sense to keep them in a separate directory just to make things clear but other than that I see no issue at all.
@ethancrawford’s description of the Overtone situation is definitely correct. We have no intention of getting rid of Overtone synthdefs, rather we enable (and encourage) new synths to be defined in the SuperCollider language as that’s the de facto standard.
In order for a synth to be considered for inclusion, it needs to have an envelop that self-kills the synth on completion and needs to output a stereo signal to an arg called out-bus. Also, the synthdef shouldn’t use any of the supercollider randomisation ugens as this breaks the deterministic properties of Sonic Pi. If these are necessary, then there are some Overtone randomisation ugens that I designed that use the deterministic randomisation system in Sonic Pi which could be ported to SuperCollider and used.
Hi, thanks to you both! I was wondering how that Overtone thing could be solved. In the end it would be a classical migration project where you put a lot of work in and in the end you get what you had before, and still the backward compatibilty to be solved.
So, adding and adapting new ones is the way to go. Great, I’ll give it a try in the next days and post a couple of syntdefs here for review, before messing things up with a PR.
Regarding the requirements: I think preparing the signal with Pan2 creates a 2-channel stereo signal, and if the envelope goes to zero and has a suitable doneAction (e. g. 2) it terminates. However, I believe randomisation is important. I have tested with the “Winwood Lead” and it does use a randomised LFO:
lfo = LFTri.kr(lforate,Rand(0,2.0)!2);
Is that what you mean and what should be avoided? It did not seem to cause any problem when using it in SP. Should it have?
@bmx - what we mean in this case, is that any kind of randomisation needs to be deterministic. (Ie, if you run the same code several times, each time produces exactly the same result. This allows us to do things like guarantee that if you share your composition with someone else, when they run it, they will hear exactly the same result that you originally created. (SuperCollider’s randomisation uGens are not designed for this).
Having said that, it is not difficult to implement deterministic randomisation in new Sonic Pi SynthDefs - it’s a matter of porting the related Overtone functions to SuperCollider’s language.
The functions buffered-coin-gate, deterministic-rand, deterministic-lf-noise0, and deterministic-lf-noise1 can be fed with an external seed (i. e. from SP), and this would be the part to port over to plain SC lang. Is that correct so far? Regarding the difficulty of porting – unfortunately, I am not Clojure-savvy. It would be great to see what Overtone makes of the Clojure code in SC lang, but I believe that Overtone compiles straight into SC binary. Any hint regarding the porting? Otherwise, I could try taking the randomness out of the synthdefs. In some of them they could be mimicked by synth params.
BTW: I think the Hoover synth uses a plain Overtone ranged-rand. Is that deterministic as well?
Ok, well, I need to slightly correct myself - it is not very difficult to implement the deterministic randomisation functions in SuperCollider.
Taken as complete objects, they have no directly corresponding representation in sclang. These Overtone objects are cGens. They are collections of uGens, which are the building blocks that SuperCollider understands. Porting those cGens is a little fiddly, as there is no directly corresponding object.
Anyway, when looking to port Overtone code to sclang in general, here’s a rough process I usually take:
look for the names of SuperCollider uGens that were originally ported to Overtone, so that I know which ones I need to use in sclang again
work out what rate the Overtone function (uGen/cGen, etc) is designed to output at (audio rate, control rate…)
and lastly, the slightly more complex step - translate Overtone’s functional style syntax into SuperCollider syntax. (It definitely helps here if you understand prefix notation - where the functions are structured like (Operator Value1 Value2) or (+ 1 2) for example)
So for example, (I think) this is close to how the buffered-coin-gate might be ported to a SuperCollider function:
~bufferedCoinGate = {|buf, seed, prob, trig|
var phase, v, res;
phase = PulseCount.kr(trig) + seed;
v = BufRd.kr(1, buf, phase, 1);
res = v < prob;
res;
};
I think it might still be missing one or two things, given that the Overtone cGen specifies that it itself is control rate (:kr), but I think the above is at least most of the way there.
It looks to me like that in turn is just using clojure’s (rand), so as far as I can tell, no. (Whether this is intentional and/or something we’d want to change, I’m not sure).
Hi @ethancrawford, that helps a lot. My last question (or so I hope) would be how to tell which buffer to read and who takes care of storing a value in it. Regarding the former, reading “fx.clj” I understand that a synth takes a hidden param rand_buf (hidden in the sense that is does not show up in the user documentation) which defaults to 0. For the latter, I suppose that the SP runtime creates a buffer at index 0 (and others?) at some suitable point (starting SC?) and stores a random seed there. So when a synth runs, it can just assume that reading buffer rand_buf the way you have described above it will get the random seed. Correct?
@ethancrawford, great, that answers all. At current, I only need the deterministic random number, so I think I can even go without the phase and the PulseCount. I need to test and recompile a little and then come back here.
I still need to fix the amplitude for the bass synths … looks like they lose some of it when they are mixed. The repo contains the definition files, the compiled files, and an updated synthinfo.rb, although I have made my changes against 3.2_devel. Will update soon …
Only Winwood Lead has randomness, and it is almost unhearable, so I have made tests randomising the note played. That worked. I still have a question related randomness: When I play several tones one after the other, the random number always yields the same number which in some cases is what is desired, but I think, here this is not so. If one calls rand the seed is advanced, and on the next call of rand one gets a new number. On the next run, however, one gets exactly the same sequence.
The synth does not advance the random seed, so it will always yield the same value, unless the seed param is set. Is this desired? How could I advance the seed, so that the next tone sounds just a little different, but still in Sonic Pi’s deterministic fashion?
Looks good!
I have a couple of small comments.
There are several changes that we might suggest, depending on @samaaron’s preference for consistency across user-contributed and built-in SynthDefs:
Most of the time, we have expressed filter cutoff values in the synth/fx metadata as MIDI values rather than Hz directly
rq has often been expressed as res
(my preference) - writing multiple word opt names like lfowidth etc in snake case is a bit more legible than a single word
Since things like lfowidth, lforate and lagamount are not part of the set of ‘default’ SynthDef opts that Sonic Pi knows about, in order to document them, you’ll need to add entries into the hash in each synth’s specific_arg_info method.
Regarding the randomness, I would have thought the way you describe it happening is exactly how it is intended - unless I’m misunderstanding something. Perhaps other core team folks have further comments?
Hi, that can all be managed. Yes, the params’ units and names should be consistent with the other synths, of course. Currently, I am trying to get v3.3-BETA-4 up on Ubuntu 18.04. Getting tons of errors, so far no success. Will make the changes for the synthdefs tomorrow.
Edit: Got it up and running. Need to make friends with it now and include the synths.
Well … it was late, and I was tired. The correct question would be: What have I done to break the setup? The answer for this question would be: Apply the modifications and the build script I used for 3.2_dev.
I have cloned the repo again and simply followed the instructions and it worked like a charm.
Sorry for the false alarm …
Edit: I did find a couple of things, nothing to do with Sonic Pi directly. I have opened another thread just for reference.
OK, reworked the Winwood lead to @ethancrawford’s suggestions, dropped the lagamount, as I could not bring it to produce any hearable or visisble (with plot) effect. I have also made lfo_width and lfo_rate slideable and updated synthinfo.rb to the 3.3_beta version, including full info about this synth. Hope to do similar things for the bass synths tomorrow.
Absolutely, that is the plan! I’ll try to finish 2 others (bass_foundation and bass_highend) and submit a PR. Any time constraints, i. e. is that a candidate for 3.3 still?
Edit: Just put Bass Foundation into my repo, and descriptions in synthinfo.rb. Hope to add Bass Highend tomorrow and then submit the PR.
and include the synths.