Norns: scripting

[dansimco]

I’m hitting a really annoying bug at the moment, where if I run my script and I have made a mistake in a function that’s called within a Beatclock loop, the clock seems to just completely crash and the system has to be slept and rebooted. Loading other scripts work, but their metros don’t. For example I can load up Awake, but it just sits on the first beat and doesn’t play. Nor does the screen redraw correctly.

My question is, is this a common mistake that I’m making, and is there a way I can bubble wrap the clock so I don’t kill it when I make these mistakes? Because rebooting is super frustrating

[beepboop]

hi all, can anybody explain to me re inheritance why this script doesnt work?

apcnome = midi.new()

function apcnome:test()
  print("hello")
end

m= apcnome.connect()
m.event = function() print('hey')  end

m:test()

inheriting the midi object works great on its own, I get the expected outputs as if apcnome is midi–if I run this script without the call to test, I get “hey” printed to maiden from my midi device–but as soon as I try to add another function to the new apcnome object (like apcnome:test above, maiden spits out an error that the method is not found

/home/we/dust/code/beepboop/apcgrid-test/apcgrid-test.lua:11: attempt to call a nil value (method 'led')
stack traceback:
	/home/we/norns/lua/core/norns.lua:215: in method 'led'
	/home/we/dust/code/beepboop/apcgrid-test/apcgrid-test.lua:11: in main chunk
	[C]: in function 'dofile'
	/home/we/norns/lua/core/script.lua:149: in function </home/we/norns/lua/core/script.lua:149>
	[C]: in function 'xpcall'
	/home/we/norns/lua/core/norns.lua:216: in field 'try'
	/home/we/norns/lua/core/script.lua:149: in function 'core/script.load'
	(...tail calls...)

ultimately I want to make a portable library that can be included to have special methods for certain midi controllers (e.g. led like methods on midi grids), I was hoping I could do this very simply by extending the midi object in a library and not needing to add core files.

any idea whats wrong here?

[zebra]

[ed] sorry, my reading comprension is bad.

but one way or another, it looks like the midi object is being treated as a grid object.

is this the full code? (i am doubtful because the error message refers to line 11 of something and your listing is 10 lines.) is there a led method somewhere?

also what is the actual device you’re using?

---

if I run my script and I have made a mistake in a function that’s called within a Beatclock loop, the clock seems to just completely crash

can you link to code please?

[beepboop]

that was the full code! I think previously I had copied some error report from a different run of the script… sorry that made it confusing.

I am using an apc mini, and I have gotten it pretty successfully to be grid like before… but I am not really trying right now to have it “emulate” a grid as hardware on the norns. such ventures are well documented around here , and the apcmini is only 64 anyway. just want to the best I can with what i got!

But either way, just simply:
make a new script, and enter

somenewclass = midi.new()

function somenewclass:newmethod()
  print("hello")
end

m = somenewclass.connect()

m:newmethod()

what I expect is that somenewclass = midi.new() copies over the midi class to my new class, then I add a new method to my new class by calling the next part, then I instantiate my new class in m and call its new method. ultimately I expect no error (even if I dont see the print because this script never initializes or anything).

but if I run this, I get an error that newmethod has not been declared:

norns.script.load("code/beepboop/apcgrid-test2/apcgrid-test.lua")
# script load: /home/we/dust/code/beepboop/apcgrid-test2/apcgrid-test.lua
# cleanup
# script clear
### SCRIPT ERROR: load fail
/home/we/dust/code/beepboop/apcgrid-test2/apcgrid-test.lua:9: attempt to call a nil value (method 'newmethod')
stack traceback:
	/home/we/norns/lua/core/norns.lua:215: in method 'newmethod'
	/home/we/dust/code/beepboop/apcgrid-test2/apcgrid-test.lua:9: in main chunk
	[C]: in function 'dofile'
	/home/we/norns/lua/core/script.lua:149: in function </home/we/norns/lua/core/script.lua:149>
	[C]: in function 'xpcall'
	/home/we/norns/lua/core/norns.lua:216: in field 'try'
	/home/we/norns/lua/core/script.lua:149: in function 'core/script.load'
	(...tail calls...)
# script clear
<ok>

so yeah more a lua question than anything, looking at both the lua documentation on this, as well as the midi.lua core file, I cant quite see whats wrong with this.

I assume it has something to do with methods available to midi instances vs those available to the midi class itself, because, for example, calling somenewclass:newmethod() works here, but thats obviously not as useful

edit I think I got it, I just had to follow through with my last thought there…

the call to somenewclass.connect does not actually instantiate m as anything, it simply points it to the pre-method-wrapped vport thing, which wont have my new method. this totally makes sense because of the way we select midi devices and the way scripts are agnostic to midi being plugged in or not.

So I just have to figure out how to add methods to vports conditionally, or just make an alternate core file.

[zebra]

oh, yes. sorry i was indeed confused by the error report. still, should have spotted:

you got it, the problem is that Midi:connect() returns a vport, not self

so, the thing about vport is it’s just a very thin wrapper around a device’s methods. so a midi device has midi-specific methods like note_on, grid/arc have led &c.

and what you want is something a little different, like a shim layer that provides one set of methods to the script (led &c) and then maps them to different methods in the underlying device (note_on &c.) is that accurate?

assuming so, i speculate that you can just add these mapping functions to your vports manually. instead of using the vport.wrap_method convenience function, which maps a vport named method to an identically-named device method, you can do like

vport = newdeviceclass.connect()
function vport:led(x, y, z) 
  if self.device then
    chan = ...?
    note = ...?
    vel = ...?
    -- lua-style ternary conditional
    device_method = z > 0 and 'note_on' or 'note_off'
    self[device_method](chan, note, vel)
  end
end

if you wanted to clean up / break out vport to be less quick-and-dirty for this kind of customization, i’m sure it would be appreciated

i’m not actually super familiar with this part of the codebase; there might be other places that make breaking assumptions about what’s in a vport. centralizing more stuff in vport.lua and documenting it would help.

[tehn]

mod note: i thought the topic of alt grids deserved its own thread

[kasselvania]

Hey guys, I am trying to get something like the Awake script working with Trowasoft’s cvOSCcv module to get OSC signals to be in to VCV Rack.

j4s0n-c/trowaSoft-VCV

What I want to do is label the midi out notes and gates to come through OSC to this module. How would I redefine (or add) the OSC out to mirror or piggy back off of the predefined Midi information? Would this be possible?

[okyeron]

OSC is built in on norns (over WiFi) so you could just add an OSC send command wherever the midi send command is happening. (On phone so hard to send reference links)

[kasselvania]

Sorry to ask, but what would the OSC send command look like? Is there a good resource so I could learn to do that well for both Awake (which has only one voice/midi command) and something with more like lessconcepts?

[tehn]

see study 5 for osc

docs

[kasselvania]

Summary

So, because I am such a newcomer to this type of stuff, I gotta ask;

I first setup the info with the destination such as the study shows;

dest = {"192.168.1.12",10101}

I would obviously put the up address and port of the cvosccv module I’m using. In the osc.send portion, what would I put?

osc.send(dest, "/soup", {1,10})

If possible, could we use the Awake script and cvOSCcv as an example?

I again assume it would be as follows;

osc.send(dest, “/channel.defined.by.module”, ???)

With the question marks being some midi? I’m just curious if someone would mind giving me a more specific answer since this is some of my first exploration in to ANY programming.

I’m looking at the study and I was way off on some of the assumption there. I am going to take a look, rewrite some stuff and see if I can get a better example of what I think MIGHT be happening.

Basically, I would want to try and reform some stuff around this? I am unsure. I just do not know if OSC is capable of more or less receivng the Midi information and translating it. So, I guess it would look something like this. Would I put something about just the midi events in there? Such as:

local osc_out = function(midi_out_device)
  
osc.event = osc_out

[beepboop]

Osc does not understand midi messages, or rather, it doesnt assume anything about the information you put in it unless you tell it to. The API in norns is very straight forward, so you can just give it a path and some data and it will send it.

From the study:

dest = {"192.168.1.12",10101}
osc.send(dest, "/soup", {1,10})

So if you have your destination, port, and address that your app is expecting, all you need to do is figure out what to put in that last argument in the “send” function (the lua table {1,10} above).

If you look, e.g., at the awake script, there is a call to send midi notes twice: the note_offs here, and note_ons here. So if you want to send that midi data with osc, just see what variables are being used at those points and copy them over:

midi_out_device:note_off(a, nil, midi_out_channel)
--adding osc here!
osc.send(dest, "/address", {a,nil,midi_out_channel})

 if (params:get("output") == 2 or params:get("output") == 3) then
        midi_out_device:note_on(note_num, 96, midi_out_channel)
        --and here!!
        osc.send(dest, "/address", {note_num,96, midi_out_channel)
        table.insert(active_notes, note_num)

[kasselvania]

Thank you so much! It can be frustrating, but this is often times the best way for me to learn things like this. This has been a real ‘teach a man to fish moment’ and I greatly appreciate it.

I will report back with a hopefully successful tale.

I am getting closer and closer to getting this running. Seemingly not getting messages all the way to the module.

I am basically running my devices like this (which might be causing me the issue of the signals not making it all the way there):

the norns IP is: 192.168.1.22
My laptop IP is: 192.168.1.4

So, when using the script, I put the dest as follows:

dest = {“192.168.122”,10101}
and in the module (which is pictured bellow) I put the OSC IP Address as: 192.168.1.22

This is how the module looks

For some reason with my settings I have not gotten anything out of the system.
For more information, here is what the osc.send looks like:

osc.send(dest, “/ch/1”, {a,nil,midi_out_channel})

That’s a lot of info on this, but I think once I get it running once, I’ll be good with just about every app necessary!

[okyeron]

Your screenshot shows the device IP address to be 127.0.0.1 (which is localhost). That’s probably why you’re not receiving anything. Dunno how exactly, but you wanna get that device to be your machine’s IP or figure out how to route the external IP to localhost.

[kasselvania]

I had changed that before. The screenshot was just of the module to show what its settings were.

I think that there might be some discrepancies between what Norns sends out and what the module is looking for, sadly. Might not work without a good amount more work on my end, which I’m clearly not up for in regards to development and programming.

[beepboop]

osc stuff can be frustrating, its a little bit of a black box sometimes. I think troubleshooting this too much will make this stray too far from this thread topic, but I will just say, try first sending osc to the app from you computer itself with something like oscsend and see if that works and go from there. firewalls could be involved here too.

[kasselvania]

I might start a separate thread. It really might be a useful tool for a lot of Norns users to be able to easily get Norns midi in to VCV Rack with no additional parts or tools.

Thanks for the tip though!

[Tyler]

Messing around with triggering random samples in Ack. I’m looking for a less convoluted way of playing random samples from a directory. I’m guessing it would be more practical to do this on the supercollider end, but I’m thinking it might require some additions to the norns codebase (ParamSet:add_dir?). Has anyone else spent time doing something similar?

-- trigger random files in the same directory

engine.name = 'Ack'

local ack = require 'ack/lib/ack'

function init()
  ack:add_params()
  
  clk = metro.init()
  clk.time = 0.25
  clk.count = -1
  clk.event = tick
  clk:start()
end

function tick()
  local path = params:get("1_sample")
  local name = params:string("1_sample")
  if name ~= "-" then
    -- get parent directory of a file
    local dir = string.gsub(path, escape(name), "")
    f = GetSiblings(dir)
    engine.trig(0)
    engine.loadSample(0, f[math.random(1,#f)])
    -- print(f[math.random(1,#f)])
  end
end

function GetSiblings(path)
   local files = {}
   local tmpfile = norns.state.data.."files.txt"
   os.execute('ls -1 '..path..' > '..tmpfile)
   local f = io.open(tmpfile)
   if not f then return files end  
   local k = 1
   for line in f:lines() do
      files[k] = path..line
      k = k + 1
   end
   f:close()
   return files
 end
 
function escape (s)
  -- "606-BD.wav" -> "606%-BD%.wav"
  s = string.gsub(s, "[%p%c]", function (c)
    return string.format("%%%s", c) end)
return s end

[zebra]

I guess I don’t see this as particularly convoluted. You could factor some stuff out to reusable utilities to make it cleaner, and you could tidy up the file parsing and string building. I don’t see the advantage of scanning for files in the engine.