#43

feedback would also be a great target :slight_smile:

2 Likes
#44

This is fun so far and I don’t even think I have the lfo version yet. Are you still considering getting the grid involved?

Edit I do have lfos. I love this

1 Like
#45

been thinking about tap tempo for the two play heads, maybe k2 as alt with k3 tapping and k3 alt with k2 tapping?

Found this example of calculating tap tempo in lua (non-norns). Does anyone know of norns scripts that already implement this?

I work with other (not necessarily electronic) musicians semi-frequently and tap tempo is super useful in this context and I find myself wanting it nearly everywhere when looping/delay is concerned.

1 Like
#46

While I can see the musical applications of tempo sync, i’m not sure how it would work in this context. That said, I bet a tap tempo delay would be super simple to cook up with softcut/lua. I’ll look into it after I get finished with this next otis update. :slight_smile:

2 Likes
#47

yeah, when I woke up this morning I put a bit more thought into what it would actually look like, and whether such a thing was even appropriate in Otis (given its coco/controlled chaos inspiration). Came to roughly the same conclusion you did (though I still might fiddle around with the idea in a private fork).

1 Like
#48

[ https://github.com/tehn/ash/blob/master/orbit.lua ]

in a nutshell

local t = 0 -- last tap time
local dt = 1 -- last tapped delta

function tap()
   local t1 = util.time()
   dt = t1 - t
   t = t1
   -- update something with dt
end

you could add windowed averaging as in the codeyou linked . though i would avoid their liberal use of # and just use a fixed-size windowing table.

personally i don’t find averaging as musically useful as the ability to fluidly vary the delay time with differently spaced taps.

5 Likes
Norns Beatclock - how to get 32 beats (also calculating bpm)?
#49

oh wow, this is super straight forward.

Thank you for taking the time to lay that out!

#50

Is it possible to get rec:on exposed in the params?

#51

Yes. Are you wanting this to be midi controllable? As of right now only control type params are able to be midi mapped. So an option type param, like rec:on or rec:off, wont be mappable.

#52

Correct. Maybe a rec/softcut input level param then?

1 Like
#53

Unless I am misunderstanding, this is what the input param does. At zero nothing is recorded, and it’s midi-mappable!

#54

Ah. Sorry. Need to test abit more, was just messing around abit earlier with mapping stuff to my nanokontrol. I just had a daughter(my first) 4 days ago, so time is abit scarce at the moment, probably works exactly how I want it to(the monitored signal still passes through even if the input param is 0?). Thanks again for a script that is just a bundle of fun. Will use this for naptime performances for the young one :slight_smile:

6 Likes
#55

Yep! :sweat_smile:

Congrats on the little one!

1 Like
#56

Pushed a small update. Adds feedback and speed as lfo targets, and cleans up some other things. More to come, eventually :smiley:

Re-download and replace/ git pull to update.

Edit: I should mention, assigning a lfo to speed sort of breaks the flip behavior for that channel. This will get fixed as soon as I decide on how I want to do it.

Edit, the second: You’ll likely notice there is an offset param for the LFO’s now. This only affects the lfo when modulating speed. It’s just there to give you the full -4x to 4x speed modulation range.

7 Likes
#57

Curious what the engine level param does. If I have it at any value I can’t tell what it is affecting.

#58

Engine level is there in case someone wants to use lib/tlps.lua in another script that uses an engine. (Otis doesn’t use an engine, so it doesn’t do anything here.)

Maybe I should comment this param out in the lib…

1 Like
#59

ah got it wasn’t sure if it was maybe for soft cut control. Thanks for the clarification. Would be pretty cool to see someone adding an engine in there for standalone fun with Otis

2 Likes
#60

a drunk thought: replace the LFO implementation with a supercollider version of Peter Blassers quantussy…

The Quantussy is a five (5) petaled flower, each petal with oscirator, that creates a rhythm, that triggers quantizations of the movements of the other four oscirators. The Quantussy is thus both based on five (5), but four(4)… and its name also refers to Quantum Physics through its unique “double quantizing” of angular momentum.

Running at low frequencies, the Quantussy is intended to provide ample modulations for the various functions of the COCOs, through inputs “FLIP”, “SKIP”, and “SP.AF”, or “Speed Affect”. The Quantussy petals can also run at audio frequencies, as well as “Balcium” frequencies, depending on a toggle switch.

The center of the Quantussy merits some attention. There is a central indicator-lozenge of 15 Light Emitting Diodes, showing the “Spesal State” of the device. The Spesal State is controlled by touching the “Cercel Nodes”, thus preserving Ciat-Lonbarde’s motto of “touch-sensitive is best!”.

To preserve this precious jewel of silicon encased in finest woods, use patch cords to wire it up in its own self-reconfiguring spasms.

a sobering note: I have 0 super collider skills, but am super into pull requests :sweat_smile:

26 Likes
#61

good reminder to go back and read any of his writings as much as possible. I’m losing it at “indicator-lozenge”

5 Likes
#62

time to start porting some c++

3 Likes