#41

well the downside I see for two ops is that

  1. op bloat, not sure if this is really a concern

  2. two ops doing very similar things where the second op is only really there to save 1 line of script space(not that 1 line should be neglected)

if we want to go down the rout of two ops I would propose XDEL with its current functionally, and XDEL.R or something along that line for the Ratchet feature

also DEL.N / DEL.X and DEL.R could be possible op names? for me it’s whatever makes the most syntactic sense, so I’m not picky just throwing ideas out there.

#42

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.

#43

I think it makes the most sense for a zero to mean no delays queued, yeah.

1 Like
#44

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 :slight_smile:

#45

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.

ss->delay.count++;
ss->delay.time[i] = a;
ss->delay.origin_script[i] = es_variables(es)->script_number;
ss->delay.origin_i[i] = es_variables(es)->i;
copy_command(&ss->delay.commands[i], post_command);
3 Likes
#46

i think it should be safe to double the number of delays, but further increase should be tested in more extreme conditions (or the whole delay system should be reviewed).

for name i like either NDEL or XDEL. DEL.X would probably make more sense for something related to the original DEL op (like additional parameters or settings).

agreed on allowing 0 as a valid value exactly for the reason you mentioned.

re: shared code snippet - definitely! avoiding code duplication is good. heads up - i’ve just opened a pull request so you’ll need to rebase once it’s merged (shouldn’t result in any conflicts).

1 Like
#47

great! I’ll keep an eye out for it. is there any sort of naming convention to follow for such a helper function?

#48

there are naming patterns for other helper functions (like the ones that deal with scripts or patterns, for instance) but nothing for delays really. so whatever makes sense!

1 Like
#49

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.

code and branch found here:

2 Likes
Teletype firmware discussion
#50

not sure about XDEL.R naming, dot notation is mostly used for 2 main reasons:

  • some setting related to the original op: DRUNK.MIN, TR.TIME
  • a way to group related ops: P.NEXT, P.I, INIT.CV, INIT.DATA

i would go with something like XDELR or RDEL

(i’ll answer dev related question in the dev thread - let’s keep this one for feature discussion)

#51

XDEL.R could be thought of as related to XDEL, imo. RDEL is perhaps much less clear as to how it differs, just from the name, but does save two characters.

#52

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.

#53

Right, I was thinking of it as falling squarely into the second category.

#54

then i’d go with something like DEL.X and DEL.R

1 Like
#55

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?

3 Likes
Monome ecosystem firmware development backlog
#56

not sure this would be feasible (should just test this at some point…), would probably require improving i2c implementation, not a trivial task…

#57

Was there talk previously of OPs which load / save scenes, or did I dream that?

#58

SCENE x to load a scene, no op for saving scenes.

1 Like
#59

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…

1 Like
#60

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).