Approaching: norns


#1076

man, I remember Electro Man. It was surprisingly interesting: more puzzly than platformy. Irritating sounds, though!


#1077

bidirectional communication

yes it’s possible.

on norns we are using libudev directly for HID. most HID output is leds and force feedback. these have standard sysfs interfaces.

however a lot of device have non-standard interfaces. for example i have an xbox360 controller, and it has LEDs on it, but you can’t just set the brightness of these LEDs directly like you can with lock indicators on keyboards. instead you can set different blinky patterns for the leds through some undocumented mapping on some undocumented port that doesn’t even get enumerated in the events list for the device (it is absolutely not worth my time to figure this out.)

here’s the full list of event codes we get for the xbox360 and a usb keyboard:

Controller
  0 : 0 (EV_SYN) : 
  1 : 1 (EV_KEY) : 
      0 : 304 (BTN_SOUTH)
      1 : 305 (BTN_EAST)
      2 : 307 (BTN_NORTH)
      3 : 308 (BTN_WEST)
      4 : 310 (BTN_TL)
      5 : 311 (BTN_TR)
      6 : 314 (BTN_SELECT)
      7 : 315 (BTN_START)
      8 : 316 (BTN_MODE)
      9 : 317 (BTN_THUMBL)
      10 : 318 (BTN_THUMBR)
  2 : 3 (EV_ABS) : 
      0 : 0 (ABS_X)
      1 : 1 (ABS_Y)
      2 : 2 (ABS_Z)
      3 : 3 (ABS_RX)
      4 : 4 (ABS_RY)
      5 : 5 (ABS_RZ)
      6 : 16 (ABS_HAT0X)
      7 : 17 (ABS_HAT0Y)
  3 : 21 (EV_FF) : 
