seems a minor typing shortcut, and adds an auto-counter that will require (as @scanner_darkly points out) some form of RESET which is way to vague of a op term (reset could apply to any many things, ie, KILL).
furthermore, consider this:
T ADD T 1
IF % T 4: TR.P 1
ELSE: TR.P 2
auto bassdrum + hihat filling the in-between pulses
in a sense, EVERY seems like a shortcut with less flexibility than just using standard conditionals-- if that’s useful for people to get using TT, perhaps that’s enough of an argument for its inclusion?
How about EVERY.SYNC to reset all every counters to MOD-1 or 0, depending on whether you want the condition to be true on next call or not. (I can’t see resetting an individual counter by script and line number TBH)
Obvious advantages of EVERY:
Automaitic counter increment and reset
60 independent counters
Clean, readable syntax
I would argue that it expands the capabilities of the Teletype in addition to being a shortcut to common conditionals.
Quick, without EVERY, create a clock divider that divides by 13, 16, 17, 19, 23, and 25 with no errors. Each general-purpose variable and line of code you don’t use earns you 1 bonus point. (</tongue_in_cheek>)
I toyed around with the idea that each EVERY call would touch the if_else_condition flag, so that you could:
EVERY 4: // kick
ELSE: // hat
Would that have any support? I think it’s logical and readable, but that’s subjective.
Nothing, the first three times. TR.P 1 the fourth. Technically, LIVE mode commands are all SCRIPT 11, COMMAND 1, 1-indexedly speaking.
Actually, you can stop an every by disabling (commenting) the line with <Alt> + /.
I agree. I forgot that there are a few other tricks recommended in the Advanced section, such as interstitial, always-executing commands between IF and ELSE, and this would break that if there were an interstitial EVERY.
Hmmm… how about EVERY X: and OTHER:?
If you set it to 0, the next call to EVERY will not fire, as the count would increase to 1.
If you set each counter to its own MOD value minus 1, each next call to EVERY would fire.
right-- but OTHER would then assume there’s a previous EVERY, so the idea is that it looks up an index position of the previous line? what i was suggesting was a global true/false of the most recently run EVERY. then the lone OTHER is not necessarily bad, just weird (aka interesting)
this is interesting as another feature in this set. OTHER would then make even more sense perhaps to reference the most-recently true/false of EVERY/SKIP
ok, i’m into these. i propose an un-subbed SYNC to sync both EVERY and SKIP (and clear the OTHER state)
The resultant behaviour right now is that the new mod is applied to the old value immediately before the increment. The count could be zeroed to “reset it” or set to mod - 1 to force it to fire immediately when the mod changes, or it could only do that if the mod shrunk beyond the current count.
Edit2: EVERY RRAND 1 10: should probably be equivalent to IF EZ % O RRAND 1 10:
i was leaning towards @tehn’s reasoning that an existing IF % already covers this and provides more flexibility. here is why: in addition to reset i’d want to add an offset, which would be an equivalent of doing IF EQ 2 % T 5, basically comparing the result of MOD with an arbitrary value. and i’m starting to like an idea of having a dedicated op for comparing the result of MOD op, like %= X Y Z or %EQ X Y Z being a shortcut for EQ Z MOD X Y.
having said that it does seem to fit well within the ecosystem, it’s concise, logical and non coder friendly, especially if supplemented with additional sync and skip, and i would most definitely use it if it became available!
this also makes me think again i’d love to see more variables. especially with a couple of new variations: variables that are local to a script (like I will be), this would work really well as a temp variable where you don’t have to worry about it being overwritten by another script, and a variable that acts like O except that it increments on each script execution, not each time it’s called (but otherwise would behave like O).
i would say that when your complete cycle is 38630800 long you won’t notice when some of the counters reset too soon