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

Just wanted to say: DEL.X/DEL.R is a really great addition to the Ops. Thanks @alphacactus!

EDIT: Ooh! I have (an unrelated) feature request. I wish we could comment out a line with ALT + / but before pressing return to commit. Or is there a way of doing it already? @scanner_darkly would know.

3 Likes
Monome ecosystem firmware development backlog
#142

you only need to commit when you enter a new line, right? so you want to be able to start entering a new line and then comment it out before it’s committed?

#143

Yes. I want to be able to add a line of code which is not going to be executed until I un-comment it.

#144

i see, yeah, that’s a good use case! should be easy to do, i’ll add it.

2 Likes
#145

ok great, so I’ll move the initialization out of flash_read and back into ss_init. also I believe I need to modify INIT.DATA and other relevant INIT ops for initializing J and K.

1 Like
#146

probably just INIT.DATA, and maybe INIT.SCRIPT and INIT.SCRIPT.ALL?

#147

Is there gonna be visual feedback on a commented line that’s readable at all when the line’s empty?