trentgill

--- abstracted grid key mappings from functionality
-- demonstrate a simple string-based grid-layout system where each key is
-- addressed with a standard structure. direct handling for row and column
-- groups of keys that all call the same underlying function.
--
-- concept is to have a generic grid handler function, and wrap all of the
-- script specific functionality into a simple table of locations and
-- matching functions that will be called when that key is pressed or
-- released.
--

trentgill

local ag =
    {grid = {}
    ,fns = {}}

function ag.init(tab_or_g, fns)
    if type(tab_or_g) == 'table' then
        -- TODO for version with switchable layers
        ag.grid = tab_or_g.grid
        ag.fns = tab_or_g.fns
    else -- assume grid obj

trentgill

# script clear
# script load: /home/we/dust/code/fledge/fledge.lua
### initializing data folder
# script run
>> reading PMAP /home/we/dust/data/fledge/fledge.pmap
m.read: /home/we/dust/data/fledge/fledge.pmap not read.
Engine.register_commands; count: 0
___ engine commands ___
___ polls ___
amp_in_l

trentgill

how to git.

these are the mental patterns that i associate with git actions. whenever you have the following thoughts, try these actions.

you don't need github to get started. only once you want to share, move between computers, or you don't have a local backup solution.

"yay! this scrap of code is working!"

trentgill

--- teletype-crow expansion

-- how to deal with grid leds?
-- sending the whole frame every tick is too much, even with a dirty flag


-- idea is to maintain the led buffer in a C array
-- grid.set(x,y,s) will directly call a C function which sets the nibble in question
-- thus the backing C array is only 64bytes (128 * 4bits)

trentgill

--- crow: teletype expansion

local TT = {}

--- hardware events
-- overload these fns so when setting the handlers, we activate
-- the ii-communication (to reduce ii traffic if unused)
TT.key = function(state) end
TT.param = function(volts) end
TT.input.trigger = function(n, state) end

trentgill

--- some possible implementations of a probable function
-- really comes down to whether it's a timeline native behaviour
-- or if we just want a general fn to a wrap an application with chance

-- original version without chance
notesss = { 1, kick
          , 1, {ii.wsyn.play_note, s{0,-12}, 2}
          }

-- tl.chance is a function that takes a probability, and an action

trentgill

-- base sequins
s1 = s{0,4,7}
s1(),s1(),s1() --> 0, 4, 7

-- apply a pattern 'transformer' function to maybe add an octave
s1:fn(function(n) return (n>5) and n or n+12 end)
s1(),s1(),s1() --> 12, 16, 7

trentgill

--- when starting a timeline, there is the ability to quantize the 0 beat
-- this lauch-quantization is essentially just called `clock.sync(quant)` before beginning

-- here is a standard timeline loop with default quantization
t1{ duration, action
  , duration, action
  }

-- note that the above is just sugar for this (ie tl() => tl.loop() )
t1.loop{ duration, action

trentgill

--- new elements for sequencing fun!


----------------------------------------------------------------------
----------------------------------------------------------------------
s = sequins

-- table call with a string is treated as a table of chars
cs = s"abcd" -- equivalent to s{'a','b','c','d'}