Norns - can a norns script switch engines

dansimco · 2020-03-11T03:22:38.396Z

Is switching engines within a norns script supported and/or advisable? For example, having a parameter which switches between passersby and an polyperc.

dan_derks · 2020-03-11T03:47:25.653Z

sorta supported with thoughtfulness (@ppqq has an approach he’s been hacking on) , but not ideal:

Norns: development Development

yeah, it’s not a two-way binding. when you load a script, the script loading module checks if engine.name is defined. if it is, it loads that engine. when the engine is done loading, low-level lua callback is fired and the script’s init is run. when i made the low-level stuff i thought a single lua script might want to switch engines. but when the script management stuff was built up, the assumption was made that this will not happen. it is one of many undocumented assumptions that you will r…

dev discussion is still happening, though. hope this helps!

zebra · 2020-03-11T03:53:41.904Z

I would say: yes, it totally can. But it is less convenient and you have to manage more callbacks yourself. I posted examples of this which you can find by searching (can’t show now, I’m on a phone.)

And, for example if you store engine name in a param, you will have to read that / use fallback at the top of the script before setting engine.name

Also, kinda obviously, your script can’t make parameters that map directly to engine commands, nor use engine utility libraries to do so (e.g. passerby.lua or whatever)

Instead you will have to make abstract parameters and map them to engine xommand on the fly.

Finally, since there is not a standard interface for e.g. voice management of polyphonic engines, you may need actually different logic to control stuff.

Like dan says, were thinkign about how to make these steps more convenient. But I can put together an “inconvenient” example with a real script (meadowphysics, say) when I get a moment.

zebra · 2020-03-11T03:58:55.029Z

gist.github.com

https://gist.github.com/catfact/0441990d762657c4a9c02c062ba77f9c

Engine_TestNoise.sc

// CroneEngine_TestNoise
// variante of TestSine, for switching

// Inherit methods from CroneEngine
Engine_TestNoise : CroneEngine {
	var <synth;

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

This file has been truncated. show original

Engine_TestSine.sc

// CroneEngine_TestSine
// dumbest possible test: a single, mono sinewave

// Inherit methods from CroneEngine
Engine_TestSine : CroneEngine {
	// Define a getter for the synth variable
	var <synth;

	// Define a class method when an object is created
	*new { arg context, doneCallback;

This file has been truncated. show original

engine_switch_test.lua

-- engine switching test

-- key 2: select TestSine
-- key 3: select TestNoise

-- enc 2 up: auto-switch (as fast as possible)
-- enc 2 down: stop auto-switching

local engine_loading_flag = true
local autoswitch = false

This file has been truncated. show original

Example showing the callback logic you need to add.

Iirc, poly perc and passerby are examples of different voice interfaces: trigger and gate.

toneburst · 2020-03-11T11:00:32.722Z

I don’t think there’s anything stopping you creating a Supercollider engine script that itself is able to swap between different sound-creating/processing algorithms on the fly.

It would make things easier if the same controls could be mapped to similar parameters of the available “sub-engines” though.