Is it possible to use OSC or midi in place of K1-3, E1-3?

hey there. have looked up and down the forum for anything about this and didn’t really have any luck.

this is just a thought that has come to mind a few times while using my norns shield. i have it hooked up in a way so i can see it nicely, but it’s a bit of a stretch over my desk to fiddle with the encoders and keys. when im using the encoders and keys frequently it can get pretty tedious. of course, i could just set it up so that its closer to me, but i was curious if it’s even a possibility to map the functions that K1-3, E1-3 accomplish to some sort of external control surface.

1 Like
  • /remote/enc n delta
  • /remote/key n z

here’s the handler in lua, if interested

(@dan_derks doc note)

9 Likes

sorry to bump this- im just a complete noob when it comes to this stuff. have been fiddling around for a while and can’t seem to come up with a solution.

what might be the reason i’m not seeing any activity on norns? this is way i have the path written in touchosc.


i tried changing path and data to the following as well after digging around in the docs for a while:

/remote/enc 1 delta
/remote/enc 1 d

here’s the output i get in maiden

clockwise:

incoming osc message from	table: 0x6350e0	/remote/enc 0 delta
1	1.0

counter-clockwise:

incoming osc message from	table: 0x50bc80	/remote/enc 0 delta
1	-1.0

any help is appreciated, sorry if the answer is staring me right in the face

Try a number for delta

yeah, i had tried that too. i may have been inputting an invalid value of sorts when trying that though

your syntax looks correct, but whatever OSC sender you’re using might be doing something wrong— what app is that? have you tried a different one? can you successfully use the same app to control any other norns params? (see the docs)

i don’t know how touchOSC works, but path arriving at norns is weird, the " 0 delta" portion should not be in the address. (i think you want to put just /remote/enc in the path field, i don’t know how to add a a second data argument though.)

here’s some working supercollider code

~norns_addr = NetAddr("norns.local", 10111);

~enc = { arg n, d;
	~norns_addr.sendMsg('/remote/enc', n, d);
};

// NB that the encoder index is 1-based, and that sensitivity is high in menu mode
~enc.value(1, 8);
~enc.value(1, -8);

norns result:

incoming osc message from       table: 0x3d7bd8 /remote/enc
1       1
2       10
ncoming osc message from       table: 0x3d4938 /remote/enc
1       1
2       -10

(the table print shows each element on its own row. here it is showing us that the OSC argument table correctly contains 2 elements.)

1 Like

i think this is the missing piece with TouchOSC – it doesn’t seem to send two elements, only one.

i ran this test script using TouchOSC with path /remote/enc. the only additional argument you can append is value range. naming the path /remote/enc 1 doesn’t pass the 1 as an argument.

function osc_in(path, args, from)
  if path == "/remote/enc" then
    print("arg 1: "..args[1])
    if args[2] ~= nil then
      print("arg 2: "..args[2])
    else
      print("arg 2 not present")
    end
  end
end

osc.event = osc_in

but, a small code snippet added to a script would allow for TouchOSC control over encoders:

function osc_in(path, args, from)
  if path == "/remote/enc 1" then
    _norns.enc(1,args[1])
  elseif path == "/remote/enc 2" then
    _norns.enc(2,args[1])
  elseif path == "/remote/enc 3" then
    _norns.enc(3,args[1])
  end
end

osc.event = osc_in

then you can just name each OSC path for each TouchOSC encoder UI: /remote/enc 1, /remote/enc 2 and /remote/enc 3. i also found that defining the value range as -0.3 to 0.3 gave the greatest range of control, as the messages accumulate as you turn the touchscreen encoder.

but i guess, tl;dr: unless TouchOSC can allow two elements to be passed in its argument table, this doesn’t seem like a friction-less path forward.

fwiw: enc.touchosc (427 Bytes)

1 Like

someone make a better touchosc seriously

7 Likes

hi @tehn, i appreciate the help

what app is that?

it’s TouchOSC by Hexler. the screenshot is of a portion of the layout editing program.

full editing window

have you tried a different one?

i haven’t, but i feel as though i don’t really need to. they all operate very similarly and seem to have only one path per control (with no second area to specify a data argument.)

can you successfully use the same app to control any other norns params?

yes! i have been able to control various params with it in the past. i have used it to control norns’ levels, reverb, compressor and softcut params as well as to control various elements of cheat codes.

— while writing this dan has already replied with some very good insight! how timely

1 Like

this reminds me, they’re running a beta of a totally new version – hopefully, this sort of stuff has been ironed out. it’s a dope tool otherwise, but these sorts of apparent inflexibilities (or at least non-obvious workarounds) are totally rough

2 Likes

circling back to this for a second- is this a function i would add to each script i planned on using this layout for individually? or is there a more broad area i could add the script to? my primary goal is to be able to control the encoders and keys across the whole system

edit; perhaps in /home/we/norns/lua/core/osc.lua?

yes, in the system osc.lua.

i’m almost positive there is a way to send more data argments from touchOsc but just have not used it in a lot of years.

(… lookin at the manual, less positive.)

@tehn, @dan_derks

it might just be easiest to always respond to /remote/enc/N and /remote/key/N in addition to the current pattern?

[update] PR’d , for your consideration

2 Likes

thanks for the PR, this will work fine


to elaborate on my terse frustration above, my using OSC as only single-value streams is a very limiting approach to to the design of the protocol. there’s a reason OSC is so much better than midi, and multi-argument packets are one of them.

by designing a ubiquitous OSC tool that does little more than MIDI can do, it does a huge disservice to the OSC ecosystem by forcing OSC receivers (such as norns) to conform to a comparatively hobbled param/argument structure.

that’s fair. i would hope they support multi-argument packets in their supposed upcoming update!

thanks a lot for all the help- everything is up and running smoothly!

I’ve been beta testing the new TouchOSC version and it does address these concerns (sending multiple values and types).

I believe they’re hoping for a spring release.

5 Likes

Has anyone made a TouchOSC template to control the encoders and buttons on a shield? I’ve had great success using all of the other templates for grids, arcs, level controls, and the CC2 template. I’m just experimenting with a headless setup to see what 2 shields would be like. I see a lot of awesome videos of people doing cool stuff with multiple Norns. I’ve seen a few pictures of some templates but nothing uploaded.

1 Like

there’s this one: GitHub - felart/Norns-TouchOSC: TouchOSC template for Norns

This got me curious so I went ahead and converted the original to TouchOSC Mk2 and made a first pass at an iPad layout that includes SOFTCUT and CLOCK params

My fork: GitHub - okyeron/Norns-TouchOSC: TouchOSC template for Norns

4 Likes

@dan_derks posted a template earlier in this thread to control the encoders. I expanded that template to added the buttons and tried to match the layout of norns shield. I’m new to TouchOSC (and norns), so anyone else feel free to make this better.
nornsshield_buttons_encoders.tosc (1.4 KB)

1 Like

Awesome! Thanks dude. That’s really close! K2 and K3 don’t work but I’m definitely not complaining. I know even less but I’m gonna look into as much as I can in the TouchOSC app to see what’s different between k1 and the other two. K1 works so this is certainly a great start.

Edit. K2 does work