Arcify

norns
#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

23 Likes
Norns: ideas
#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()

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

1 Like