Hi everyone,
my question, regarding 2 types of Synth construction may comes from a previous post, and on various aspects of usability. i will try to explain and maybe someone else have asked before using other terms.
ok, right now, when i need a special synth (3 osc, filters, lfos,etc…), i am building it directly in Sonic pi… which is quite easy and sounds great… obviously, i control params from variables and treat them as i want.
Now, i am coming to synthdef, in supercollider… i am building my first synths from a couple of hours and i asking myself, what are the benefits to build a new synth in sCollider if it is to get the same result?
So, can you help to look at the differences, in terms of operability, ressources usages, etc…?
PS: i totally agree that if i want a granular synth or something of this kind which is not based on the included generators in Sonic Pi, i will go for supercollider, but (for exemple) if i want to build a clone of my Nordlead, i suppose i can do within sonic pi, without trouble… what do you think ? is there any advantage to work on supercollider to make such synth ?
well, i hope it was clear enough to get some answer from you guys…
bye
Others may have different things to say on this, but here’s a few observations from me:
Composite synths made purely from Sonic Pi’s language might be easier for those new to coding and/or Sonic Pi to understand - SCLang can be a bit confusing at first.
I may not fully understand it, so someone more familiar the matter is free to correct me, but my impression is that in certain circumstances, a dedicated SynthDef might be more performant than a composite synth made with Sonic Pi - though in some cases, the difference may be negligible. The more complex the synth is however, the more it might be worth building in SCLang - particularly since IIRC the SynthDef compiling process is sometimes able to optimise certain combinations of UGens in the synth definition behind the scenes.
With SynthDefs, there is also the factor of old Ugen/Supercollider compatibility, as you found out recently!
As for the amount of code written in Sonic Pi to play one or the other of composite Sonic Pi synths or Supercollider Synthdefs: If you compile a Synthdef, yes, you have to write all of the SynthDef source code, but then you might only have to write one single synth ... to play it in Sonic Pi. For building them purely in Sonic Pi, you potentially have to write more code in Sonic Pi to play them, as opposed to playing a SynthDef directly. You would have multiple synth .... and with_fx .... statements, potentially a bunch of control ... to affect modulation of the inner components etc - which can add up to quite a few lines of code. To play multiple instances of the composite synth, you could still extract the definition into a function and call the function several times - so that’s not a huge issue. In that regard, it’s really just a matter of personal preference - whether you want most of the synth definition in Sonic Pi, or SCLang. Sam had thoughts about making it simpler and perhaps shorter to write composite synth definitions in Sonic Pi - so that might affect the decision if it ever happens.
Composite synths built with Sonic Pi are trivial to share and use (just like any other Sonic Pi music script) as they are plain text. SynthDefs are still easily shared between people, but require a little more fiddling to use in Sonic Pi - they can be loaded in without integrating into the documentation, parameter safety and editor autocompletion systems, (the simplest and most accessible way) or by updating Sonic Pi’s source code and recompiling the app to properly integrate into these systems. Being able to type less to trigger a synth, and have weird opt values rejected is always useful I think! IMO this integration is the factor that still makes SynthDefs more useful for me - particularly when used in a live-coding context.
100% thanks you very much, that was my day´s doubt, when i started to build a custom synth in Scol. and i wanted to share with a friend who is also starting to work on Sonic Pi… thats why, should i share a piece of sonic pi code OR/AND a synthdef that no much people will be able to modify it
if anyone else has a different view, please, share it and give some advices… bye
uriel
- particularly when used in a live-coding context.
thanks you very much, that was my day´s doubt, when i started to build a custom synth in Scol. and i wanted to share with a friend who is also starting to work on Sonic Pi… thats why, should i share a piece of sonic pi code OR/AND a synthdef that no much people will be able to modify it 