norns: scripting

21echoes · 2020-05-27T21:34:12.561Z

I think the dispatchers abstraction doesn’t really add much value for norns scripts, but the “have a single source of truth for data, and subscribe to its changes” advice has stuck around for decades for good reason. params, despite some small limitations, is a great solution for that in my norns coding experience (saving/loading and MIDI-mappability are awesome things to get for free, too)

Lemmy · 2020-05-28T07:56:38.577Z

That abstraction uses a data store, which is a single source of truth, so I don’t see a contradiction there. The topic I find interesting in this case is having the ability to update the data store from different UI components, and how that might be done without a ‘code smell’ as put in the example.
It’s encouraging that having coded for Norns you haven’t come across much of a need for that. This example was the first thing I have looked at in Norns coding and Lua. The difficulty may have been principally because I was adapting an existing script and didn’t want to reinvent it too much.
All the same I think the case of dependencies between settings is an interesting topic and worth discussing. It’s not an indictment of the current params system and doesn’t cancel out any of its virtues.

zebra · 2020-05-28T11:34:22.303Z

the ‘bad code smell’ here is breaking into the “private” data structure underlying a parameter that has already been :added to the default paramset, making it part of the persistent storage for the script, target of midi-learn, etc.

Lemmy:

the ability to update the same data via a series of different UI components

well, that is fine, but there is no concept of parameter dependencies in a paramset, so there is no particular guarantee that e.g. B will be loaded before A. (in fact, in the example it will be the other way around, so surprising things could happen.)

guess i’m just saying that i would be careful about making the UI component configurations part of the same data store as their targets, at present. this doesn’t mean you can’t leverage control and/or controlspec outside of paramset.

maybe the easiest solution is to just formally guarantee the present behavior: the order in which parameters are :added to a paramset, is the order in which they will update when the paramset is banged. it’s the most basic kind of dependency management but maybe it’s enough.

in any case i’d be more comfortable recommending this if we added ParamSet:set_range(index) to the API in addition to get_range. then we would at least have a shot at managing the edge cases.

if there is desire for something like Flux pattern:
store → events/queries → views → actions → dispatcher → callbacks → store…

then i agree that it seems like asking for more layers on top of paramset and parameter actions.

Lemmy · 2020-05-28T12:49:17.693Z

The great benefit of a flux type approach is the data reactivity. So if you update the data model, from wherever, the UI renders the required updates without imperative programming. That solves these kinds of edge cases because as long as values are initialised with reasonable defaults, then after loading or user input, updates are handled appropriately.
To be clear I’m not espousing a full-blown approach like that in this context because of the overhead. Just as importantly I think it should be easy from a community perspective for people to get into writing scripts. I’m sure you have thought long and hard about these various options and getting the right compromise.

Using event listeners might be a simple way of accessing some benefits of the reactive approach. (Listening to model changes, not to specific user inputs).

But I’m just thinking out loud here, I will stop commenting on this until I know the system a bit better.

okyeron · 2020-06-24T04:37:47.124Z

having trouble with incrementing param values

I have the following - but… my param menu item increments 50 ms for each turn of the encoder.

  local delay_time_spec = controlspec.new(0.1, 5000, "lin", 1, 300, "ms") 
  delay_time_spec.default = 1000
  params:add {
    type="control",id="delay_time_spec",name="DelayTime",controlspec=delay_time_spec, formatter=Formatters.round(1),
    action=function(value) engine.set("Delay.DelayTime", value) end
  }

The step for the controlspec seems to be ignored?

I tried also adding a formatter - but I’m not really certain how that should be used.

What I am doing wrong?

zebra · 2020-06-24T06:59:21.340Z

step is the output quantum

i gather that at some point you are calling something like

params:delta("DelayTime", 1)

the delta method i hard-coded to incremement in steps of 1/100 of the range (maxval - minval), times the increment.

but the increment passed to delta doesn’t have to be an integer, so you can work around this in scripts by scaling the input to delta; unfortunately that’s of no use in the params menu.

i mentioned this a bit here, it would be nice to have an input quantum:

norns: ideas Monome

i can speak the last point a little (with apologies for tediousness.) i agree it would be better if the parameter value were quantized to nearest decibel. i think there is no design reason for the present behavior, just expedience: these are parameters of type control. this means they map a “raw” value in [0, 1] to an arbitrary range, quantum, &c, as defined in a ControlSpec. for example, the output range for compressor post-gain is [-20db, +60db]. (here.) the :delta method for control p…

opend GH issue.

github.com/monome/norns

parameter input quantization

opened 06:59AM - 24 Jun 20 UTC

closed 08:18PM - 30 Jun 20 UTC

catfact

lua

currently, `paramset:delta` is hard-coded to increment in steps of 1/100 of the …range (`maxval - minval`), times the increment. in scripts, its possible to scale the input to the delta arbitrarily, but in menus one is stuck with a quantum of 0.01 times the range (or 0.0005 in "fine" mode.) this is usually fine but sometimes inconvenient. it might be nice to add an input quantum to `ControlSpec`, as well as an output quantum (the `step` field), so that this can be controlled more specifically.

