#1

I’m trying to make something I’m working on less goofy.

I’d like to read the cc number (not the cc value) that has been mapped by the user on the norns parameter page directly in the lua for my script. Is this possible with a param method or some other means?

#2

we don’t have an API for this currently. you could peek into the pmap tables directly, but this wouldn’t be considered future-stable (we could change the internals).

it’s not unreasonable to have some param map functions, however— we’ll try to come up with something.

can you describe your situation for needing this? perhaps i can suggest a different approach

1 Like
#3

Thanks @tehn :slight_smile:

basically looking to not hard code cc numbers in my app.

--midi device
m = midi.connect() 
m.event = function(data)
  local d = midi.to_msg(data)
  if d.type == "cc" then
    --this only works for 16n
    edit = d.cc - 32
    for i = 1,16 do
      cc_vol_list[i] = params:get("vol" .. i)
      print (params:get_id("vol" .. i))
      sliders[i] = cc_vol_list[i]*32-1
      if sliders[i] > 32 then sliders[i] = 32 end
      if sliders[i] < 0 then sliders[i] = 0 end 
    end
  end
  redraw()
end

This is the midi function in the sines app I am working on. At the moment, it is hardcoded for 16n midi cc’s (cc 32-47). Each time a 16n slider is moved, the gui shifts to represent all values for that slider. edit = d.cc - 32 maps the 16n cc values to sliders 1 -16.

How can I achieve the same effect with a midi mapped parameter when I don’t know in advance what cc number has been mapped by the user?

edt: changed example

#4

hmm. this is where i’d just let the parameters + mapping system do its thing. were you hoping to avoid using the parameters? or perhaps just looking to “bake in” 16n functionality?

i ask because if you have the user assign their own mappings to control the vol<x> parameter (which could then adjust all the values this example addresses), then your script doesn’t need to do handle this separately. apologies if i’m misunderstanding! :slight_smile:

1 Like
#5

Thanks Dan!

I guess the crux of it is this:

Each slider controls volume for a simple voice. I want the currently moving cc slider to “bang” and display all the values for that voice on screen dynamically. so when slider 1 that is controlled by cc x is moving, assemble all values for that voice and display them.

…I may not be describing this very well. Basically trying to not have to hard code these cc numbers.

1 Like
#6

no no, i think you explained it well – you want to hard-code 16n compatibility out-the-box, while also allowing a user to be able to map other controllers if they don’t have a 16n, right?

without seeing the larger script (can you link the WIP version?), i’d approach this by generalizing these functions within the parameters so that if a user wants to midi map an alt controller, they can. then, maybe have another parameter that allows a user to specify they want to use default 16n mapping, and do a quick check in the m.event function:

if params:get("16n_enabled") then
  if d.type == "cc" then
    ...

and just send the value to the parameter that would otherwise be midi-mapped: params:set("vol"..i,<value>)

1 Like
#7

Ok yeah I see what your are getting at.

#8

i think this was added after i posted, but if you don’t want to hard-code anything and just want to allow the user full freedom to map whatever sliders + cc’s they want, then definitely keep these functions inside of parameters and just have the user utilize the default mapping mechanism.

1 Like
#9

The code is here btw: https://github.com/aidanreilly/sines/blob/main/sines.lua but i’ve not commited my latest fumblings.

1 Like
#10

i would suggest creating a parameter for each voice volume.

in the action function for each param, you can have it “bang” it’s voice number to a global variable and trigger the redraw so you can dynamically show the values you want.

2 Likes
#11

Ooh. Ok yes I think this would work.

1 Like
#12

You should also be able to provide a default .pmap for 16n

3 Likes