norns: ideas

i’ve done something based on this idea using compass!

it’s great


I have a softcut “jogwheel” sketch started which can use norns encoders or arc.

It works ok, but needs some more finesse I think.

Was waiting on the newest norns update because it uses the waveform display. Also there’s still some bugs.

(I also made some custom hardware to do the sc1000 thing)


i’m wondering - would there be interest in having “global script extension” global parameter? what i mean is essentially being able to set a global norns parameter that will load a file into every norns script that you open. the loaded file should then toggle some new useful behavior onto of that script, independent of any script (but possibly useful for most any script!).

what do i mean? i’ve now encountered a use for this twice so i’ll just explain in two examples:

  1. i have a midi2osc library that you can import into any script and then it will utilize some settings to convert a midi command into multiple midi commands through osc. for example, i can press one midi key to simultaneously enable reverb, compression, and all the settings for both at the same time. to use this library i edit every script which i want to use with it with similar two lines added at the top (below). instead it might be useful to select this library from a list of “global script extensions” so the two lines of code don’t need to be added manually.
local midi2osc = include('midi2osc/lib/midi2osc')
  1. i am working on a full dump/load library that you can import into any script and make a working dump of everything (softcut, parameters, etc.) and be able to load everything back (into softcut too!). the structure of this library is the same as the preceding one so it requires adding in two lines at the top of every script you want to use it with.

now, me personally, am pretty fine adding two lines to the scripts i want to use these functions. maybe most people are so this is unnecessary. but having a “global script extension” as a global parameter might assist in others who don’t want to edit all their scripts if they want this functionality. perhaps there are other “global extensions” that people might envision to take advantage of this, too.

some problems right away with this are that the “global extensions” likely need to avoid manipulating softcut/engines to prevent collisions with the host script. it adds a whole new layer of complexity when debugging problems. there are probably other problems as well.

is this useful? does the usefulness outweigh the problems? in any case, happy to discuss this idea :slight_smile:


I’ve been wondering if the global parameter option you suggest would be useful for those of us who use midigrid with alternative grid hardware that can use it - it would save having to go through every script that needs to use midigrid every time they are updated, for example.


i’ve also imagined something like a .bashrc but for norns - just a little user editable snippet in dust that runs ahead of every script load (i think a single file would invite more configuration than a param). of course it could break things sometimes, but it would be very handy for libraries like you’re describing (midigrid, arcify)

also a potential solution to the arc proposal here @dan_derks


TL/DR: though it is a fine idea in theory, consider that adding an “extension” is really the equivalent of just running a patched version of ~/norns/lua that is unaffected by updates. for pretty obvious reasons, this is an undesirable option compared to (A) submitting the patch upstream if it has widespread utiltiy, (B) confining it to a script if it is niche, and IMHO should be a method of last resort.

we are cautiously building out some mechanisms for global customizations in lua via a .matronrc. the primary reason for this is to more gracefully support hardware customization without patching the norns system sources. but other global behaviors may make sense there as well.

the caution is important - @infinitedigits as you’ve implied, too much of this kind of thing impinges on the efficacy of the platform as a known quantity against which scripts can be developed and shared.

e.g.: you may start with adding a preamble for total save/recall of parameters and softcut buffers, but sooner or later you may want to programmatically effect these actions from within a script. now the script can’t be shared without caveats. [“it could break things sometimes” is not a very good thing to have to say about a new feature.]

i’d instead ask whether the behavior is a good candidate for global inclusion by merging it upstream; in this specific case we seem to be steadily extending the amount of stored state per script in any case, so your efforts may well be appreciated there.

in other words,

if the answer seems to be “yes,” then the best action is to consider just bringing the feature upstream. for exampe @andrew, arc behavior in the issue you reference is very obviously (to me) something that should just be a part of the main norns system, to be evoked when an arc is attached - and that of course is why it’s on the issue list. (IOW, i don’t see the value in forcing the decision on how the arc interacts with parameters onto the user. and on a technical level, we already have a default arc handler that arc-aware scripts must override - we are simply proposing a more useful behavior than a no-op for the default handler.)

it may interest you all to know that startup.lua was initially conceived (by me, maybe not by everyone on the project) as the place where custom startup behavior would happen. (but i also assumed that scripts would be much less monolithic.) that would still be the place to shim in things that you want to execute in a clean lua environment, with all processes alive but before event loop starts ticking.

clearly, there is no technical obstacle to explicitly executing logic from ~/dust there, or before script init. instead it’s an ecosystem design consideration which leads to dependency management and many more potential support challenges. (think about, i dunno, Skyrim mods or something.)

so, my personal opinion is that in the abstract i think it’s a fine idea to support something like ~/dust/data/user.lua, but support for norns is already challenging and we arguably rely too much on the willingness of users to engage in very technical troubleshooting steps, so pragmatically i think a conservative approach is correct. and since the heavy lifting of support is being done by monome HQ team, this kind of decision is theirs to make.


