Norns: SuperCollider

zebra · 2019-07-21T02:27:05.594Z

yeah, exactly, Nes2Square wants a trigger. a ‘trigger’ in SC just means a transition from <=0, to >0. Impulse.kr is one of many UGens that produces signals that go high for one sample / control block, and then return to zero - ideal for trigger inputs.

so, indeed, if you want to “bang” the Nes2Square with a single command, i’d do this:

add a control bus variable to the engine like var trig_b, initialize like trig_b = Bus.control(server, 1)
replace Nes2Square.ar(gate...) with Nes2Square.ar(InTrig.kr(trig_b)...)
in the ‘bang’ command do trig_b.set(1)

okyeron · 2019-07-21T02:30:26.295Z

Rockin. Thank you! That looks like a key peice of info I’d not picked up yet from the tutorials, etc. I’ve been looking at.

Followup - I will want to add 3 more variations of this - Nes2Triangle etc. Do I define those as separate “synths” or is there a better way to do that (like a case statement inside the synth object)?

zebra · 2019-07-21T02:35:07.777Z

up to you. you could use SelectX in the synthdef to crossfade between array of sources, or make different Ugens in one synth sharing inputs but with arbitrary levels, or make different Synths with totally different inputs. different complexity, different limitations, none is ‘better’

okyeron · 2019-07-21T02:38:56.850Z

sorry… one more q:
for trig_b = Bus.control(server, 1); what’s my server here? context?