USB Keyboard
  0 : 0 (EV_SYN) : 
  1 : 1 (EV_KEY) : 
      0 : 1 (KEY_ESC)
      1 : 2 (KEY_1)
      2 : 3 (KEY_2)
      3 : 4 (KEY_3)
      4 : 5 (KEY_4)
      5 : 6 (KEY_5)
      6 : 7 (KEY_6)
      7 : 8 (KEY_7)
      8 : 9 (KEY_8)
      9 : 10 (KEY_9)
      10 : 11 (KEY_0)
      11 : 12 (KEY_MINUS)
      12 : 13 (KEY_EQUAL)
      13 : 14 (KEY_BACKSPACE)
      14 : 15 (KEY_TAB)
      15 : 16 (KEY_Q)
      16 : 17 (KEY_W)
      17 : 18 (KEY_E)
      18 : 19 (KEY_R)
      19 : 20 (KEY_T)
      20 : 21 (KEY_Y)
      21 : 22 (KEY_U)
      22 : 23 (KEY_I)
      23 : 24 (KEY_O)
      24 : 25 (KEY_P)
      25 : 26 (KEY_LEFTBRACE)
      26 : 27 (KEY_RIGHTBRACE)
      27 : 28 (KEY_ENTER)
      28 : 29 (KEY_LEFTCTRL)
      29 : 30 (KEY_A)
      30 : 31 (KEY_S)
      31 : 32 (KEY_D)
      32 : 33 (KEY_F)
      33 : 34 (KEY_G)
      34 : 35 (KEY_H)
      35 : 36 (KEY_J)
      36 : 37 (KEY_K)
      37 : 38 (KEY_L)
      38 : 39 (KEY_SEMICOLON)
      39 : 40 (KEY_APOSTROPHE)
      40 : 41 (KEY_GRAVE)
      41 : 42 (KEY_LEFTSHIFT)
      42 : 43 (KEY_BACKSLASH)
      43 : 44 (KEY_Z)
      44 : 45 (KEY_X)
      45 : 46 (KEY_C)
      46 : 47 (KEY_V)
      47 : 48 (KEY_B)
      48 : 49 (KEY_N)
      49 : 50 (KEY_M)
      50 : 51 (KEY_COMMA)
      51 : 52 (KEY_DOT)
      52 : 53 (KEY_SLASH)
      53 : 54 (KEY_RIGHTSHIFT)
      54 : 55 (KEY_KPASTERISK)
      55 : 56 (KEY_LEFTALT)
      56 : 57 (KEY_SPACE)
      57 : 58 (KEY_CAPSLOCK)
      58 : 59 (KEY_F1)
      59 : 60 (KEY_F2)
      60 : 61 (KEY_F3)
      61 : 62 (KEY_F4)
      62 : 63 (KEY_F5)
      63 : 64 (KEY_F6)
      64 : 65 (KEY_F7)
      65 : 66 (KEY_F8)
      66 : 67 (KEY_F9)
      67 : 68 (KEY_F10)
      68 : 69 (KEY_NUMLOCK)
      69 : 70 (KEY_SCROLLLOCK)
      70 : 71 (KEY_KP7)
      71 : 72 (KEY_KP8)
      72 : 73 (KEY_KP9)
      73 : 74 (KEY_KPMINUS)
      74 : 75 (KEY_KP4)
      75 : 76 (KEY_KP5)
      76 : 77 (KEY_KP6)
      77 : 78 (KEY_KPPLUS)
      78 : 79 (KEY_KP1)
      79 : 80 (KEY_KP2)
      80 : 81 (KEY_KP3)
      81 : 82 (KEY_KP0)
      82 : 83 (KEY_KPDOT)
      83 : 86 (KEY_102ND)
      84 : 87 (KEY_F11)
      85 : 88 (KEY_F12)
      86 : 89 (KEY_RO)
      87 : 92 (KEY_HENKAN)
      88 : 93 (KEY_KATAKANAHIRAGANA)
      89 : 94 (KEY_MUHENKAN)
      90 : 95 (KEY_KPJPCOMMA)
      91 : 96 (KEY_KPENTER)
      92 : 97 (KEY_RIGHTCTRL)
      93 : 98 (KEY_KPSLASH)
      94 : 99 (KEY_SYSRQ)
      95 : 100 (KEY_RIGHTALT)
      96 : 102 (KEY_HOME)
      97 : 103 (KEY_UP)
      98 : 104 (KEY_PAGEUP)
      99 : 105 (KEY_LEFT)
      100 : 106 (KEY_RIGHT)
      101 : 107 (KEY_END)
      102 : 108 (KEY_DOWN)
      103 : 109 (KEY_PAGEDOWN)
      104 : 110 (KEY_INSERT)
      105 : 111 (KEY_DELETE)
      106 : 113 (KEY_MUTE)
      107 : 114 (KEY_VOLUMEDOWN)
      108 : 115 (KEY_VOLUMEUP)
      109 : 116 (KEY_POWER)
      110 : 117 (KEY_KPEQUAL)
      111 : 119 (KEY_PAUSE)
      112 : 121 (KEY_KPCOMMA)
      113 : 122 (KEY_HANGEUL)
      114 : 123 (KEY_HANJA)
      115 : 124 (KEY_YEN)
      116 : 125 (KEY_LEFTMETA)
      117 : 126 (KEY_RIGHTMETA)
      118 : 127 (KEY_COMPOSE)
      119 : 128 (KEY_STOP)
      120 : 129 (KEY_AGAIN)
      121 : 130 (KEY_PROPS)
      122 : 131 (KEY_UNDO)
      123 : 132 (KEY_FRONT)
      124 : 133 (KEY_COPY)
      125 : 134 (KEY_OPEN)
      126 : 135 (KEY_PASTE)
      127 : 136 (KEY_FIND)
      128 : 137 (KEY_CUT)
      129 : 138 (KEY_HELP)
      130 : 183 (KEY_F13)
      131 : 184 (KEY_F14)
      132 : 185 (KEY_F15)
      133 : 186 (KEY_F16)
      134 : 187 (KEY_F17)
      135 : 188 (KEY_F18)
      136 : 189 (KEY_F19)
      137 : 190 (KEY_F20)
      138 : 191 (KEY_F21)
      139 : 192 (KEY_F22)
      140 : 193 (KEY_F23)
      141 : 194 (KEY_F24)
      142 : 240 (KEY_UNKNOWN)
  2 : 4 (EV_MSC) : 
  3 : 17 (EV_LED) : 
      0 : 0 (LED_NUML)
      1 : 1 (LED_CAPSL)
      2 : 2 (LED_SCROLLL)
  4 : 20 (EV_REP) : 

the EV_LED codes for the keyboard are standard and easy to use.

you may notice the EV_FF field for the gampad. force feedback can be pretty deep, some devices let you program custom waveforms and stuff, some don’t. start on page 20 here: http://www.infradead.org/~mchehab/kernel_docs_pdf/linux-input.pdf

anyway, we haven’t made glue to send events to HID devices from lua just yet, but have kept it in mind with the supported-events scaffolding. (e.g., lua knows about those EV_LED fields.)

partly that’s because the use cases just aren’t clear (custom HID controllers? better to use serial maybe, like monome controller protocol) and we are spread thin implementing core functionality. so i hope that the first time someone comes a long with a compelling use case, they can help specify which exact output event bits would be most helpful to implement.


#1078

not totally sure i understand the question. the SoC is a Broadcom BCM2837. if you’re curious about the microarchitecture / instruction set, it is four Arm Cortex-A53 cores. the instruction set includes NEON SIMD. (other Cortex variants have “DSP extensions” for SIMD but for A53 it’s all NEON.) there is also the Compute Library if you are interested in doing custom heavy-lifting ML tasks on this platform.

this is most applicable if you want to do very low-level development, probably using assembly. when compiling a program (like supercollider), the compiler (gcc) will take advantage of vectorized NEON instructions when possible.

