SC vs Modular Synths (Eurorack)


#21

joesh lol :smiley: yes, artist can be sort of chaotic sometimes, but that’s fine! The piano recording episode sounds interesting (you’re a music teacher!!! you lucky man! :slight_smile: ) and reminds me that we are surrounded daily by an amazing array (no pun intended!) of wonderful sound sources, if only we are good enough to realize that :wink:


#22

that sounds really interesting, though maybe too advanced for my current level of knowledge.

The sound file sounds amazing and I hope I can soon cover the gap so that I can enjoy fully your words.

Thank you!


#24

James, that sounds great. It also reminds me that I seem to remember a very simple line of code that could be added at the end of a synthdef and which made the various args into sliders. However, I can’t remember what it was, or where I found it - either in the sc book, or maybe in an example?

BTW, it isn’t varGui - this one I remember.

Thanks in advance - if my explanation brings up any ideas?


#26

Probably you mean the metadata arg, used with key ‘specs’. I meanwhile got the habit to almost always write SynthDefs with metadata specs.

With standard lib you can use ‘makeGui’ (not widely used this way it seems), with miSCellaneous installed ‘sVarGui’.

// using 'myFreq' here, as for 'freq' and 'amp' there are already global specs defined
(
SynthDef(\test, { |myFreq, amp|
	Out.ar(0, SinOsc.ar(myFreq, 0, amp))
}, metadata: (
	specs: (
		myFreq: [20, 10000, \exp, 0, 400]	
	)
)
).add
)


SynthDescLib.global[\test].makeGui

\test.sVarGui.gui

#27

Daniel, you’re my saviour, brilliant!

Big thanks - Joe


#28

I have a fairly large modular synth setup and also spend a lot of time with SuperCollider. I find myself using SC a lot for control, sending MIDI to various modules, as well as signal generation, particularly for playback of samples. My modular ends up seeing more use for effects, processing, mixing. But these are trends, not necessarily rules. And as I get better writing synthesis code perhaps more will end up coming from SC.


#29

I think I introduced it badly… the intent is actually to keep each module as simple as possible.

(It’s mostly a documentation problem – when the semester is over, then I can work on a manual of sorts – until then, it looks “magical” just because it isn’t explained properly.)

For a quick example, using that system, you would p = JITModPatch.new and, in the patch code window:

// JMInput.ar is part of JITModular: Module's audio input
// .play() connects this module to the speakers
~out = { JMInput.ar }; ~out.play(vol: 0.2);

~osc = { Saw.ar(440) };  // simple oscillator

~osc <>> ~out;  // connect to output

~filter = { LPF.ar(JMInput.ar, 2000) };

// modules can be chained in series
// you can read the synth structure directly from the code
~osc <>> ~filter <>> ~out;

// add a control input
~osc = { |freq = 440| Saw.ar(freq) };

// swap in a different type of oscillator
~osc = { |freq = 440, width = 0.5| Pulse.ar(freq, width) };

// for GUI: set an appropriate range for 'width'
~osc.addSpec(\width, [0.01, 0.5]);

// swap in a different filter
~filter = { |ffreq = 2000, rq = 1| RLPF.ar(JMInput.ar, ffreq, rq) };
~filter.addSpec(\ffreq, \freq, \rq, [1, 0.02, \exp]);

Each line is very simple. (The fact that I used it yesterday to build something more complicated doesn’t mean that you are required to do lots of complicated things with it.) What I wanted to accomplish with this system is to break up the process of designing a synth so you can focus on one piece at a time, and experiment with each piece as its own unit.

It works well for that (though there are still some issues trying to use it in the classroom…).

hjh


#30

Concerning the original question, trying to emulate the specific sound quality of a modular device by software means is probably the most difficult thing because of analogue idiosyncracies.

But debatable if this is eligible or necessary. Personally I like to use SC in order to obtain things that are hardly or impossible with analogue devices, the digital space of possibilities feels infinite, but this alone is not an argument pro or contra per se. Luckily however worlds can be linked also.

Not being an expert with analogue devices I find them inspiring, e.g. I’ve written the smooth wavefolding classes contained in miSCellaneous quark because I stumbled across analogue wavefolding following Buchla. It’s an anti-aliasing variant of SC main lib’s Fold UGen, pictures of some options on a sine source might be self-explaining:

https://github.com/dkmayer/miSCellaneous_lib/blob/master/HelpSource/Tutorials/attachments/Smooth_Clipping_and_Folding/fold_examples.png

Furthermore feedback behaviour is different in the digital domain, e.g. I’d be interested in phase-locked loop examples in SC. I asked some days ago on the mailing list and got no response, maybe anyone here has some experiences ?


#31

Dear James, thanks a lot for your explanation. Things now are clearer, and I can perceive the sense of it all better now.

