Approaching: norns



go for it
[ ]


is there an sc realization of bytebeat?



Norns could be a good platform to have an application that applies a genetic algorithm (with crossover and mutation and fitness selection being input by the user using a knob/external control) to bytebeat equations… :slight_smile:


oh boy I just thought of this

I can’t wait to use the grid for some pin matrix style patching on the norns…

drool overload


@shreeswifty has done some for organelle / pd


if norns plays nice with pd things will be very interesting.
That’s all done with expressions which i am sure will work in SC too



There’s not one that can be written in C-style code as far as I know (apart from using normal SynthDef syntax, i.e. zebra’s response), but there are a handful of UGens that do instruction-based synthesis. Check out Instruction, and BBlocker BBlockerProgram. Dfsm and Dtag do sort of similar things, but they’re demand-rate so I’m not sure how well they would work to actually synthesize sounds?
(The above are all in sc3-plugins)


You could cheat using jack? There is a utility called jack-stdin that can pipe data from the command line into jack which would be fitting and in keeping with the original.

Once it’s in jack, it should be easy enough to get it into Supercollider.

I wonder how trivial it would be to make a Supercollider UGen that reads data from stdin from an arbitrarily provided executable?


spent most of my day harvesting bits of knowledge from farahnaz hatam
and looking at power banks to extend range of the device
and mulling whether to ask about running shlisp somehow on norns w/o shnth

but mostly reading sc stuff to help prepare my brain


not really the right thread, but:

  • shlisp itself, sure, you can easily compile and run on most systems. however, this is just the programming language interpreter.

  • the actual sound engine for shbobo shnths is called wanilla, and it consists of a number of opcodes hardcoded in assembly for the arm cortex-m3. this will not work on other processors without a lot of porting work.

  • maybe relatively little work for raspi, since it is also an ARM part and i’m sure supports most or all of the same instructions. still, all the hardcoded memory/flash layout stuff would have to be redesigned.

i suppose you could use norns as a fish-soup generator / patch loader for a connected shnth.


it can be done, here’s something i made a while ago with a really, really stupid trick to generate samples with arbitrary iterated function (single-sample buffer, arbitrary impulse, and! the impulse can run at the samplerate (i think? certainly at nyquist) i think just Dfsm and would work nicely together)\cubicMapVoice, {
		arg buf, out=0, level=1.0,
			atk=0.001, rel=0.1, gate=1,
			hz=110, oct=1, a=3.4,
			lpf_hz_mul=2, lpf_hz_add=0;
		var x, y, duty, env, output;
		duty = 1.0 / (hz * oct);
		x = Dbufrd(buf);
		x = (a*x*x*x) + ((1.0-a)*x); // cubic oscillator.
		y = Dbufwr(x, buf);
		output =, 0, y);
		output =, hz * lpf_hz_mul + lpf_hz_add);
		env =, 1.0, rel), gate:gate, doneAction:2);, (env * output * level).dup);	

this is, of course, super inefficient.

actually probably a little funky because of sclang’s virtual terminal wonkiness (?) jack-stdin definitely the way to go i think


It’s academic, but I’m not sure I follow, I don’t understand what sclang would have to do with it? Wouldn’t we be able to write a UGen in C++ and use popen or similar?

In practice I’m sure there are a ton of reasons why it’s a terrible idea and will cause the server to crash constantly, but I always did love playing with BitWiz on my phone…


you’re right, i’m being dumb, definitely popen in the ugen, and this is a terrible idea anyway


You probably can’t use popen in a ugen directly - it’s almost certainly not realtime safe. Stdin data would have to be read from a different thread and heavily buffered, but it would be possible. It would be significantly easier to simply dump bytebeat’s output to an audio file and read it in (which I believe could be done as the file is still growing, using the DiskIn UGen).

I just checked and Dtag doesn’t work at demand rate because it prints to stdout, which obviously balloons when run at sample rate (speaking of not real-time safe…). That’s probably easily fixable, if someone wants to write a bug against it.


If you could use a FIFO it would be perfect. It would be pretty easy to wrap the entire process of compiling the C, creating the FIFO, etc in a pseudo-UGen.


It’s totally possible that sleexyz’s bytebeat example in sclang is much more performant than the same thing written in straight C (a lot of core UGens are more optimized than anything but carefully hand-coded vectorized C), so if the bitshift/logic/math ops in sclang can produce the desired output, it’s probably a lot easier AND faster than cobbling together a different workflow.
Though you don’t get the visceral thrill of dumping out audio directly from main(). :slight_smile:


–quietly looks into ordering “popen the ugen” bumper stickers–


oooh boy I hadn’t even considered the possibility of running shlisp on norns



would anyone be interested in a small minimal chess app for norns? it will be a while til i have the money to even get a norns but i thought it might be cool to have a chess (or go??) game running in the back ground that you could play with folks… i am a dork i know :stuck_out_tongue: