Inspired by some discussions with @dietcv, here’s a video on one way to do Gabor Lazar/Errorsmith/Kindohm style additive synthesis.
19 Likes
Thanks for these sounds. Additive synthesis like that where one line of code = 60+ UGens is one of my favorite things about SC. And thanks to the others who contributed to this additive approach that has been on the list of late.
Also on a side note, thanks for your coding style. I also code Routine style rather than Pbind style. With Pbinds I always find myself in some kind of …bind… where I can’t make the pattern do what I want (to be fair, I am avoiding regular pulse most of the time). I never have that problem with Routines and basic ListPatterns. Glad to see another user having made this choice as well, as I know it is the minority around these parts (probably for good reason).
Sam
5 Likes
I’m with you, Sam. Routines and Tasks … I have found myself using some pattern classes to generate data FOR synths / notes, but never had a good feel for the pattern classes as event generation.
In events, predefined keys can cause tricky bugs indeed (been there, done that). For this reason, nowadays whenever I use events as “objects” (something I do quite regularly when building bigger systems) I define a method \safeReg first that I use exclusively to add new methods and members, and that will throw an error whenever I try to add something with a key that already has a meaning. But that doesn’t solve the problem you’ve encountered, nor do I see a straightforward way to extend it to your use case.
Could be an idea for SC4 or patterns 2.0: give default event keys a kind of “namespace” so they are not likely to disturb other keys. In the absence of namespaces, a prefix may work as well: Instead of a default key \detune, perhaps it could have been named something like \scpat_detune. (The prefix is ugly on purpose: to reduce the likelyhood that someone else uses it by accident 
) Of course changing that now would break a lot of existing code.
Despite their flaws I still prefer events and patterns over routines to be honest. There’s something “cozy” about the way patterns can be sequenced, combined and filtered.
Blockquote
Despite their flaws I still prefer events and patterns over routines to be honest. There’s something “cozy” about the way patterns can be sequenced, combined and filtered.
Patterns are the best. Nothing against patterns. It is the Pbind auto-linking to synth generation that I find constraining. But I see the appeal. It just isn’t for me.
Finally had some time in the xmas break to check out your videos, @nathan, and I’m totally blown away. So much to learn here. Please keep churning out more of these videos!
1 Like
i think sc does kinda force you to develop your own idiom which i find pretty fascinating
using Routine doesn’t seem well suited for livecoding since you have you continually stop and re-start to update…
I don’t use Routines or Tasks much for this sort of thing, but wouldn’t a Tdef allow one to overcome this, in a similar way that Pdef does for Pbind and Pmono?
would it be possible to extend the amount of partials beyond 64ish using a buffer and Pproto and having the bank piano model with its inharmonicity parameter, the spectral tilt and the comb filter response in the SynthDef? is someone using it for additive synthesis?
A bit of a necro-bump, but: patterns don’t generate synths.
Patterns generate events.
The default event prototype’s default action is to generate synths.
If you use your own event prototype, then the events will do something else. (It’s enough even to override the event’s \play function.)
There’s no auto-linking at all – the imagined constraint simply doesn’t exist.
hjh
1 Like