Norns: dust

— now getting it actually working… will probably require some work. And then you’ll need to figure out the hardware interface side of things.

I know @mzero had been talking about making some efforts on getting this working with rpi+pisound.


is that the repo that was mentioned previously?
I would love to get the code working on my linux64 machine as well as the Norns device

Yes that’s where you would go. Everything works fine on other linuxes, except the screen and GPIO. Adapting screen should be simple (it’s a Cairo surface.) Adapting GPIO a little more arbitrary.

6 posts were merged into an existing topic: Norns: Development

any suggestion on how to fake the cairo surface?
i DO have a grids but i was out today and missed the USPS guy so Friday is my first visit to Nornia


This is the funniest thing I’ve read all day. Time for some Nornia memes (in another thread, of course).


Turkish Delights of course


Hi @artfwo - I think I discovered a bug in glut today.

loading this glut.pset consistently crashes the left channel when playing the 3rd sample (whether alone or in tandem).

(included pset and tape so you can attempt to reproduce on your machine).


edit: It would probably be better to post bug reports against the dust repo, wouldn’t it?

edit-2: It seems like the interplay of density and size can bring the left channel back in/out, but even using them within fairly “modest” ranges cuts out the left channel.

1 Like

thanks for the report! yes, feel free to open issues on github in dust (noting that it’s a glut bug and assigning me is okay).

regarding this specific bug: as of now, glut always reads only the first (left) channel from loaded samples, because of how SuperCollider GrainBuf ugen works. Stereo sample support will require doubling the number of grain ugens and changing the loading/panning logic a bit (working on that).

you sample here seems to have a huge DC offset in the left channel and that might cause the engine to silence itself. i suggest normalizing it and see if it works. it’s also best to mixdown samples for glut into mono, until the stereo buffers thing is resolved.



I see in the OP script specfic questions should be in another thread, yet to be created. i have some MLR questions burning!

1 Like

script-specific (ie mlr) questions welcome here (i was trying not to get questions here about scripting)

i’ll clarify the top post, thanks for the reminder


Thanks for the clarification. A couple of MLR questions from me:

  1. The script converts audio to mono, correct?
  2. When I load rather long pre-existing audio clips (say, 1-2 mins), I’m seeing that the file is mapped strangely on the corresponding grid row — for example, only a section of the audio file will be accessible on a range of just 1-2 keys on the row. Am I running into a length limitation of some kind?

…how do you do this?

1 Like

Open MLR, then go back to the menu and into Parameters. You can load samples there.


While using MLR, I was able to quickly add clips by entering the clip menu directly from the grid (key 3 on the top row).

1 Like

are you guys using some other version of mlr than me? mine doesn’t have audio file parameters :confused:

1 Like

Oh! this is my bad! I wasn’t in front of norns. I must have been confusing scripts! :grimacing: In mlr it is as @Olivier says, go to the Clip page on grid and button 2 loads samples.

Sorry for the confusion!!


fixed this in the update


My interest in developing for norns would mostly be making synth engines and effects to strap to other peoples’ apps. In the interest of not spinning off near-identical copies of apps, should there be an effort to have a standardized synth manager/selector within an app’s parameters page? Many sequencer apps like Earthsea could be synth-agnostic, IMO. The pitch/gate info could passed to a selected synth, which could then have its own parameters exposed within the parameters page (or a sub-page). If an app exposes controls beyond pitch/gate, these could be map-able via some sort of mod matrix to the synth’s params.


Thanks for the response! Perhaps worth noting that the 3rd sample with all the DC offset is just a norns tape recording of the first two samples as played back and manipulated by glut - any idea why glut would introduce so much DC offset?

I’ll keep the mono advice in mind for the future, it’s nice being able to dump little tape experiments from other patches in though! Look forward to proper stereo support :slight_smile: