Hi all,
during the next months i’ll start building some instruments with SC and i’ll use those both in my live (a combo of Live and Max4Live stuff) and in my studio production enviroment (Reaper, tons of VST, Reaktor, some Csound, Pure Data and Max).
Since i want all these new SC made stuff to be controlled by MIDI and OSC and to be used with some poly/mono voice stealing, i’m learning Voicer. I’d like to know some opinion about pros and cons of using SynthDefs or Instr in such a context. Many thanks!
i used Instr for a bit but switched back to SynthDefs soon after. Instr is less well-maintained and can be awkward to integrate into contexts where SynthDefs are expected. i didn’t find its benefits all that useful in the long run.
also part of it is that i’m mostly quark-free these days due to bad past experiences relying on third-party SC code. ymmv.
2 Likes
Thanks Nathan for your opinion!
What i see as really interesting about Instr is that you can feed it with “generic” arguments at creation/play time. Numerals and functions returning numbers as in SynthDef but even whole ugens both ar and kr or even other Instr or SynthDefs. This seems very flexible to me. But maybe i’m not so fluent with SynthDef and (apart of using Busses either ar and kr) they seems more “limited” than Instr. Any other opinions are wellcome! Thanks!
I started off using Instr extensively, thinking that I could build large instruments from modularized components.
It didn’t work out that way, and I’ve switched back to SynthDefs.
Instr’s modularity seems to be very tightly tied to crucial’s Patch/Player architecture. I was never quite successful in using it as anything other than a synthdef-builder.
hjh
1 Like
Thanks @jamshark70 for your opinion.
I wonder if in terms of efficiency is a good idea to do SynthDef with ar busses feeding arguments. So in theory they can accept ar signals and kr “promoted” to ar
I am pleased to hear from other users about this!
I also have had some problems in using instr, and I have thought the reason might be the lack of my coding ability.
However, it seems there to be the limitation of instr.
Could the details on the limitation be included
- in the future version of SC help documents
or - in the Learning category of this site?
1 Like
Instr: Some history is relevant. Instr/Patch were originally developed for SC2, which had a totally different architecture: one massive Synth, which could use a Spawner.ar unit to add what we now call “synth nodes.” Spawner would evaluate its UGen function for every event, so it was easy to pass “anything” into a synth argument and it would be automatically embedded into the new UGen graph.
In the early days of SC server, Felix himself posted more than once how hard it was to try to squeeze the old code structure into the new server architecture (less embedding, more bus connection). I’ve looked at the code – that’s no joke. That he achieved any backward compatibility at all is impressive. But the side effect is that I sometimes feel Instr/Patch have some hidden gotchas, and it’s hard to document them because they are hard to predict.
My personal experience was that the friction between Instr/Patch’s assumptions and sclang/scsynth’s assumptions was, for my purposes, insurmountable. This was after many years, of trying first to build a modular Instr library, then stepping back from that toward a library of larger, single-unit Instrs, and gradually using those Instrs less and less. I can’t speak to anyone else’s purposes.
hjh
1 Like
Synth modularity is, in a lot of ways, harder in SC server than you’d expect.
The first question is, are you interested in building larger SynthDefs out of modular components, or in modularizing the signal processing (so that modules can be swapped in and out at will)?
They are good at different things. I usually have a lot of “notes” happening (including polyphony). Single SynthDefs make more sense for this, but I don’t have a good modular approach (meaning, lots of flexibility in passing values or promoting arguments to synth controls). SynthDef.wrap is a start, but it’s very easy to have name conflicts. So I usually just end up writing big SynthDefs.
With buses, you have to worry about allocating new buses for every “voice,” and getting the nodes in the right order.
hjh