okyeron · 2020-06-24T07:21:54.961Z

Aha! Thanks for the detailed response!

simonvanderveldt · 2020-07-18T11:27:42.023Z

This is also crow related (although I guess a similar situation can occur when using a MIDI to CV adapter as well), but I think this is the best topic for this question.

I was wondering for those who have written something that outputs pitch/voltages for modular/eurorack how you handle the different types of CV inputs on modules?

I’m mainly wondering about the difference between modules that only take a positive voltage as pitch input vs modules that support both positive and negative voltage.

Olivier · 2020-07-30T17:07:31.257Z

I was thinking of putting together a super basic norns + lua tutorial yesterday, which led me to another, probably more interesting and useful idea…a game of exquisite corpse in the scripting realm

The basic idea is that I (or someone) would create a basic tutorial to get started (could be video or written), and then someone picks up where I left off and keeps building the script, turning their work into a second tutorial, and so on and so forth. Whatever I explore and develop in my initial tutorial is by no means set in stone; future participants have the freedom to take the script in a completely different direction.

What I find potentially interesting about the idea is that anyone can participate, and each successive pass doesn’t necessarily have to push the script into further complexity (although it could do that, too). So long as each one sheds light on something new, that’s cool.

Does that sound fun to anyone else? What would we end up with?!

andrew · 2020-07-30T17:09:33.366Z

that sounds very fun to me

could be a live streaming thing

Olivier · 2020-07-30T17:14:30.360Z

Totally! Live streaming scares the shit out of me, personally, but that shouldn’t stop anyone from going that route to share their work/tutorial

EDIT — I’ll try to record a first installment today or tomorrow, and then I’ll create a (wiki?) thread with a sign-up sheet.

tyleretters · 2020-07-30T19:05:28.809Z

What’s your git workflow?

I’ve been connected to smb, then clone my repo in /dust/code/mything. This seems to be the best way? Though I don’t really like having my git stuff in there that I wouldn’t have bundled with the actual release. So maybe I should have this be /dust/code/mythingdev and then once mything is in released and in maiden don’t touch that at all?

glia · 2020-10-02T06:38:09.646Z

soooo

lets say i’m weirdly curious about how to visualize the two orbiting “tape” leds from the ob-4 for an interface

how might i script something that simple in lua?

klingklangmatze · 2020-10-02T07:00:11.251Z

Is that possible with trigonometry? For the x,y values of the individual points: x = rsin(alpha), y = rcos(alpha). Where r is the radius and alpha is an angle between 0 and 360

I know this is not a script yet, but a geometric approach.

bgc · 2020-10-02T08:12:37.551Z

https://github.com/bgc/bgc_dust/blob/master/lib/ui_utils.lua <- this could be a starting point for that.
my shield is still not working, if it was i would code those, seems fairly simple.

from my code you just take out the arc in draw knob and put to squares, 180 degrees apart (or PI radians)

andrew · 2020-10-02T15:18:07.872Z

klingklangmatze:

x = rsin(alpha), y = rcos(alpha)

in lua that should look something like:

loop_time = 3 --(seconds)
radius = 10
framerate = 1/30 -- (30 frames per second == 1/30th second per frame)

metro.init(function(tick_count)
  elapsed_time = tick_count / framerate
  theta = elapsed_time  / loop_time * 2 * math.pi
  pixel_x = math.cos(theta) * radius
  pixel_y = math.sin(theta) * radius

  --- draw the pixel
end, framerate)

(probably : ) )

xmacex · 2020-10-02T17:06:18.573Z

I don’t have a norns to try it (arrives next week, I am sketching this in p5.js), but maybe also the higher level graphics functions such as screen:arc() would simplify things by letting the computer do the math I am imagining something like

loop_time = 3
framerate = 1/30
pixel_size = 1
speed = 360/loop_time * frame_rate

metro.init(function(tick_count)
    screen:arc(10, 10, radius, tick_count * speed % 360, tick_count % 360 + pixel_size)

end, framerate)

glia · 2020-10-02T17:40:24.049Z

thanks yall

when i have time to test i’ll report back but this will definitely help guide my attempts

yaw · 2020-10-02T19:52:57.089Z

Barycenter is based off this motion / idea + a couple nested layers of the same. Cosine & Sine will get you one side, the inverse (1 - Cosine, or 1 - sine) will get you the opposite point.

o[1].x = viewport.width/2 + (math.cos(delta) * radius)
o[1].y = viewport.height/2 + (math.sin(delta) * radius)
o[2].x = viewport.width/2 + (1 - math.cos(delta) * radius)
o[2].y = viewport.height/2 + (1 - math.sin(delta) * radius)

license · 2020-11-15T20:57:55.037Z

@eigen ran into an issue with a script where an animation was not wired up quite correctly, causing flickering when the norns global menu was open. @tyleretters came up with the fix, which was to call the global (userspace) redraw() function, rather than a function in a custom module, on the animation clock. I was not aware before that it had to be set up this way. Is this already documented anywhere, and if not, where would be the appropriate place to add the docs? I apologize if this is the wrong thread for the question.