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.
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.
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.
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”
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’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?
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)
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:
Download Arcify
Copy the ’lib’ folder inside the MLR folder
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.)
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.
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)
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.
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).
