I highly recommend going the sshfs route if using an editor running on a computer. The maiden repl can then be used to run norns.script.load(...) (passing in the relative path to your script within the dust structure) to achieve what the play button does.

UPDATE: I should add that the repl has basic command history, just hit the up arrow on your keyboard and press return to re-evaluate the last expression.

6 Likes

I’ve been working locally in VS Code and made a little python command line script (while I was procrastinating today) to help me manage syncing files and various other admin stuff, so I can type commands like:

  • norns shell
  • norns list
  • norns remote list
  • norns sync <script name>

It is entirely tailored to my computer right now, but if anyone is interested I could figure out how to make it a more polished sharable resource.

1 Like

Running norns on RasPi I have bluetooth already on-board (norns hardware could easily add a BT usb nub for this)
 so why not try to get like a WiiMote talking to norns? :grin:

I’ve got the bluetooth stuff recognizing the WiiMote, pairing and and connecting so that’s great. but
 norns needs some hacking in device_monitor.c to make this go.

I started a github issue here in case someone smarter than me has time to lend a hand :slight_smile:

(This could also be helpful for stuff like bluetooth midi?)

5 Likes

Yikes, that’s exciting. I had a blast with using wiimote with Ableton
 theoretically if you get this going with rPi norns (π o r π s ?) it should work also work with norns and a bluetooth dongle?

In theory, yes. In practice not yet.

For the moment norns only looks at the usb subsystem for input devices, so this area needs more code (that ive not been able to figure out on my own). Also I think UART might need to be disabled, so
? :thinking:

1 Like

I’m interested in developing an audio utility script for Norns. To start, I would like to be able to normalize samples, trim the start and end, and resave. Can anyone point me in the right direction for normalization? Would this require SC engine development, or is this already available?

2 Likes

I would love this!

Not sure if this is any help:
http://doc.sccode.org/Classes/SoundFile.html

Also, I would look into @markeats Timber for Waveform-displaying/GUI stuff.

3 Likes

@crim @noiserock

i agree that would be good to have. manipulating soundfile contents from supercollider is actually not that convenient though. we do provide some buffer-trimming utilities here for use in SC engines.

i would just accomplish this by installing sox (which we should probably include in the default norns distro) and invoking it from lua.

to normalize an input file to -1.0 dBFS, and trim it to 2.0s duration with a 1.0s offset:
sox file.wav file_trim_norm.wav norm -1.0 trim 1.0 2.0

5 Likes

Thanks! It didn’t occur to me to invoke an external command line tool from Lua. I suppose I could do this with ffmpeg as well, but the sox API looks like it might be bit more friendly.

2 Likes

Sox is prolly better than ffmpeg. There’s also ecasound, which is like a whole DAW with a command line interface! That could be fun.

4 Likes

So
I have a completely new rewrite of FM7. It’s so different I’m labeling it version 2.0. It has a large number of requirements, including a grid and an arc, optionally a MIDI keyboard. I would like to make the code more modular and detect if there is an arc connected, then change how the encoders on the Norns control parameters.

I tried the pattern I saw in other scripts which is basically these two lines

a = arc.connect()
if a then special_arc_function() end

But with my script this block is always true even when an arc is not connected. How can I detect if a device is present?

2 Likes

Try looking at the tables arc.devices or grid.devices

similarly I have used this to get a list of attached hid’s

function init()
  for v in pairs(hid.devices) do
    print (v .. ": " .. hid.devices[v].name)
  end 
end
2 Likes

Oh neat. It seems like the table for a connected arc persists across disconnects but when a device is removed, the key a.device is nil.

1 Like

I found a bug in how engines are loaded while debugging the Gemini script.

Given a script with an engine is loaded successfully, loading a different script that has an error on the Lua side (in this case an initialization ordering error) causes the previous engine to be loaded.

This is reproducible by loading the FM7 library, followed by loading this commit from the Gemini library, which will throw an exception when an Arc is connected. The third step is to apply my diff to fix the initial exception via Maiden, save and load the script. This will cause SuperCollider to throw an exception expressing a missing engine from Gemini. This is followed by something (perhaps this is the root cause?) loading the last successful engine into this script, exposing all parameters and polls then initializing the “failed” script a second time. Rebooting the device “fixed” this bug. Is it worth an issue on github to hunt this down?

Yes. It sounds like something in the script.lua domain

1 Like

Good evening!

I lost about 30 minutes feeling like a crazy person because I was editing a library that is included in the top level script, then loading the script to the device through Maiden. This did not include the changes I made to the library, even though I was looking right at the code. IIRC there is some kind of caching thing when using the Lua require 'foo' syntax. Is that correct?

Is there a way to develop libraries on the device that does not require rebooting the device to see changes?

Yeah, require caches the file. You can use include('foo') instead. I asked the exact same thing very recently so seems to be a common question

1 Like

require's caching behavior is a lua thing, not a norns thing. we use it in core libs, but not for any great reason

we added include to norns, which doesn’t cache and searches muliple locations starting with the path to the current script.
https://monome.org/docs/norns/script-reference/#using-libraries

2 Likes

Encoder 2 in a FM7 broke at a seemingly random moment. I have the callback firing only when a key toggle is true, which seems to continue to work (when the toggle is false I see no exceptions) but when the toggle is true I get the following exception

stack traceback:

/home/we/norns/lua/core/encoders.lua:57: in function 'core/encoders.process'

lua: /home/we/norns/lua/core/encoders.lua:57: attempt to call a number value (field 'callback')

I noticed this about 3 minutes into a live session I began recording with the internal TAPE feature. Prior to recording, the encoder worked as expected. The encoder changes a parameter (the c:m ratio in this case) so I checked the system parameter screen and I could continue to change the value from there. I haven’t tried to reproduce this yet. Reloading the script “fixed” this state.

update: I can reproduce this. Each time the record action of the TAPE feature is called, my encoder function breaks in the same way. Details on Github.

1 Like

How does norns do GPIO? I’ve looked through gpio.c, and it looks like the knobs show up as an input device. How do they end up in /dev/input?