sorry about the context switching. your original question was “is all of sclang available.” to which my response is “yes, and sc3-plugins,” with the (probably obvious) qualification that you can’t use SC graphics or UI classes. those rely on graphics frameworks (Qt, etc) that don’t exist on the norns system.
we don’t have a way to draw to the norns screen directly from SC. (we could add it, but it would break the norns menu. we’d want to add additional glue for lua to hand-off screen control to the engine, and take it back in menu mode. maybe this is a good idea, maybe not, i’m open to opinions but again, tend to think we should try to use the lua side for UI and compositional logic, even if we’re really used to sclang.)
we also don’t have a way to read encoder and key movements directly in SC. here i’d really like to draw a hard line, and keep enc/key handlers hardcoded through matron, so the norns menu can make appropriate use of them (saving and restoring callbacks.) if you want to just directly send encoder deltas and key states to an SC engine, you can do so:
(Engine_MyEngine.sc)
Engine_MyEngine : CroneEngine {
alloc {
this.addCommand(\enc, "ii", {
var which = msg[1];
var delta = msg[2];
do_something_with_encoder_movement(which, delta);
}
}
(msyscript.lua)
engine.name = 'MyEngine'
enc = function(n, d) engine.enc(n, d) end
in the lua script, enc is a special global variable, and the menu system will save and restore callbacks defined this way when toggling in and out of menu mode.
(and similar for keys)
so: “having encoders do math and stuff” - of course, its necessary to perform computations in response to encoder movements. we’ve built out some methods for mapping controls in lua that closely parallel ControlSpec and related sclang classes, and can be easily plumbed into the “parameter” and “parameter set” abstractions in lua.
we’ll will continue to build this out as well, and i imagine some useful abstractions could be broken out like long-presses and momentary mode toggles.
i tend to think this is the best place to do all your musical parameter logic, and engines should accept “raw” values like frequency.
but other options are available and not a big deal.
re: jukeboxers, files:
i tried to show a simple example of loading a file this with my silly sample-flapper script. for a more sophisticated approach see mlr or playfair scripts - the former uses the SoftCut engine and the latter uses the Ack engine. they tie a little deeper into some path-handling abstractions and also store sample paths as script parameters.
in both cases, lua side doesn’t actually load sound files, it just sends paths to the engines. (the engines have load commands accepting sound file paths.) matron does link libsndfile just so you can query soundfile durations from lua.