#1

Arcify

Easily map Arc encoders to up to four parameters on the Monome Norns (eight with a shift key).

example_01

example_02

example_03

This library was built to solve a problem I ran into, that I wanted an easy way to map parameters to the Arc (I have an Arc but no MIDI controllers).

This is a tool for script authors to add to their scripts as opposed to Norns end-users. The demo app uses TestSine and is not very fun or inspiring.

Requirements

  • Norns OS v2.0 or greater.
  • A Monome Arc (or the desire to support one in your Norns sketch)
  • We [TestSine Engine] (If you want to test this script)

Documentation

Download

v1.0.0 - https://github.com/mimetaur/arcify/releases/download/v1.0.0/arcify.zip

On GitHub: https://github.com/mimetaur/arcify

27 Likes
Cranes
Norns: ideas
Animator
Norns: ideas
Beets 1.1.1
Beets 1.1.1
Norns: ideas
Ableton Push Library for norns
Pedalboard: Chainable FX for norns
#2

Oh very nice. Was definitely hoping for this type of possibility in Norns scripts.

1 Like
#3

By “shift key”, do you mean that this supports 1st gen arc w/ the push button?

Because awesome.

2 Likes
#4

awesome.

any chance this could live on the system wide midi learn page?

2 Likes
#5

Sadly no, I don’t have a push button Arc handy and the built in Norns Arc library doesn’t support it. But if @tehn can fill me in on what it would take to add push button support to the core Norns Arc code, I’d be happy to take a look.

Right now it uses Norns Key 2 or Key 3.

#6

In order to inject the arc parameters there I would have to add a version of this library into the core Norns code, which may be possible via a pull request on GitHub. I’ll take a look at that code.

I could certainly see a simplified version coming “out of the box” with the Norns, and then for more complex applications there’d be room for a separate library.

#7

This library looks really useful for getting started with an Arc though I’ve begun to design a dynamic parameter binding system based on a grid and an arc so I don’t think this will work with the current limits of 8 params across two modes.

Would it be helpful to try and extend this library to support an arbitrary amount of modes? I’m working on the FM7 synthesizer and would like to enable up to 4 encoders to control the phase modulation matrix, which is 6x6. Here’s my initial UI design

  • A grid presents a 6x6 matrix of dimly lit buttons
  • Up to 4 buttons can be pressed at one time, raising their brightness
  • Each button corresponds to a phase modulation point for the operators. For example key 1,2 modulates operator 1 with the output of operator 2.
  • Each button that is toggled picks the first available Arc ring, gets the current parameter value and draws a segment on the LEDs
  • The encoder for that ring now can increase or decrease the value
  • Toggling the button saves the parameter value and clears the LEDs on the ring

I can’t quite think of how I would do this with the current state of the library, since any Arc ring can by mapped to any of the available 32 parameters, then be re-mapped to a new one at a different time.

2 Likes
#8

The built in arc library does support the push buttons of the first gen arc. It’s arc.key()

1 Like
#9

Nice! Then I’ll plan on adding an option to support it.

#10

I’ve been thinking about this, that there shouldn’t be a hard-coded shift button but rather a table of mappings that can be navigated either arbitrarily (like your example using the grid) or linearly through tapping a key multiple times, etc. the current state of the library has the 4/8 so baked in that it would take some rearchitecting.

My other concern is that I want to ensure the API to use it in its simplest form remains easy enough that a novice script writer can write 5-10 lines of code and get easy access to mapping arc encoders in the param screen. I suppose I could solve that with an initialization parameter that puts it in “expert mode”

#11

Could you do this through reassigning what parameter the arc is mapped to via params:set(“arc_encoder_x_mapping”) (alsoat the point at which the user hits the button? I think that takes a number, so I need to expose a public method that gives the library user a table of param names and ids (right now it gets built by a private method called params_as_options)

So you leave the arc with a max of four assignments, but arbitrarily change what it is those assignments are set to on the fly? By a combination of changing the assignment as above and calling arcify:clear_encoder_mapping(x) you could set an encoder to map to a param, and then clear that param when you were done.

Right now the way to arbitrarily remap encoders as I describe above is a mess, it seems like you would be better served with a method like arcify:map(encoder_num, “param_id”)

You also end up with an unnecessary set of params tacked on to your params screen. To get rid of those params I’ll need to expose methods that let you change encoder mappings dynamically through changing the encoder mapping table, rather than the params system. I would need a flag in arcify like expose_mappings_as_params and in your case, that would be false.

Where we’re heading with this is pretty far away from my original “drop in easy arc support” concept for the lib. But as long as we can come up with an expert API that beginners don’t have to worry about, that’s fine.

All that said, this seems possible and I’m happy to help move the library in a more flexible direction. I built it for solving an immediate problem (easy controls for my thesis symposium talk/demonstration this week) but as I begin to imagine more complex scripts I’ll want more power.

(I added a few issues on GitHub to reflect the roadmap: https://github.com/mimetaur/arcify/issues)

2 Likes
#12

I’ve finally got my Norns and have been getting used to using it in MLR mode… I’m using Grids with it… But I’d love to add Arc for control over the fine tune… is there a way to assign it via midi mode to control parameters in MLR while also using the Grids?

Mlr (norns)
#13

It takes adding a couple files and lines of code in Maiden, but check out my Norns library Arcify that lets you choose 4 parameters to be controlled by the 4 encoders.

(And let me know if you hit any problems setting it up)

2 Likes
#14

Many thanks!

Will this run at the same time as MLR Grids?

#15

Basically, you’ll be modifying your copy of MLR, Arcify is a library rather than a typical Norns script.

Rather than choosing it from the Norns menu you’ll:

  1. Download Arcify
  2. Copy the ’lib’ folder inside the MLR folder
  3. Add some of the code found in this file to the MLR script.

Right now, installing the library needs a little bit of familiarity with coding on Norns. I’ve been trying to figure out a super easy, copy-paste-able way to let anyone use it. Let me know if you get stuck on the above steps!

(In the long term I want to figure out integrating it into the Norns exactly the way Midi controllers work, so you don’t even need to add code to your script.)

2 Likes
#16

Does that have any impact if there’s no Arc connected? I was thinking that it would be very useful to add it into @olivier’s Compass to control the loop start & end points.

2 Likes
#17

Following…

#18

It doesn’t cause any errors, it just leaves some unnecessary params in the parameter list. So yeah, feel free to proactively add it to a script! I’ve been meaning to add some pull requests to other folks’ scripts too.

It would be nice to have it test if an arc is connected, and only add params if there is one connected, just to add less cruft. I’ll put that on the list for the next release.

(Mods, this probably should get merged into the Arcify thread btw)

2 Likes
#19

OK, had a shot at adding this today. It works provided I turn the Arc fast, butslow turns have no effect. I’ve instrumented the code in arcify.lua and can see the changes being applied to params at the function at line 344. However it results in the same value for each call as if something is resetting the parameter?
I also note that the code in compass makes a call to params:delta rather than params:set.

#20

OK, changing it from a params:set, to params:delta seems to work better. I’ve noticed that whatever mechanism compass uses when the commands change the loop start & end, that doesn’t get reflected in the Arc leds (though it’s possible that that actually makes sense, the start/end defines the bounds for the softcut start/end).