update metro syntax to match norns update

[tehn]

see monome/norns#572

[trentgill]

see 0268d01..ab02b8b

• rename .alloc to .init
• .init takes either a table or a arg list

i also added a class fn called 'assign_all()' which:

• allocates all the timers
• assigns default _crow.tell() events: ^^metro(chan,count)

usage is in the README. in short:

function init()
  metro = Metro.assign_all()
  metro[1]:start(1.0)
  metro[2]:start(2.0, 100)
end

the user can then alias the metros if they desire:
mycounter = metro[1]

i understand it's an extra layer on top of the norns metro system, but it makes it feel way more like the rest of crow to my mind.

please reopen this for discussion if you want!

//
edit: changed name from 'auto_metros()' to 'assign_all()` ce140e9

[tehn]

just a heads up that norns sortof automatically does assign_all as default behavior.

metro[0...32] are available always. but metro.init() provide an "unused" timer, to avoid collisions. on script reset the metros are "cleared" (ie, turned off, marked as unallocated). (there are actually 38 or so metros accessible, but the high numbers are protected for menu use in norns.)

it'd be nice to do something similar, so that people can either use numbered metros or name them.

a big aim for me is syntax consistency between norns and crow. we can of course introduce changes to norns as well if seen fit.

[trentgill]

i'm a little vague on "metro[0...32] are available always".

doesn't the user still need to run metro[1] = Metro.init() or something?
the point of assign_all is that the .init() procedure is not needed.

the problem with assign_all is it means the .init() procedure will fail as all of the metros are already assigned. i don't see how both functions can be simultaneously available.

edit: @tehn

[tehn]

on norns metro[1] ... metro[32] are allocated at startup. so they are always available to the environment.

named_metro = metro.init(...)

is basically a helper function which keeps track of which metros (1-32) are allocated (there is an internal allocation table).

of course you can still direct-access an already-allocated metro with the subtable... ie, even if named_metro got allocated metro[1] you can still play with metro[1] directly (but this is not really advised).

not necessarily relevant to crow: when norns scripts get cleared, all the metros get turned off and allocation table cleared.