#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
#130

Test results for firmwware 3.0.0 267A22F

Scene and detailed results below. The short version is that everything seems to work as expected, except that J and K do not seem to be initialized to 0 in each script when the scene is loaded. Values for J and K seem to be saved with the scene. Thanks for developing this - it’s going to be great to have so much extra storage!

LOCAL VAR TESTING
#1
J 10
K 11
X J
Y K

#2
I 20
$ 3

#3
X I

#4
J 40
K 41
$ 5

#5
X J
Y K

#6
J + J 1
K + K 1
X J
Y K

#7

#8

#M
J + J 10
K + K 20
X J
Y K

#I
M.ACT 0
J 100
K 200
X J
Y K

Scene load:
Expected result X=100, Y=100
pass

Trigger script 1
Expected result X=10, Y=11
pass

Trigger script 2
Expected result X=20, Y=unchanged
pass

Trigger script 3
Expected result X=0, Y=unchanged
pass

Trigger script 4
Expected result X=0, Y=0
pass

Trigger script 5
Expected result X=0, Y=0
pass

Trigger script 6
Expected result X=1, Y=1
Repeated triggers count up X Y
fail - X and Y increment by 1 but start at values stored with scene

M.ACT 1
Expected result X=10, Y=20
every metro tick, X increments by 10, y increments by 20
fail - X and Y increment by 10 and 20 but start with values stored in scene

4 Likes
#131

A clocking op for Levels

1 Like
Monome ecosystem firmware development backlog
#132

great! glad to see your testing was mostly good too. should be an easy fix for the one problem you encountered.
J & K are going to have weird behavior with the INIT script because the script will have it’s own local values for them. I guess that’s expected though.

did you do any tests with delays or script calls? that was my main concern, but it seemed to be working fine in my testing.

1 Like
#133

Maybe some polynomial easing curves / transfer functions, either for CV.SLEW or the actual CV value itself?

Right now by using CV and CV.SLEW you can create clock-synced triangle LFOs; by changing the slew time or using CV.SET you can get different slopes and shapes, and by adding delays or using divisions of a clock, you can play with different shapes. But they’re all linear.

I assume sine is probably not feasible for performance reasons (unless there’s already a sine LUT for some reason?), but something like (3 * x * x) - (2 * x * x * x) could approximate it. That would allow creating more sine-like synced LFOs with the same techniques that work for triangles.

4 Likes
Monome ecosystem firmware development backlog
#134

Scripts 2 and 4 were specific tests around the locals when calling a script from another - those worked as expected.

For delays, do you mean the new ops?
DEL.X
DEL.R

I tested those in the previous build and they also worked as expected, but happy to re-test them in this build. Or did you mean there is some specific concern around delays and interaction with the locals? If so, what is the concern? It’s not immediately obvious to me but happy to do more testing. I plan to leave this build on the device and continue poking around until the next one is posted.

#135

I’m a little fuzzy on the complete details, but basically delays use the TEMP_SCRIPT, which I believe primarily is used for live mode. however, the delay code sets the script number to the calling script number instead of the TEMP_SCRIPT number. from what I can tell it should all work fine, but I was worried there was something I could have overlooked.

unrelated there’s a mistake in how the get/set functions are working right now with script index that I’m going to fix tonight. oddly enough the mistake doesn’t break the functionality, but I still need to fix it.

2 Likes
#136

build with the fixes. going to run the same tests as @EqualTemperament and open a pull request if all goes well.

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

edit:
strange behavior again when testing script 6. J and K not being initialized to zero properly I think. looking into it.

edit2:
okay found the issue. I thought ss_init was called when a scene was loaded, but I believe flash_read was the function I was looking for(paging @scanner_darkly for confirmation) .

on this topic in my opinion J & K should be initialized to zero on scene load, but maybe others disagree with that? currently other variables such as A aren’t initialized in this manner. as in they keep their value from the previously loaded scene which makes sense if you’re using the SCENE op.

2 Likes
> teletype: grid # code exchange
#137

libavr32 includes libfixmath which has LUT-based trig methods:

5 Likes
Teletype firmware discussion
#138

I don’t have a strong opinion either way, mostly because I have not written much in the way of scenes that call other scenes. So I don’t have a feel for what would work best here. Maybe others do.

One noteworthy difference between the globals and the locals is that there’s no LIVE mode access to the locals. You can type A 0 from the live command screen and set it, but can’t do that with I J K. Is that a factor in how these should behave?

Without down-voting the slew easing function request because I think it would be useful and interesting, the TXo expander is instant gratification for clock synced LFOs in the Teletype ecosystem. Thought I mention since I believe BPC has a batch in production now.

#139

I think this could be really cool for enhancing the modulation-sequencing capabilities of Teletype, even if it’s a pretty simple/minimal amount control over the slew curve!

#140

yeah i’m not sure why ss_init is not called when a new scene is loaded. when i added grid stuff i just manually added ss_grid_init to do_preset_read (which is located in preset_r_mode.c). my guess is that indeed the idea is that you would want to keep the current values when you switch scenes with SCENE op, and if you need to init a scene you can just use INIT or INIT.SCENE ops. if we follow the same logic then J and K should also keep their current values, but should be reset to 0 in ss_init.

1 Like