#110

I does behave the same way. Keeping values between calls could definitely be useful.

2 Likes
#111

well my understanding of the source code is that a new execute state is created each time, but I isn’t initialized to zero. so it’s just creating a new execute state in the same memory location, therefore retaining values between calls?

#112

it wouldn’t be the same memory location necessarily though. in any case if we want to keep values between calls we would need to store them in the scene state and initialize from that when a new execute state is created (if i understand that part correctly, i need to look at that code)

#113

right it’s not intentional, but that’s the cause of this behavior if I understand correctly.

on your second point I think that could work something like LAST with the values being stored in the scene_script_t.

#114

the behaviour is that it resets it to 0 on each call, according to @EqualTemperament’s test.

yeah, basically store it in the scene state and init it to 0 when a scene is loaded.

1 Like
#115

So to summarize the favored implementation is:

  • J and K are initialized to 0 in each script on scene load, and are not reset to 0 when the script is called. Instead they retain their stored value within the script. So J and K effectively represent 20 new variables (J and K * 10 scripts)
  • When a script is called from another script, I in the called script gets set to I from the calling script (this is the current behavior)
  • When a script is called from another script, J and K in the called script do not get set from the calling script, and instead retain their current value stored in the called script (this is not the current behavior)
  • Potentially an additional new to-be-named SCRIPT op could pass I, and also J and K to the called script

Does that sound right? Thought I’d type it out for clarity, since that and testing are all I can contribute here.

9 Likes
Monome ecosystem firmware development backlog
#116

yep, this sounds right, thanks for the summary!

1 Like
#117

perfect! testing is a huge help don’t downplay it.

I’ll start working on this if it’s the agreed upon behavior then.

4 Likes
#118

Sticking this in here as it seems like the best place for it for now:

I’ve rebased and merged: https://github.com/monome/teletype/pull/165

However GitHub is have a “bad day”, so the PR hasn’t shut, nor have I been able to making any comments on the PR.

I’ll come back to it in a few hours and check that the merge really did happen and hasn’t been rolled back.

2 Likes
#119

Here’s another idea. As usual, I offer it without regard for dev complexity or performance impacts because I don’t know. I could see where this would be high for both.

The idea would be to create a kind of flow control that doesn’t exist today - to execute a command when an expression evaluates to true. I think it would fit nicely as additional stack ops:

S.COND: [expr]
or
S.C: [expr]

So essentially it would set up a watch condition for the specified expression that is evaluated as often as possible without impacting performance. When the condition evaluates to true, it would execute the equivalent of S.POP.

There could also be flavors to pop the entire stack, or maybe even a set number of LIFO stack entries.

S.C.ALL: [expr]
S.C x: [expr]

where x is the number of stack entries to pop. Might also need:

S.C.CLR
to remove the watch condition.

I don’t use the stack all that much. For me, I think this would add a lot of use cases.

#120

I can see the appeal of this - but wouldn’t it break the event-based paradigm to watch continuous changes in the background?

1 Like
#121

Theoretically this is already programmable with clever use of the M script, I think! Granted, if you wanted your M script for something else, maybe this isn’t so nice of a solution

#122

Indeed, I think you could. Depending on the timing accuracy you want, you might have to run metro at a very fast rate, e.g. M! 2. And as you say, it might preclude you from using metro as more of a tempo clock. Not sure if this could be done more efficiently with back end code to evaluate the expression whenever the run loop is not busy doing something else.

Yeah, no idea if this breaks the event paradigm, @Leverkusen . It is still an event; just an internally generated one. But, its a valid point whether this something like this would really go beyond the scope of Teletype’s intended purpose.

#123

an interesting idea but probably not feasible… it would require either running a separate fast timer (so, performance hit) or alternatively it could parse the expression and set up hooks so it’s only evaluated when its value might be changed by other scripts (say, if a variable used in the expression gets changed), which would add complexity to the execution engine. then you’d also have to consider that evaluating an expression could have some side effects (what if you use O variable, for instance?).

also it feels like a pretty special use case. i think adding another metro script could cover this but would be also useful for many other purposes.

#124

My intuition is that it would be possible to implement this without it becoming a recurring background process if the conditions are not allowed to depend on IN or PARAM; only conditions depending on variables would work. For every rule you’d list the variables it depends on, and then, whenever one of those variables is updated, you’d check if that makes the condition satisfied. This doesn’t sound like a piece of cake, but it seems doable.

#125

You beat me to it! (Is this 20 characters yet?)

#126

it should really be 30 chars for teletype threads :slight_smile:

6 Likes
#127

I don’t ever want to leave the Teletype developers short of interesting ideas. (As if…) :slight_smile:

Makes sense, and I wondered if this might be pushing it on complexity or processor cycles. Thought it was worth posting anyway. Sometimes one idea leads to another.

#128

most definitely! especially considering teletype can be used in so many different ways.

1 Like
#129

build for J & K as script local variables. branch can be found at the github link earlier in the thread. testing seemed alright as far as I can tell.

teletype.hex (567.3 KB)
teletype.zip (1.2 MB)

edit: totally messed up on running make format. working on getting that fixed right now.

3 Likes