I does behave the same way. Keeping values between calls could definitely be useful.
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?
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)
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
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.
So to summarize the favored implementation is:
Kare 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
Keffectively represent 20 new variables (
K* 10 scripts)
- When a script is called from another script,
Iin the called script gets set to
Ifrom the calling script (this is the current behavior)
- When a script is called from another script,
Kin 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
SCRIPTop could pass
I, and also
Kto 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.
yep, this sounds right, thanks for the summary!
perfect! testing is a huge help don’t downplay it.
I’ll start working on this if it’s the agreed upon behavior then.
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.
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:
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
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]
x is the number of stack entries to pop. Might also need:
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.
I can see the appeal of this - but wouldn’t it break the event-based paradigm to watch continuous changes in the background?
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
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.
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.
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.
You beat me to it! (Is this 20 characters yet?)
it should really be 30 chars for teletype threads
I don’t ever want to leave the Teletype developers short of interesting ideas. (As if…)
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.
most definitely! especially considering teletype can be used in so many different ways.