rhythm

[tomara-x]

• impulse() -> reset_v() steady pulses

• ramp() ^ (>() | >() | ...) for percentages kind of triggering (you can mix them all and pass them through one rise btw) (bus the >() nodes)

• for an on/off gate thing, i was thinking get()? but that would have an issue. so something like [1,0,1,0,0,1,1,0] -> get() and then feed a counter into that. should work fine, but that 7th step wouldn't have a rise, it's just a long continuous 1 from the beginning of 6 to the end of 7 so...

  • you can multiply the input trigger by the value (clean fix, more wiring)
  • you can make it a [1,0,1,0,0,1,2,0].. anything that's a rise (dirty fix, less wiring)

(for live, use a select and var()s instead)

• tuplets (inside tuplets (inside tuplets))

  • can select() a bunch of ramps at different frequencies but they need to all be reset by the driving trigger (and their frequencies be multiples of the frequency of the driving trigger) (nesting tho?)
  • sequence the frequency (multiplier) of a ramp (still no ability to turn off specific steps)
  • multiply the frequency of the trigger and do counting

• nested resets?

  • okay, that's cool!

girl, they're all painful to work with! you can do better

[tomara-x]

don't forget to say hi to euclid

a good place for NetIns to shine! hehe you wanted to get rid of them how many times? so you do the algorithm in process and the output is an array that's set to the NetIns. then the node is just reading (can we have the same for get()?)