its impossible to answer without knowing your metrics for success.
the lua interpreter and the supercollider synthesis server each get approximately a full 1.2 GHz core on the compute module.
on the synthesis side, i get about 200 voices of a basic sinewave + panner + amplitude synth before i hit dropouts. (this is the builtin wavetable-based sine osc)
(this engine will attempt to allocate 1 million voices, but will fail after ~2K due to supercollider’s internal node count limit.)
Engine_ManySines.sc:
Engine_ManySines : CroneEngine {
var n, t, g, r, s, amp;
*new { arg context, doneCallback;
^super.new(context, doneCallback);
}
alloc {
s = Server.default;
amp = 0.01;
n = 1000000;
t = 0.25;
g = Group.new(s);
r = Routine { n.do { arg i; var hz, pan;
hz = 55 * [2, 3/2, 6/5].choose * (2 ** (4.rand)) + 4.0.rand;
pan = 1.0.rand2;
{ Pan2.ar(SinOsc.ar(hz) * amp, pan) }.play(target:g);
postln([i, hz, pan]);
t.wait;
}}.play;
}
free {
g.free;
r.stop;
}
}
manysines.lua:
engine.name = 'ManySines'
init = function()
end
on the lua side, your main metric of success is probably timing. if you do nothing but crank out (say) MIDI notes from a metro, you can expect extremely low jitter (<1ms) and basically zero drift. if your script does other stuff then there is no limit to how poor you can make the timing performance. filesystem access and extensive screen drawing are what typically sink a script’s timing performance.
depending on what exactly you’re doing you may run into other undesirable sources of timing variance, such as the latency introduced by OSC or the fact that softcut commands are only executed on audio block boundaries.
i would expect the norns computer to be comfortably over-specced for any “dumb controller” role.
i guess i should say that if you want to develop things at a lower level and forgo using our stack, there is more compute headroom available.
oh, yeah: and turning off wifi will help things run smoother as well if you are really trying to push it.
