In the referenced thread, Sam mentions that Sonic Pi doesn’t try to munge parameters on supercollider synths because it doesn’t really know anything about them unless there’s metadata to inform it. I would suggest that maybe we could turn that logic on its head an declare that a supercollider synth has to conform to a specific set of known parameters. Having made that a priori declaration, Sonic Pi can just assume conformance and munge away.
Admittedly, I’ve only briefly looked at the internal code involved, so I could be overlooking something obvious, but as it stands adding new synths that could be used where built-in synths are currently used is a couple of orders of magnitude harder since one has to 1. build the synth in supercollider, 2. add the appropriate metadata, 3. rebuild Sonic Pi. Then, for there to be any hope of others using it, 4. convince Sam to accept the new synth into the official Sonic Pi code base.
It would be really nice if you could 1. build the synth in supercollider, 2. publish it on Github (or other fine public repository), 3. publicize its existence on this forum.
Chapter 6 of The Manual - Writing SuperCollider Synths For Sonic Pi sums it up:
In a future version the code will be rewritten to read all the synths and their metadata from a directory (or set of directories) at boot time and then it all becomes possible.
At the moment you only need to recompile if you two things:
the parameters to appear in the help/autocomplete
SonicPi to transform chords into multiple calls to the synth (you can still decompose chords by hand - bit smelly, but…)
The Manual intends to be the place that:
defines how a synth should be written
explains how to do it
contains user-contributed synths that can be pulled from github and hot-loaded
Thanks, and I get that. I’ve just spent the time working my way through your Manual which is where the question came from.
I’m actually suggesting a different approach that seems like it would be an easier matter of code. From what I can tell, the only real issue is that a synth must define an out_bus and note parameter. It looks like everything else is somewhat optional. If so (and even if not, then add more required paramerts), then a well-behaved synth is one that defines those to parameters correctly. All others that the synth defines will be assumed to be optional.