curious if it could replace my aleph craving for simpler/lighter dsp tasks.

if you mean you just wanna write some C code to do simple audio processing, yes absolutely. supercollider is provided and is a convenient high-level framework for defining musical processing. the norns lua environment is provided and is a convenient way to define knob/key/screen <-> grid/hid/midi <-> osc mapping. but you are not obliged to use either one.

one thing aleph can do that is unique is provide minimal I/O latency. norns can’t do that, it runs on ALSA/jack and has a configurable I/O buffer size that you may want to adjust depending on your specific latency/load requirements.


#1079

Ah right, for some reason I thought this was gonna be along the same lines as the Aleph in that regard. For the I/O buffer size, is it going to be in the ‘normal soundcard’ range? (rather, how low can you (reasonably) go under realistic load?)


#1080

currently the default is 128 frames per period, 2 periods/buffer, at 48k. smaller buffers are possible but the loss of efficiency becomes noticeable below that.

as far as acoustic delay, this is <2ms (sorry, 8ms for total round-trip) and is about the same as standing 1 4 meters away from a sound source.

imho this is mainly an issue if you want to use the audio I/O in a direct feedback loop (which won’t give you resoance > 500hz ~120hz), or in a direct wet/dry mix (which will cause very noticeable comb filtering - so just don’t try to mix dry signal with the same signal routed through the norns and unprocessed.)


#1081

To be fair, that’s assuming the total buffer (in + out) is 128 samples (e.g. a 64 sample input buffer and a 64 sample output buffer). Otherwise you need to double that number.

Also, the DAC and ADC chips have a latency on the order of a few samples as well, usually between 7 and 30 depending on the oversampling and their digital filter implementation.


#1082

But you can’t escape that independently of what silicon you have doing the processing.

Thanks @zebra, I was looking for more details like this. Definitely not planning on asm and sc seems like a good platform for dsp ideas, I’m certain there is a wealth of patches by the community. I’ve been exploring ML approaches to sound, so it was nice to find out they have a library one can use. That said, my use of ML is to ultimately drive dmx lights…


#1083

To be fair, that’s assuming the total buffer (in + out) is 128 samples (e.g. a 64 sample input buffer and a 64 sample output buffer). Otherwise you need to double that number.

you’re right, double it for round-trip. my bad. additionally i forgot that jack uses this weird “periods” concept, so double it again call the total round-trip latency ~8ms, or 4 meters in air. pushing the Haas effect limit a little but still within it. (i might play with adding one period/buffer and halving the period size.) [update: yea its actually quite happy with 3x 32-frame periods if latency is a priority over power.]

Also, the DAC and ADC chips have a latency on the order of a few samples as well, usually between 7 and 30 depending on the oversampling and their digital filter implementation.

that’s true. for the CS4270 it’s ~5 samples for the ADC and ~2.5 samples for the DAC. and since we’re being pedantic i’ll point out that this is group delay, not latency. (it is frequency-dependent.)


#1084

Could one have norns run an external audio interface?


#1085

To answer your question, I just found a few posts in this thread :

:slight_smile:


#1087

I think our best bet of getting DMX output on the norns is using OLA. I’ve used SuperCollider to control DMX via OSC to OLA with great success.


#1088

Do I understand correctly that you can plug those supported devices and basically Ola talks to them if You feed ola osc?

Right now I made a teensy coupled to a screen driving dmx out but I also have an enttec USB device that’s on that list…


#1089

Yes! It is really simple once you get it installed. a simple osc message like /dmx/universe/0/1 will address the light on channel 1. I made a simple pseudoclass called BusToOSC which enables me to poll control buses and send their values to specific OSC addresses. It’s really helpful for making the connection from SC to OLA. But obviously you wouldn’t even need to use SC if you didn’t want to.


#1090

The first public mention of Crone! Supercollider tips, Q/A


#1091

Any one know if the initlal stock apps will support different size grids? I’m sure this question has been answered somewhere this thread a search didn’t produce any results for me.


#1092

var-size grids will be supported but the first shipping batch of scripts will focus on 16x8.

that said, adapting scripts for different grid sizes is way easier on norns than with eurorack modules etc…


#1093

Which poses the question: what are the future perspectives regarding the grid. Not that I would get one now (nor anytime soon), but let’s say I get a norns and find that it would be best complimented by a grid, do I have to look for a second hand one, or are some new grid batches planned for the future?


#1094

front page of the website has updated projections for availability across the whole range of monome devices (not just norns)

new batch of 128s will be in the shop next weekend


#1095

How does norns deal with some kind of analog pass-thru? Is there a way to get the sound directly from the input to the output without processing? This would seem important for any of the loopers to function so that you can hear your live sound on top of the looped sound.


#1097

Yeah I would definitely go for a 64 with the latest aesthetic to pair with my Norns.