#511

here is a PR. (really though: probably best not to remove the audio or tape directories in the first place.)

#513

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!

8 Likes
#514

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.

1 Like
#515

really nice work on this! i love this genre of writing: “precise, level-headed development environment setup”

#516

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

2 Likes
#517

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.

6 Likes
Yggdrasil
Yggdrasil
#518

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
1 Like
#519

yes, it is. i love this approach. i’ll refactor to use this technique. @its_your_bedtime :pray:

let’s talk about this more! i may be able to take it on, depending how much c is required.

2 Likes
Orca - Livecoding Tool
#520

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.]

2 Likes
#521

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.

#522

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.

#523

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

1 Like
#525

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?

#526

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.

1 Like
#527

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?

#528

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.

1 Like
#529

Hey there, just wanted to submit some thoughts and bugs regarding the clocking system.

  1. Crow clock input, as of now if I feed a clock with bpm 125, then Norns will show it as 300 because internally it understands 125 bpm as 125 x 4. The clock speed is still 125 when Norns syncs, but the bpm reader on Norns will show 300. This doesn’t affect any functionality, but would be nice if it showed it correctly. For example when syncing to midi clock it will show 125, so the incorrect reading only happens when clocked from Crow.

  2. General Midi Start / Stop / Run / Reset messages (also applicable to crow clock sync), currently they don’t exist, hence, Norns never stops the sequencers or anything tempo related. In the end it is very hard to start your other gear with Norns synced to either midi or crow clock. Also for performance reasons, it is important to be able to stop everything at once (and start too). Fairly basic stuff that should have really been on Norns from the start.

  3. Norns does not understand Clock Swing when either clocked by midi or crow. By clock sync I mean irregular clock where every second pulse is delayed by variable amount. The majority of music relies on some sort of swing amount in the sequence, from classical MPC 54% clock swing to full triplets at around 67%. For example when using ERM multi clock, it sends variable swing amount for 4 midi outputs, this way every machine can follow this swinged clock and stay in the same groove. For example Monome Ansimble responds to swinged clock exactly how you would expect it, but Norns completely ignores it. This is not so important for loopers or audio related stuff, but very important for sequencers, meaning that the sequence should advance to the next step not just by regular clock, but also irregular. Would love if this could be implemented :slight_smile:

Hope I don’t sound too needy with these requests, but I really feel like these things are absolutely necessary to make Norns work with other gear and be more performance friendly, its not just for ambient music :smiley:

1 Like
#530

hey hey! hope all’s well :slight_smile:
some very good topics, which thankfully point to docs gaps more than system troubles, so hopefully this reply helps!

Crow clock input

under PARAMETERS > CLOCK, there’s a crow in div setting which determines how many clock pulses should register as a “tap” for the BPM matching. you’ll need to fine-tune to match this to your clock source’s pulses per quarter note.

so, if a clock source sends four pulses every 500ms to represent 120 BPM, then you’ll want to set crow in div to 4 to match the norns clock tempo displayed.

if fiddling with different values doesn’t give expected results, please share what your clock source is and we can investigate the specs :mantelpiece_clock:

i just had a dark night of the soul writing a transport into cheat codes, so i am fresh on the heels. big picture: each script needs to define what should start and stop and reset whenever these messages are received. this is a docs gap which i’m writing to fill, but essentially norns already has two script-definable transport calls: clock.transport.start() and clock.transport.stop(). these are hard-coded to respond to MIDI start/stop messages (if clock source is set to MIDI), as well as Ableton Live’s “start stop sync” (if clock source is set to Link).

so, simply put, the functionality has been present in norns for a year, but very few scripts utilize it because it wasn’t well-documented. i’m hoping that this docs effort will help clarify when to use what and why, but if you have a few scripts which you’re totally dying to have this in, let the author know and i’m totally happy to help how I can :slight_smile: @vicimity 's Initenere comes to mind as a script which makes use of these messages.

@artfwo can speak more to the architecture, but from what I understand the clock runs its own transport which can derive a tempo from an external source but it doesn’t wait for ticks (like ansible or other modular gear which require constant pulses to advance [if a patch cable is in their clock input]). apologies if this is a dumb question, but how do DAWs handle incoming clock swing driving their main clock?

as far as outgoing swing, @tyleretters’s lattice provides a really nice framework for scripts to incorporate swing, but this is a new library for script authors. in fact, lattice also has a nice framework for scripts to act more like modular sequencers where a pulse event is required to advance. excited for more people to use this!

6 Likes
#531

well, the clock API only provides the primitives to sync to the source, so swing has to be implemented on the script level.

in a DAW, incoming swing is best handled on the DAW end, e.g. the DAW gets a steady rhythm at the clock input and shuffles it internally (by delaying odd beats for example). i am not aware of any hardware or software implementing it the other way round.

2 Likes
#532

Thanks a lot for all the explanation, really helpful! Didn’t know start and stop is already in there so this is definitely great news for future app updates!
Will check out lattice as well!

1 Like