sort of a development question here. if the user enters 0 for the number of delays, what should the expected behavior be? should the code default the 0 to a 1?
the user could use a variable that changes for the number of delays to queue, so I think not queuing delays when passed a 0 should be okay. I don’t see any possible pitfalls with that functionality, but maybe someone can enlighten me.
Agreed, the utility of a second OP is marginal once the first is implemented. I just don’t think the XDEL functionality should directly be called “ratcheting” since it doesn’t fire immediately. As always, let’s work with what we have and not let “perfect” be the enemy of “good enough”.
EDIT: I do think it’s a bit late to be worried about “OP bloat” in terms of “how many OPs there are” (there’s a ton). Bigger concern would be giving up performance somewhere to implement an improvement elsewhere. I can appreciate that the delay buffer size will need careful optimization for XDEL. Thankfully there is already a set of OPs for clearing out the buffer, if needed
a few days later of on/off testing I’ve seen no issues with the op. I did not increase the maximum number of delays, so that may be something I try today. however, I think I’ll leave the decision of increasing the delay buffer to @scanner_darkly, and keep that change out of my branch. still not sure what the consensus is on what the op name(s) should be.
I would like to note that the following snippet of code could be commonly shared between any sort of DELAY op. it’s a small memory optimization, but maybe a common function call could be used for this.
went with XDEL as the op name. additionally added XDEL.R for the functionality that triggers once immediately, then x-1 times at the delay interval.
still need to do some more testing tonight after adding the function call with common delay code delay_common_add. not too sure about the name, it at least works as a filler name for testing purposes.
I’ll take out the commented out sections of code before the pull request. I did want to ask if it’s okay to use names other than a, b, and c for my local function variables? from what I’ve seen it’s a common convention, but I think in this case it makes the code harder to understand.
but it’s not a setting, it’s an action, so doesn’t fall under the 1st category.
if it was something like XDEL.R setting which could be used to enable/disable ratcheting for XDEL (or get the current setting) it would follow the 1st category, but i don’t think there is a benefit of controlling this behaviour generally.
More of a Teletype + Ansible request. Could we have an ansible mode which works as a simple extender of teletype so that grid ops would be passed of the i2c bus and appear on a grid connected to ansible, and the ins/outs of ansible would be extra ins/outs on teletype? Wouldn’t it be lovely to be able to use both grid and computer keyboard with teletype at the same time?
Ah thanks. Do you recall why SCENE x doesn’t run the target scene’s I script?
I’m also curious whether SCENE x reinitializes the default variable values (I’m away from my modular right now but I’ll check when I get home).
I’m trying to figure out how classy TT can get at being a finite state machine sequencer. I’ve made some simple “sequence maps” by having the turtle walk a table of state indices, but there’s not much room for radically different behavior between states. If each scene can be used as a state then all that’s missing is “upon state exit” and “upon state entrance” code. The I script seems perfect for “upon state entrance” but it’s not used with SCENE x for some reason…
probably so that if you have a meta scene that switches between different scenes it would work continuously. imagine having a group of scenes that all do some transformations on pattern data. if you, say, initialize pattern data in the init script then this would happen each time you switch a scene with the op - probably not the effect you want.
i suppose it could be an additional parameter (would require a separate op though as SCENE can be also used to get the current scene number).