Makes sense. I wasnt sure if that would be causing the problem or not.
The issue is reported here: Fates - a DIY norns DAC board for Raspberry Pi
lua: /home/we/norns/lua/core/menu/tape.lua:66: attempt to index a nil value (local ‘f’)
Maybe it is a permissions problem (waiting on feedback from user on that)
so, errors on this line:
where it attempts to use the index file in write mode.
evidently it did not fail to open and use the same file in read mode a few lines up.
permissions problem seems likely. (why/how? got me.)
(i guess we should have a check for nil, but erroring if we can’t write to the filesystem there is probably the right behavior.)
Figured out the error. The user’s tape directory had been deleted. Thus the filepath was invalid.
In the code snippet I posted, if f is nil on the first read, it does not throw an error, m.fileindex is just set to zero. Then when it tries to write afterwards, it gets an actual error.
Maybe @dan_derks would want to file this as a support issue/solution?
pff, thanks, i should have realized that.
yes, i’ll submit a fix right now since i happen to have the norns out for once. (and dan is, hopefully, asleep)
here is a PR. (really though: probably best not to remove the audio or tape directories in the first place.)
Unrelated, but I was chatting with @tyleretters and @dan_derks about development environments (e.g., VS Code, auto-complete, etc.) a few weeks ago during the Norns study session, and decided to put this together. I hope it helps someone else! Thanks Tyler and Dan for the help!
A quicker/nicer run/“build” setup is described here https://github.com/monome/norns/issues/1067
It was written for Atom but should be adaptable to VS Code or any other editor that supports build commands.
really nice work on this! i love this genre of writing: “precise, level-headed development environment setup”
nice looking guide!
heads up that maiden-repl should be in the path, so you don’t need to type it all out or make an alias
i know this was probably supposed to be funny but it’s a very frustrating comment to me. we’ve fielded this issue at length but have received precious little assistance in moving it forward. the OS does not actually help us much since we are not running in a console or X window.
not really. the kernel doesn’t care about keyboard locale. the kernel maps scan codes to keycodes. (this lowest-level mapping can itself be customized, but that’s not typically done for localization - more for things like like swapping CTL and ALT.) userspace maps keycodes to characters when appropriate - in localectl for virtual terminals, in xorg for windowed apps, or just in application code for things like evtest which use the USB data directly instead of requiring a terminal or window environment. (when you set locale at installation time, you are probably setting localectl for console / terminal input on OS’s like debian which use systemd.)
in norns, we lifted the keycode to character mapping from evtest/kernel headers, and ported it to lua. this table effectively defines the keycode mapping by naming each keycode with a character:
if you want to help us support other keyboard locales in norns apps which handle character input, that could be done with a lua code contribution to that file or a collection of similar files for different keyboard locales. maybe this seems redunant because other apps do it, but believe it or not it appears to be the status quo and libraries like SDL have to do the same thing.
extending and swapping out the HID events table should be pretty easy to do. if you want to somehow create a virtual terminal inside the lua environment and wrap its I/O, i guess that is probably also possible, but it sounds way more difficult.
finally:
the keyboard mappings are already in the core lib - the module i just linked. look at orca source - it looks for the character input events already set up by the hid module, like hid.codes.KEY_SEMICOLON. this is good - only the hid module is concerned with keycodes, the script operates on the abstraction of character-events, and we can support other locales by simply defining different code tables (or lifting them from xorg source or whatever, natch - maybe it makes sense ot make this lua module understand whatever standard file format for defining keyboard locales.)
it looks like yggrasil searches for keycodes directly, which of course will hamper any such efforts to expand locale compatibility.
the keyboard mappings are already in the core lib
what i meant by “be in the core lib” is have a suggested way for people to use this keymap (ie helper functions, sensible keyboard discovery, etc), along with docs and examples.
the implementation in orca, for example, has a ton of internal keyboard lib files… whereas i’d expect/prefer a keyboard core lib to enable something like
k = keyboard.init()
k.keycode = function(n,z) --- redefine callback which returns keycode+state
yes, it is. i love this approach. i’ll refactor to use this technique. @its_your_bedtime 
let’s talk about this more! i may be able to take it on, depending how much c is required.
i don’t think any C programming is required to support other keyboard layouts.
a tiny amount may be required to detect when a HID devices is in fact a keyboard (supports “keyboard” interface protocol.)
i found the open issue for iternational kbd support. this doesn’t cover the creation of a higher-level keyboard abstraction in lua to glue all these things together.
[i’m gonna move these last few posts to “development” topic, and move further details to the issue comment thread.]
Hi.
I was thinking about the possibility to write the name of (for example) the recording tape with keyboard (HID)…
it will cool and easier to be able to write the name with letter of a computer key.
What’s the best way to debug core C on norns? I’m planning to try a few things in screen.c around the frame buffer and don’t know how to configure norns to get messages back.
x-posted:
ok, i guess we are always building with debug symbols, but they won’t be useful with -O3 (the default.)
unless i’m forgetting something (possible, b/c my waf-fu is weak), we don’t have a debug configuration set up that changes the optimization flags for matron.
so for now i would just edit norns/matron/wscript line 79 to change -O3 to -O0 (and don’t forget to change it back later!)
then just
> pidof matron | xargs kill
> cd ~/norns
> ./waf clean
> ./waf build
gdb build/matron/matron
(gdb) b main
(gdb) r
et cetera
Would be possible to rewrite routings to use a class compliant audio interface with Norns to expand I/O and add multitrack record?
Of course I can imagine not only Norns but the engines would have to change to accept more I/O.
Would be possible with the current hardware though?
I’ve been curious about the same thing. I plugged in an M-Audio fast track and I get this.
192.168.1.191 ~/dust/code/sines $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: sndrpimonome [snd_rpi_monome], device 0: monome cs4270 cs4270-hifi-0 [monome cs4270 cs4270-hifi-0]
Subdevices: 0/1
Subdevice #0: subdevice #0
card 1: Pro [FastTrack Pro], device 0: USB Audio [USB Audio]
Subdevices: 1/1
Subdevice #0: subdevice #0
card 1: Pro [FastTrack Pro], device 1: USB Audio [USB Audio #1]
Subdevices: 1/1
Subdevice #0: subdevice #0
192.168.1.191 ~/dust/code/sines $ jack_lsp
system:capture_1
system:capture_2
system:playback_1
system:playback_2
crone:input_1
crone:input_2
crone:input_3
crone:input_4
crone:input_5
crone:input_6
crone:output_1
crone:output_2
crone:output_3
crone:output_4
crone:output_5
crone:output_6
softcut:input_1
softcut:input_2
softcut:output_1
softcut:output_2
SuperCollider:in_1
SuperCollider:in_2
SuperCollider:out_1
SuperCollider:out_2
No problems on the hardware front. JACK doesn’t pick up the new device, though on my Linux desktop I can do USB audio hot-swapping without restarting jackd.
So I’d say, yes this is possible and yes it would take a lot of work to hook it into the larger Norns platform.
After calling screen.arc() to draw an arc, I’d find it useful in scripts if I could get the current x, y position on the screen.
What do we think about using cairo_get_current_point in screen.c, and adding get_current_point() to the script-level screen lib?
we can consider this after a pending PR gets merged where cairo gets heavily reworked (its own thread) which complicates get methods (they need callbacks). but once it’s merged there will be a pattern that can be followed to add this.