as i thought about this more, my 2nd example (dumping/loading state) really needs to be merged upstream and not added as a super-complex add-on which would have to consider every particular script’s state management. so that leaves only one example i have…

yeah i think this cost is not to be underestimated. i cannot come up with more than those two examples, of which one i want to retract. i was interested in seeing whether there were many other such situations. it sounds like @DoS has another situation that could benefit from a startup script, though it sounds like a fit for .matronrc.

it seems like this idea needs many more use cases which is totally fine by me :slight_smile:


Absolutely agreed - the Norns dev team obviously have a huge amount to do already.


I’m just about to do some ropey hacking around where an app uses the MusicUtil.generate_scale_of_length() method. I really like all the scale options but often I just want to select my own notes. For this app it’s a fairly easy gaffa-tape job but it occurred to me that this is just the sort of thing that I would want in other apps and then it occurred to me that this is probably a fairly common use case for others and that there might already be a more elegant solution? If not perhaps I ought to think about how I do it so that it could live as an abstraction and just be dropped into the lib of other apps?
My strategy was to add a use_user_scale option to params and use that to switch the behaviour between normal proper scales or just reading from an array whose elements can be dialled in from params. Either initialised to a common scale or maybe to all at zero offset? I guess that the param stuff could live in the abstracted init. That way you just add an init line to the bottom of the server app init code and add the if-switch where it’s needed anywhere the MusicUtil code is called. Also the scale would be saved with your preset as the notes would all be params.
Marginally less hacky than just pasting all the code into other apps but still fairly hacky and not the most user-friendly for others to pinch and re-use. I guess the proper way to do this would be to redefine the MusicUtil methods? The cleanest option I would guess would be to add a user_scale option to the available scales? Perhaps have a sub page for the notes in params to keep it tidy?

1 Like

A vocal synth with a “speech recognition” interface. talk to your Norns and drive a synthesizer. Keep a continuous buffer/log of words to resynthesize scrambled language. Rap at it, read it a book, tell it a secret, feed it a fax


Some easy way to set Norns version requirement within a script would be nice. A notification would be displayed, urging the user to update their Norns.

I have seen several discussions in the script threads where people encounter bugs that are related to them not having updated the Norns. (I made the same mistake a few days back, hence this idea.) This would lessen the support workload of script developers.


I would like to use norns as a sound source that takes triggers from a contact mic- is this possible already? This is one way I use my modular to interact with drums- I stick a contact mic on a drum and the sound it sends is used like a trigger to strike an envelope/vca (have to boost the signal as well for this to work). I usually set up a sequence or randomized quantizer so each trigger will cycle through the sequence by a step each time its hit. Is there a way to already do this with norns/ would this be possible?

1 Like

i think this is possible with a 12 lines of code that you can add to any script you want to add this functionality:

-- listen to audio
contact_mic_threshold = 0.1 -- pretty loud
p_amp_in.time=0.05 -- 50 millisecond resolution
  if val>contact_mic_threshold then 
    -- send osc to any trigger...
    -- send midi? send crow? or other stuff?

put that at the end of a function init() and it will constantly listen for a contact mic hit and then do whatever you want (osc to trigger paramter, midi, crow, etc.)

edit: one addendum. you can actually to the above twice: once for the left channel (amp_in_l) and once for the right channel (amp_in_r). if you have two hard panned contact mics you should be able to monitor two instead of one…


also just crow by itself ! (assuming enough amplification)

input[n].mode( ‘peak’, threshold, hysteresis ) – set input n to:
– ‘stream’: creates an event when an audio transient is detected at the input
– threshold: sets the RMS level required to trigger an event
– hysteresis: sets how far the RMS level needs to decrease before retriggering

1 Like

Beautiful, thank you for the tips @infinitedigits and @andrew. Might have to look for a crow in the future…

I just wanted to suggest looking into the possibility of updating scripts directly from Norns, the same way as you can update the software. Obviously it will probably require a lot of software redesigning (I’m assuming that 3.0 is already quite a major redesign), but yesterday whlist rehearsing for live performance I wanted to quickly update the Cheat Codes, with no direct access to the computer and I thought it would be handy, especially for hotfixes etc.
Just to clarify, not talking about a browser of the scripts directly on norns. Just a quick fetch of updates for already downloaded scripts in the menus.

I’m not an my norns right now, but I often open a remote terminal over to my norns for whatever reasons, and there a possibility to run maiden to update installed scripts.

I meant more of a standalone solution in situation when you don’t have access to the terminal.

I am not near norns right now but updating via iPad works fine for me, not sure if a phone also works, never tried.

Guys, thank you for trying to help, but you are missing the point. It’s not really a post looking for a workaround. I’m just suggesting a feature which I guess would be useful, the same way as updating the software from norns menu.

1 Like