#1101

I did. It threw an error (can’t recall what it was now, sorry).

#1102

@carvingcode, @okeryon

so, yeah. all C functions called by lua are static in matron/src/weaver.c. it’s a somehat verbose and brittle FFI but that’s how we’re doing it. in lua, all indices are 1-based. the conversion to 0-based always happens in the glue function in weaver.c (when possible.)

for example, setting a grid LED:
https://github.com/monome/norns/blob/dev/matron/src/weaver.c#L1098

and indeed, the grid rotation glue function does not perform this conversion:
[ https://github.com/monome/norns/blob/dev/matron/src/weaver.c#L1156 ]

but the question is, is “rotation” really an index? or is it considered a multiplier (of pi/2 radians?)

1 Like
#1103

I was going to test and throw a PR up when I have time later. If you think it needs to change somehow other than the 1-based index fix, please let know.

Edit - I’ll raise an issue and get some more feedback from the gang on github

1 Like
#1104

personally i don’t see a need to change it, since i agree with your interpretation of the rotation as a value and not an index (what would it be indexing?) that said, i don’t recall ever personally wanting to change grid rotation, thus i have no skin in the game. (or should i say “zero”)

@carvingcode well sorry, i don’t see anything obviously wrong. i’m not on a machine at the moment that can (easily) emulate the norns environment. if i were, i’d just try going down the call stack (starting with your script’s init function, which is called in a non-obvious way from core/script.lua) and printing the value of the options array to see when / why it is getting nil. (in other words, a completely typical debugging strategy.)

clearly the “options” parameter class works, in general; so maybe it is indeed something strange related to your use of the expression-key table syntax.

#1105

Is add_options() able to receive a table fully populated (keys and values)?

Edit: the grid rotation works fine using just the 0-3 values. Just my interest in UI that’s causing the problem.

	-- working, not ideal
    params:add{type = "number", id = "grid_rotation", name = "Grid Rotation", min = 0, max = 3, default = 0, 
		action = function(value)
		grid_device:all(0)
		grid_device:rotation(value)
		grid_device:refresh()
    end}
```
#1106

i see what you mean - all other usages in the repo use implicitly-indexed arrays (like {"one", "two", "three"} (like Jonny said, these are still key/value pairs - the keys are just numbers starting with 1.)

but it should work, AFAICT, at first glance…

e.g.

Lua 5.3.5  Copyright (C) 1994-2018 Lua.org, PUC-Rio
> a = {["one"] = "1", ["two"] = "2"}
> for k,v in pairs(a) do print(k,v) end
one	1
two	2
> b = {"one", "two"}
> for k,v in pairs(b) do print(k,v) end
1	one
2	two

that said - just try changing the table initialization syntax to use literal keys (implicit or explicit makes no difference.) there might be something subtle i’m not grokking, w/r/t passing around tables that use expression keys.

1 Like
#1107

Looking over your example, I made the following change to the table setup:

local grid_display_options = {["0"] = "0", ["90"] = "1", ["180"] = "2", ["270"] = "3"}

Ran it. Did not receive an error from the ‘option’ param class/function. (remember, when the values were ints, error in options reported.)

But when I went in to adjust the screen rotation, it throws a different error:

lua: /home/we/norns/lua/core/screen.lua:187: bad argument #1 to 's_extents' (string expected, got nil)
stack traceback:
	[C]: in function 's_extents'
	/home/we/norns/lua/core/screen.lua:187: in function 's_text_right'
	/home/we/norns/lua/core/screen.lua:135: in function 'core/screen.text_right'
	/home/we/norns/lua/core/menu.lua:603: in field 'redraw'
	/home/we/norns/lua/core/menu.lua:555: in field 'penc'
	/home/we/norns/lua/core/menu.lua:142: in function 'core/encoders.callback'
	/home/we/norns/lua/core/encoders.lua:57: in function 'core/encoders.process'
#1108

ok look - clearly the “options” parameter type assumes you will give it a numerically-indexed array of strings. you’re giving it something else. the first time, you gave it an array of numbers indexed by lua expressions that returned strings. then you changed the values to strings but didn’t change the keys (which was my suggestion - sorry to be unclear.)

maybe this will work - certainly you can still call pairs on such a table - or any other table - but if it doesn’t work, and that limitation makes you unhappy, then be prepared to investigate.

in the spirit of “teaching to fish” i will just say that this call stack gives you everything you need to understand what is breaking.

if you just want it to work, i’d just make the grid rotation a “number” (in [0, 3]) instead of an “option” because in the end, that’s exactly what is going to be sent to the monome library.

and for the moment (like, unless someone wants to kindly update the options params class to extend its functionality), i think we should document the usage of options to make it clear that is intended to be used with a simple list of strings, and how its default value and action function work.

1 Like
#1109

Sure. Just thought it was interesting results.

I’m using just the numeric array just fine. No problem. But in a UI, the numbers don’t represent anything to users.

There’s a lot in the monome world that is quite “code-ish”. Good for coders. But extend beyond coders and it’s not helpful. That’s where UI can help.

I’ll not hammer away at this as it seems updates to underlying code may be necessary.

1 Like
#1110

cool. (i agree with that assessment btw.)

anyways, if you want to just use “options” to change the display, how bout something like (untested!)

local grid_display_options = {"0", "90", "180", "270"}
params:add_option("grid_rotation", "Grid Rotation", grid_display_options)
params:set_action("grid_rotation", function(x) 
    local val = x - 1
    grid_device:all(0)
    grid_device:rotation(val)
    grid_device:refresh()
end)

in other words (and sorry for all the noise,) i think the confusion boils down to 2 points:

  • in the options parameter type, the action function takes the numerical index of the selected option as its argument. (TIL: something funky happens if the options don’t have numerical indices.)
  • the last argument to options creation is the default numerical index, and it is 1-based. (in this case, the default option is the first one, so the last parameter is not really needed.)

see this example in the mix menu page:

and - thanks for investigating! i learned things.

#1111

Hell yeah! That’s where I’m coming from, can’t wait to start creating. What sort of things you playing with? Maybe we should create a UI specific thread for UI dev work.

1 Like
#1112

This works! Geesh… I tried something like this earlier, per @okyeron 's suggestion. But I obviously formatted it differently and incorrectly.

Thanks for “teaching by example”.

4 Likes
#1113

Glad you got it working – sorry for the extra noise with the key/pair idea, but maybe it’ll lead to something else in the future. :tired_face:

1 Like
#1114

Finally ordered one.

I’m very excited.

4 Likes
#1115

Nice solution, I’ve seen that the midisport 1x1 is 29 euro, that and a midi-usb Y cable should do it.

#1116

still on one…i synced from usb and I have lots of small files clutter (duplicates but small size). Passerby crashes. I deleted most of them but still passerby crashes. what’s the best thing to do? reinstall?

#1117

can you explain what you mean by crashes?

#1118

in both less concepts and passerby after a while sound stops.

#1119

that’s unexpected. you’re on version 1 (not the beta) correct? can you try turning off the aux reverb and see if it still crashes?

#1120

one yes, it was/is off…why only passerby?