and does that go inside the alloc { ?

zebra · 2019-07-21T02:44:24.356Z

okyeron:

what’s my server here

sorry, i meant that generically, it’s Crone.server in a norns engine

okyeron:

and does that go inside the alloc { ?

yes that’ll work

okyeron · 2019-07-21T02:49:32.558Z

okyeron:

*new { arg context, doneCallback; 
^super.new(context, doneCallback); 
}

but with this in the engine, is the server variable now context? Or is that something different and I should just use trig_b = Bus.control(Crone.server, 1);?

Sorry again for all the Noob-ness here.

Oooh… found it in another engine example. I want context.server

I got it working!

zebra · 2019-07-21T03:09:01.483Z

rad, congrats

yeah actually you’re right , context.server is more correct than Crone.server. in practice they are the same. but the latter is a global, so it’s worse. my bad.

(i’ve said it before but really should clean up unecessary cruft from Crone ecosystem. it’s left over from the heavier lifting done by SC components pre-2.0.)

shreeswifty · 2019-11-01T03:02:27.914Z

Here’s one i think would make a nice Norns

(
~trig = { |dens=10| Impulse.kr(dens) };
~freq = { MouseX.kr(100, 2000, 1) * LFNoise1.kr(1).range(0.25, 1.75) };
~moddepth = { LFNoise1.kr(20).range(1, 10) };
~modfreq = 200;
~graindur = 0.1;

~grain = { arg envbuf = -1;
GrainFM.ar(2, ~trig.kr, ~graindur.kr,
~freq.kr, ~modfreq.kr, ~moddepth.kr,
pan: WhiteNoise.kr, envbuf: envbuf) * 0.2
};
~grain.play;
)
// change control ugens:
~modfreq = { ~freq.kr * LFNoise2.kr(1).range(0.5, 2.0) }; // modfreq roughly follows freq
~trig = { |dens=10| Dust.kr(dens)}; // random triggering, same density
~freq = { LFNoise0.kr(0.3).range(200, 800) };
~moddepth = 3; // fixed depth
~graindur = { LFNoise0.kr.range(0.01, 0.1) };

// bonus: blend dust and impulse triggers

~trig = { |dens=20, bal=0.2| Dust.kr(dens * (1-bal)) + Impulse.kr(dens * bal) };
~trig.set(\bal, 0.1);
~trig.set(\bal, 0.5);
~trig.set(\bal, 0.9);

ProxyMixer§;

shreeswifty · 2019-11-01T03:30:25.027Z

i am just having some fun running some old supercollider code
Does the Norns SC have Quarks capacity? I would love a BBcut Norns

(
var sf, clock1, clock2;

clock1= ExternalClock(TempoClock(0.6));
clock2= ExternalClock(TempoClock(0.7));

Routine.run({

sf=BBCutBuffer.array([Platform.resourceDir +/+ “sounds/breaks.wav”,Platform.resourceDir +/+ “sounds/breaks2.wav”],[8,4]);

s.sync; //this forces a wait for the Buffer to load

BBCut2([CutBuf1(sf[0]),CutMixer(0,0.5,1.0,-1.0)], ChooseCutProc(0.25,{[4,2].choose})).play(clock1);
BBCut2([CutBuf1(sf[1]),CutMixer(0,0.5,1.0,1.0)], ChooseCutProc(0.25,{[4,2].choose})).play(clock2);
});

clock1.play;
clock2.play;
)

(
var sf, clock;

clock= ExternalClock(TempoClock(0.5));

clock.play;

Routine.run({

sf= BBCutBuffer(Platform.resourceDir +/+ “sounds/breaks2.wav”,8);

s.sync; //this forces a wait for the Buffer to load

g=CutGroup(CutBuf1(sf));

a=BBCut2(g, BBCutProc11.new).play(clock);
});

)

zebra · 2019-11-01T03:50:36.239Z

The quarks syaytem works on norna, sans gui.

But I’m not sure how well it does with installing plugins on arm64

shreeswifty · 2019-11-01T04:13:05.818Z

BBcut is the only “quark” i usually use/install
There’s always something to learn
Those redfred tweets look awesome
i have the schemawounds n stuff too. Back in 2004/5 we successfully [with cylobs help] got SC working on ipad and they were so much fun to layer

shreeswifty · 2019-11-01T04:19:32.977Z

//snakefinger bass

(
SynthDef(“bass”,{arg bus= 2, note=60, dur=0.2, pan=0.0, chorus=0.02,filtfreq=4000, filtq=0.1;
var v;
v=Mix.ar(LFSaw.ar([note-chorus,note+chorus].midicps,[pi.rand,pi.rand], 0.25)); //(([Rand(0.25,0.4),Rand(0.25,0.4)]));
v= v*EnvGen.ar(Env.perc(Rand(0.01,0.02),dur,0.5), doneAction:2);
//v=Resonz.ar(v, filtfreq, filtq);
Out.ar(0,Pan2.ar(v,pan));
}).load(s);

SynthDef(“sweepy”,
{ arg busNumber=0, busInNumber=0, rate=0.5;
var in, proc;
in = In.ar(busInNumber, 2);
proc=Limiter.ar(Resonz.ar(in*8, SinOsc.kr(LFNoise0.kr(rate,0.25,0.3), 2.0.rand, 2000, 2200), 0.4), 0.999, 0.1);

	ReplaceOut.ar(busNumber,proc);

}).load(s);

SynthDef(“delay”,
{ arg busNumber=0, busInNumber=0;
var in, proc;
in = In.ar(busInNumber, 2);
proc=CombN.ar(in,0.25,0.125,1.0);
ReplaceOut.ar(busNumber,proc);
}).load(s);
)

(
var func, fxsynth, fxsynth2;

fxsynth=Synth(\sweepy);
fxsynth2=Synth.after(fxsynth,\delay);

func= {
arg basefreq=36, rate=0.125;
var p, r, durs, pan, ff, fq, chor;

durs= exprand(0.1,0.8);
pan= 1.0.rand2;
ff= rrand(1000,4000);
fq= exprand(0.1,0.5);
chor= exprand(0.01,0.2);

p= Pseq([Pn(basefreq, rrand(9,19)), Plazy({Pseries(basefreq, [-0.25,-0.5,-0.75].choose, rrand(3,18))})],inf).asStream;

r=Routine({

rrand(50,100).do(
{
Synth.before(fxsynth,\bass,[\note, p.next, \dur, durs, \pan, pan, \chorus, chor, \filtfreq, ff, \filtq, fq]);
rate.wait;
});

});

r.play;
};

Routine(
{

10.do({func.value(([0,12,24].choose)+([36,36.1,36.2,36.4,36.75].choose), [0.125,0.15,0.175].choose);

fxsynth.run(if(0.4.coin,true,false));
if(0.3.coin,{fxsynth2.run(fxsynth2.isRunning.not);});

[0.75,2.0,4.0,5.0].choose.wait
});

}).play;

)

andrew · 2019-11-25T00:32:36.263Z

Approaching: norns

I guess I finally have to learn supercollider?

Yes. It’s fantastic. The initial learning curve is rough, but the IDE and built-in help have improved a lot since I started a few years back. The nice thing is that it scales very quickly. Say you have a simple sine wave:

{SinOsc.ar(220)}.play;

So, that looks like a ton of syntax to create a single-channel sine wave. Now, my favorite aspect of SuperCollider is “multichannel expansion,” or a quick way to create numerous objects. If you modify the line with the [] multichannel syntax:

{SinOsc.ar([220, 330])}.play;

This will put a 220 Hz sine on the left channel and a 330 Hz sine on the right. You can load this up with as many channels as you please. Panning that may seem like a nightmare, but the Splay uGen will help situate each generator in the stereo field:

{Splay.ar(SinOsc.ar([220, 330, 440, 660, 880, 110]))}.play

That will give you a rich, wide additive wave. For reference, we are spawning six oscillators in one line of code. Once you learn more, you can use faster methods for populating all of the channel arguments, adding MIDI inputs, turning that one line into a reusable SynthDef, etc. Start simple

Speaking of which, cmd+. is perhaps the most important key combo to learn while learning SuperCollider. It immediately kills all active synths. When learning SC, it’s super easy to write something jarringly loud, so keep that key combo handy. When I start experimenting, I start with a

{WhiteNoise.ar()}.play

to test how loud things could be expected to get. This can save you from a traumatic headphone accident when changing uGens.

cmd+D is also great. It opens the help document for whatever uGen your cursor is currently on. If you have your cursor on “SinOsc”, it will bring up the SinOsc docs. The help documents are interactive. You can modify and execute the examples as though they were in the main editor window.

I just bumped the SC tips thread: Supercollider tips, Q/A

Here’s an interactive homework assignment that I turned in early in grad school when learning how to generate patterns in SC: Supercollider tips, Q/A

I’m definitely buying a Norns once the page goes live.

Oh, one weird tip: Don’t buy The SuperCollider Book as your first stop. It was written a few SC versions ago, so a lot of the code is out-of-date. In particular, I had a lot of “fun” when trying to execute the Microsound chapter examples a few months back. One of the uGens used in every example was no longer in SC 3.8. It’s a great book to have eventually as you get more comfortable, but it will cause a lot of headaches for beginners.

Approaching: norns

Bloody nice one. @trickyflemming

I would add:

cmd + enter executes one line of code,

or put your code between ( ) to execute it all together,

cmd + shift + D to search the documentation, or

cmd + D to search for current selection.

and, importantly, like @trickyflemming mentioned, cmd + . kills all active synths.

SuperCollider comes packaged with a bunch of documentation, including some really good tutorials to get you started. Dive in .

For those who learn better from video (although already linked in the Supercollider tips, Q/A) this also seems like an appropriate moment to recommend Eli Fieldsteel’s SuperCollider Tutorials . They are really good: well-paced, enlightening.

One last thing that I wish someone told me when I was just starting out: if you are interested in live-coding , you will find everything you need by searching for JITLib in the SuperCollider documentation.

Approaching: norns

D’oh! I really should have mentioned these. Excellent recommendation. This, in my opinion, is the single best resource for starting to learn SC. They’re long videos, but worth it. Videos 0-8 will likely be the most important for Norns. 3, 4, & 5 are the keys for most of SC. 8 is useful if you plan on building anything using samples or recording. After video 8, it dives into MIDI, sequencing, external control, and composition. Depending on how the Lua end of Norns looks, these might not be as critical.

Approaching: norns

For anyone wondering: Here is the playlist of the mentioned tutorial videos. Thank you a lot for pointing them out! I just started going through these and they seem very helpful so far.

dropping these old nuggets here. any other pointers for first time engine-ers ?

here’s the manual

also: I already like sc a lot

okyeron · 2019-11-29T21:13:13.461Z

Is there an existing engine that would be a good template to use for adapting an “audio processing” supercollider script to norns?

Looking for the basic framework needed to deal with the incoming audio.

rdfm · 2019-11-29T21:17:03.268Z

would this work?

github.com

monome/we/blob/master/lib/Engine_SimplePassThru.sc

Engine_SimplePassThru : CroneEngine {

	var amp=0;
	var <synth;

// this is your constructor. the 'context' arg is a CroneAudioContext.
// it provides input and output busses and groups.
// see its implementation for details.
	*new { arg context, doneCallback;
		^super.new(context, doneCallback);
	}

// this is called when the engine is actually loaded by a script.
// you can assume it will be called in a Routine,
//  and you can use .sync and .wait methods.
	alloc {
		//Add SynthDefs
		SynthDef(\passThru, {|inL, inR, out, amp=0 |
			// read stereo
			var sound = [In.ar(inL), In.ar(inR)];

This file has been truncated. show original

Justmat · 2019-11-29T21:26:50.406Z

This is one I put together, using the decimator ugen.

github.com

justmat/otis/blob/master/lib/Engine_Decimator.sc

Engine_Decimator : CroneEngine {
  var srate=48000, sdepth=31;
  var <synth;
	
  *new { arg context, doneCallback;
    ^super.new(context, doneCallback);
  }

  alloc {
    SynthDef(\Decimator, {|inL, inR, out, srate=48000, sdepth=31|
      var sound = {
        Decimator.ar(SoundIn.ar([0,1]),
          srate, 
          sdepth
        ); 
      };
      
      Out.ar(out, sound);
    }).add;

This file has been truncated. show original

shreeswifty · 2019-11-30T02:30:49.641Z

i really want to make a Gnedyn Norns application but with sound coming from norns but with selectable distrubutions of stochastic LFOs going to crow
Is there a tutorial for Nornsing a SC patch? i guess i can adapt one i just dont know how to get started

glia · 2020-01-02T18:46:15.248Z

away from norns but just attempted to wrap Convolution2L ugen into an engine

it’s my first time trying so i’m curious…
does anybody spot obvious errors? i expect this will be a learning experience

github.com

zunaito/kyber/blob/master/lib/Engine_Kyber.sc

Engine_Kyber : CroneEngine {
  var <synth;

  *new { arg context, doneCallback;
    ^super.new(context, doneCallback);
  }

  alloc {
    SynthDef(\Convolution2L, {
      arg in, out, kernel, trigger=0.0, framesize=2048, crossfade=1.0;

      var sig = {
        Convolution2L.ar(SoundIn.ar([0, 1]),
          kernel,
          trigger,
          framesize,
          crossfade
        );
      };

This file has been truncated. show original

inspiration is taken from a supercollider based effect built for 2018 rbma participants

from public info and emails with a member of the design team this is what i can gather about how it works:

user records a sound snippet to one of 20 slots (max length 20s per slot)
the sampled audio from current slot is fed into a granular engine
select a grain (ranging from 7-700ms in size) which is then convolved with the real-time audio input
the spectral overlap of the two sounds is output (think…grain timbre w/ input envelope)

additional details from the devs:

the convolution is done using Convolution2L since it allows for seamless transition between grains (convolution kernels)
it doesn’t support proper time-partitioned convolution so to keep the input-output delay small they manually delayed the input signal and fed it to several Convolution2L that all ran at a small framesize (& got a different part of the grain as convolution kernel)

two challenges they faced [1] each grain needs to have an envelope applied [2] the energy of the output needs to be controlled…

they used a short single sided hand window to fade in/out
they ended up normalizing with the RMS of the grain (capped at some higher / lower limit)

Any time a new grain was selected (either by shifting the position of grain window or by changing its length), it was prepared (applied window, calculated gain, loaded into all convolves) and then a trigger signal was sent to all convolvers to switch to the new grain

@andrew I’m trying to work out whether all of that is possible with just one Convolution2L in a norns engine (my guess is no) or whether i’ll need to hack an existing granular engine like Glut to handle some of the features

zebra · 2020-01-02T19:55:47.499Z

i can probably help a little this weekend. Sounds like they did stuff that isn’t directly possible with built-in grain UGens.

I’m still not totally clear in the spec. Every time a grain fires, instead of being played back directly, it should be used as real-time convo kernel on live input? Or both? Or some kinda crossfade? (Feel free to dm or email)

nitefish · 2020-01-02T19:58:40.029Z

Typo on the first alloc: convulution2L ?