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

[sademik]

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.

[tehn]

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

here’s the handler in lua, if interested

(@dan_derks doc note)

[sademik]

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

[robotfunk]

Try a number for delta

[sademik]

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

[tehn]

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)

[zebra]

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

[dan_derks]

@zebra

here it is showing us that the OSC argument table correctly contains 2 elements

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)

[tehn]

someone make a better touchosc seriously

[sademik]

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

[dan_derks]

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

[sademik]

@dan_derks

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

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?

[zebra]

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

[tehn]

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.

[sademik]

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!

[okyeron]

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.