#1

I’m writing some code that does some trickery involving the parameter menu, and am using functions in _menu to achieve them, but I’m worried about the code smell. Are there any safer ways to open the menu (parameter or others) besides this, other than manually pressing key-1? Also is there some way to make a callback when the menu is closed? Of course I’m asking for the current script I’m working on, but I can see that functionality being useful in other scenarios.

example 

function openSecretParams()
  local i
  
  -- show only secret params
  i = 1
  while i <= #params.params do
    if i < SECRET_PARAMS then
      params:hide(i)
    else
      params:show(i)
    end
    i = i + 1
  end
  
  -- menu macros
  _menu.set_mode(true)
  _menu.enc(1,4)
  _menu.enc(2,-4)
  _menu.key(3,1)
  
  -- show normal parameters when returning to param menu
  i = 1
  while i <= #params.params do
    if i < SECRET_PARAMS then
      params:show(i)
    else
      params:hide(i)
    end
    i = i + 1
  end
  
end
#2

yes indeed this script makes me very nervous, and will likely not work in most cases (ie, if you manually navigate to the LEVELS page).

i’d avoid automating enc and key. just use _menu.set_page

and even though i suggest that, i generally would not suggest having a script do anything with the menu— unless we add a “menu API” for script usage, which will correctly deal with the somewhat complex states the menu can get itself into.

i can sortof gather what you’re trying to do (i think) which is just toggle a specific param list for interaction.

first, i’m not sure why it needs to be hidden, or if that was just an implementation idea. why not just put these in a group? but then there’s still the nav-to-there issue.

the clean way to do this would be to implement a “param” library, which builds a scroller screen similar to how the menu param works… but is to be used inside a user script. this would be somewhat trivial, and perhaps useful to other scripts that just want to embed a subset of params for a particular “page” within the script without jumping to SYSTEM mode

3 Likes
#3

Actually the last thing you mentionned I could see a use case for that in many of the tools I’m already using. Although I do like my endless list of parameters in the system / menu section, have the right section of it appear where the script creator want me to see them appear could add some silent meaning to the way the script is conceived (ie. “I added these params because they’re useful HERE!”) Which is something that’s sometimes a bit problematic where you turn parameter knobs kind of guessing where it’s modulating or why or if it’s even doing something.

It’s also good for modulating sources purposes because it clarifies the signal / modulation path.

If it was complicated to implement then don’t bother, it’s not game changing either. But I could definitely see the use cases for that compared to the current common workflow.

1 Like
#4

This is actually closer to an ideal solution than what I’m doing now. I’m doing a sort of workaround to effectively give objects their own parameters, by making pseudo-parameters whose actions set values to objects in a buffer. But, it’s convoluted and a little hard to keep track of. It would be nice to be able to create different sets of parameters, and be able to localize them inside of a table.

For example


local Object = {}
function Object:new()
  local o = {}
  self.__index = self
  setmetatable(o, self)
  o.val = 0
  o.params = ParamSet:new()
  o.params:add{
    type = "number",
    id = "val",
    name = "value",
    min = 0, max = 127, default = 64,
    action = function(x) o.val = x end
  }
  return o
end

then the parameter page could be viewed with something like o.params:view().
There would have to be some management of views so that different parameter sets wouldn’t be competing.

#5

Got a start on a Parameters Page library by stripping down menu/params.lua from the norns repo. Here’s a link if anyone wants to help out. I’m considering this question answered though and will probably continue discussion in Norns: ideas, or Norns: development.

1 Like