Thanx! :smile:


#32

Yes Daniel… absolutely useful and amazing :)))) thaaaaaanks!


#33

I bought my first hardware synth 10 years ago, and 5 years later I got my first eurorack modules and it kept growing until 6 months ago, at that time I started to learn SC and Pd.

On functionality aspect one of the big advantage on SC is you can do polyphony with ease, and even multi channels, while eurorack is more lean toward to monophonic patch, or you may have a wall of modules to do the task.

On my experience, it’s all about the form factor. If I sit in front of my eurorack system, I might think about how to do what in a confined condition, or most of the time I randomly patching for no actually goal, sometimes I ended up with sometimes cool or nothing, and to me it is the most rewarding moment on eurorack. However, I believe many eurorack people do, I would think of getting new modules to do something more or something my current system unable to do. If you can afford then it is okay, but might lead you to a rabbit hole where I witnessed so many others do: getting new modules for inspirations.

My opinion is if you can afford, get start on eurorack, but be patient, one step at a time.


#34

Yes Vinc, I absolutely do agree with you when you write that relying ONLY on the tools

you don’t play and compose as J. Hendrix did by simply buying the same guitar, do you? :slight_smile:


#35

Hi Jam,

I just wanted to tell you that I’ve been fooling around a bit with the JITModular library a bit… fantastic!

Yes, now I really understand the “modular” thing and it seems to offer a totally different approach, very rich and stimulating…

… thank you once again for your precious advice :slight_smile:


#36

Wow ! Looks very handy. Can you have several outputs with JITModular ? Like a sequencer which would output triggers and notes ?


#37

Have a look at AE Modular.


#38

Currently, in JITModular, it assumes audio-rate proxies should be stereo, but you can pre-define the number of output channels:

~audio2 = { DC.ar(0) ! 4 };
StereoNodeProxy.nil(localhost, nil): wrapped channels from 4 to 2 channels
~audio2
-> StereoNodeProxy.audio(localhost, 2)

~audio4.ar(4);  // pre-define
~audio4 = { DC.ar(0) ! 4 };
~audio4
-> StereoNodeProxy.audio(localhost, 4)

.kr proxies are free, as many channels as you output.

But IMO the better way to sequence in JITModular is with patterns.

~player = \psSet -> Pbind(
	\skipArgs, [\list, \of, \symbols, \to, \ignore],
	\degree, ...,
	\dur, ...
);

… which will treat any gt inputs as gates and t_trig inputs as envelope triggers.

hjh


#39

Thanks a lot James for your detailed explanations !


#40

Concerning sequencing and modular design you might have a look at the PbindFx class from miSCellaneous_lib. My primary concern was to sequence events and fx data, but PbindFx is not restricted to the notion of source and fxs, together with fx data you can sequence arbitrary graphs of nodes (patches of modules in a general sense, but it needs SynthDefs with some conventions). As the syntax only uses indices, their content can be exchanged on the fly – as well as the graph pattern itself (see PbindFx help Exs. 10 for modulation graph sequencing and Exs. 7 for replacement).

Syntax example for sequencing graphs with keyword ‘fxOrder’:

\fxOrder, Pn(Pshuf([
	`(0:1, 4:1, 1:6),
	`(0:1, 5:1, 1:6),
	`(0:2, 3:2, 2:6),
	`(0: 1, 1: [2, 3], 3: 4)  // arrays cause parallel routing
	`(0: [1, 2, 3], 2: [4, \o], 3: 2)  // graph example below, 1 and 4 go to out as not defined separately
]))

PbindFx_graph_3b

The bus management is done automatically, all buses can be multichannel, sizes should fit but are checked per event.


#41

SC does two things wayyy better than modular:

  • much more sophistication in your control side sequencing, using Pdefns and Patterns in general
  • iteration / expansion, which you don’t get at all in modular

conversely, modular has access to weird / talkative / squonky analog circuitry which would be inefficient to try to replicate via code. below you can see modules like the Doepfer’s WASP filter, PLL module, vactrol LPGs / VCAs, a spring reverb, and some metasonix tube modules, all of which would be, although not impossible, pretty bloody difficult to exactly replicate in supercollider.

imo, a very clear division of labour is possible here. if you are going to use both (with a DC-coupled sound interface like the ES-8) there is not much point in buying control modules (as supercollider would almost certainly be able to whatever it is that the module does, but better).


#42

Thanks a lot, capogreco!

Well, the pic is nice and inviting (is that your gear?) and, yes, I can see from your and other’s replies that there’s a fair area of intersection between the SC and Mod/Synth domain, although they don’t superimpose perfectly.

That’s fair enough and, besides that, a very stimulating thread for me and, I hope, for somebody else as well… :slight_smile: