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

libavr32 includes libfixmath which has LUT-based trig methods:

5 Likes

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.

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!

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

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

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?

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

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

2 Likes

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

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

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

i think an empty line will always start uncommented. and if you start typing something and comment it out, then delete what you entered, at that point it should become uncommented again.

3 Likes

That sounds great! 20 characters of perfect.

would the slew time be the period of the sine wave?

updated the top post with the latest master build.

3 Likes

As in, should the time set by CV.SLEW in the case of a sinusoidal slew correspond to the period of the sine wave? I think if we want to be consistent with the behavior for linear slew, we should instead have it correspond to the time it takes a sine wave to go from trough to peak—half the period.

3 Likes

Hope it’s ok if I throw a couple more pennies into the wishing well.

Next level USB Storage Ops

Ability to bring up a directory listing of *.txt files on the root of the USB stick and select one to load into a memory slot without having to use a computer to rename it. Possibly an option to save current scene only to USB? Ability to name it something other than ttxx.txt?

Options for SCENE Op

Currently I think the SCENE op works exactly the same as loading from the keyboard or by using the panel button with the exception that the I script is not executed automatically.

So calling SCENE does reset grid ops, I think? Could there be variations on the SCENE op that would not do a G.RST? Wondering if this might be a way to avoid having longer/more/phantom scripts. E.g. you could use all 10 scripts in one scene to do grid ops and other setup (slews offsets, etc.), and then at the end call another scene to do all the processing. I guess it could potentially get a little confusing with a grid op button or fader calling a scene that’s not really in the current script… might need more discussion but thought I’d throw the idea out.

2 Likes

ok that makes sense.

cv.slew already outputs a linear ramp. you don’t have to worry about the rate. i assume you just to turn the ramp into a half-cycle sine scaled to [0, 1].

call the linear ramp output x, you want (cos((x+1) * pi) + 1) / 2

y = fix16_cos(fix16_mul(fix16_add(x, fix16_one), fix16_pi)

and then scale back to [0, 1]

y = fix16_add(y, fix16_one) >> 1

(untested!)

note that there are different options for libfixmath sine approximation that can be selected in the preprocessor. to use the LUT define FIXMATH_SIN_LUT somewhere. otherwise there is a less accurate parabola appoximation and a more accurate higher order polynomial

1 Like