Approaching: norns


#1139

Awesome I was wondering about that. Could it also transmit midi with this?


#1140

Anyone else want nanoloop for norns?


#1141

go for it
[ https://github.com/yoyz/picoloop ]


#1142

is there an sc realization of bytebeat?


#1143

#1144

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:


#1145

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


#1146

@shreeswifty has done some for organelle / pd


#1147

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

pp


#1148

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)


#1149

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?


#1150

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


#1151

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.


#1152

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 Duty.ar! the impulse can run at the samplerate (i think? certainly at nyquist) i think just Dfsm and Duty.ar would work nicely together)

	SynthDef.new(\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 = Duty.ar(duty, 0, y);
		output = LPF.ar(output, hz * lpf_hz_mul + lpf_hz_add);
		env = EnvGen.ar(Env.asr(atk, 1.0, rel), gate:gate, doneAction:2);
		Out.ar(out, (env * output * level).dup);	
	}).send(s);

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


#1153

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…


#1154

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


#1155

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.


#1156

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.


#1157

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:


#1158

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