#689

20 characters of Timber?

#690

yeah I might need to spend more time with Timber (keys). thatā€™s what I initially tried, but it was loading one sample across the entire keyboard. I need 2-3 on specific keys only (triggering with my feet while playing bassā€¦ havenā€™t gotten around to getting a midi footswitch yet)

#691

Looking at the docs real quick - Timber Player says ā€œclip launcherā€ which sounds right for what you described.

1 Like
#692

cool, thanks! will spend more time with that - I had only been using Timber Player (w/ grid) up until now.

#693

Is it considered bad practice to just run an n FPS redraw loop? I feel like itā€™s more efficient to just do task based redraws but itā€™s certainly convenient to leave the display refresh in itā€™s own semi-self-contained function.

#694

no i think thats totally legit

2 Likes
#695

you can add a dirty flag where change actions happen, and then conditionally redraw in the main clocked redraw function. this way your redraw function doesnā€™t happen more than the fps, and less is ok.

highly recommend this method for grid redraws.

screen version below:

dirty = false

r = metro.init()
r.time = 0.05 -- 20fps (OLED max)
r.event = function()
  if dirty = true then
    redraw()
    dirty = false
  end
end
r:start()

function key(n,z)
  if n==1 then
    number = number + 1
    dirty = true
  end
end

function enc(n,d)
  if n==1 then
    number = number + d
    dirty = true
  end
end

function redraw()
  screen.clear()
  screen.move(10,10)
  screen.text(number)
  screen.update()
end
3 Likes
#696

Oh this makes perfect sense, thanks! When I was skimming scripts and came across this approach I thought it was doing the opposite, forcing extra draws. I get it now.

#697

Having submitted a pull request to add arcify support to the compass script, I started wondering about how to handle the case where arcify wasnā€™t installed.

Is this the preferred way of handling something like this, or are there other preferred ways of doing this:

3 Likes
#698

Hello, does anyone have an example of simple LFO implementation in Norns?
I couldnā€™t immediately find anything off-the-shelf in norns/docs.
I was imagining adding some simple ā€˜warbleā€™ to the softcut rate, for exampleā€¦
Thanking you kindly :blush:

1 Like
#699

@Justmat did that with Otis:

2 Likes
#700

@Molotov, the LFO setup stuff is in otis/lib/hnds.lua. It should be pretty simple to include the lib in another script, at least this was my hope when I wrote it :sweat_smile: Feel free to shoot me any questions, if you decide to go that route!

3 Likes
#701

i might suggest including arcify in the PR itself, so the script references its own local copy in its lib folder.

generally this is the best way as it locks the expected version of the lib. unfortunately we canā€™t do it with engines because of the sc collisionā€¦ but weā€™re working on that for 3.0

3 Likes
#702

This looks great thanks, so Iā€™m assuming itā€™s ā€˜safeā€™ to include a copy of the library in my script folder?
(I know duplicate engines can cause issuesā€¦)

1 Like
#703

yes you can include duplicates of the .lua files!

3 Likes
#704

Yep, just throw it in a yourscript/lib folder!

1 Like
#705

I have a hazy idea of something I want to do, but those of you with Linux chops and who are more accustomed to working on lower powered computers like the Norns might be able to help me.

On my desktop machine, I do a lot of projects where Unity and Max are firing all kinds of OSC data back and forth, or maybe something is going to the browser with web sockets. A lot of these involve multi-agent simulations, flocking, etc.

Iā€™d like to do some projects on the Norns using similar techniques, or non-multi agent stuff using algorithms like perlin noise, lorenz attractors, etc. The problem Iā€™m facing is my initial experiments (especially multi-agent stuff, even like particle systems) were clogging up the main thread, which is super irritating because it makes the UI sluggish. So Iā€™ve been thinking about pushing off this work to a an additional script running separately on the Norns - it could be Lua, it could be Python, whatever. A few questions came up though:

  1. Does that guarantee itā€™s off the main Lua UI thread? Or is there more to it?
  2. How should it best communicate? OSC? Piping text output?
  3. How do I manage this separate script in the context of the Norns interface being able to start and end my script?
  4. Can I avoid users of my Norns script having to deal with any weird extra dependency processes when they install, or at least minimize them?
#706

Thanks for doing this! Iā€™ve been a little hesitant to go around adding pull requests with Arcify to other peopleā€™s scripts - when I do it it feels like self promotion.

I think the long term solution might be to figure out an elegant design that pushes this type of support up a level into the Norns as a whole, while also being smart enough to not override scripts that have a genuine use for Arc as an interface. @tehn might have some ideasā€¦

2 Likes
#707

No, thank you for arcify! I was just scratching my own itch in getting quicker hands on control of compass, and more than happy to contribute the changes back.

#708

Iā€™m working on an issue with norns meadowphysics at the moment, was wondering if anyone had any insight. Currently, triggers are firing a step early I think. It manifests it self especially clearly when triggering adjacent rows, the slaved row will be a step ahead of the master row. If they are cyclically linked, they will drift in phase.

Iā€™m working my way through the original meadowphysics engine lua but havenā€™t cracked it yet. Any suggestions would be much appreciated!

It looks like it might be a race condition of some sort, when the slaved voice (triggered by another voice) is at full clock speed, it seems to skip the first step in itā€™s cycle. Which is visible in this video, the fourth row shows this effect:

https://vimeo.com/365447995