Teletype 3.+ feature requests and discussion

[mlogger]

A clocking op for Levels

[alphacactus]

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.

[Starthief]

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.

[EqualTemperament]

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.

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.

[alphacactus]

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.

[alphacactus]

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.

monome/teletype/blob/2b978ba0d4659fc61c6737646145044318836204/module/flash.c#L86-L102

[zebra]

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.

libavr32 includes libfixmath which has LUT-based trig methods:

monome/libavr32/blob/master/src/libfixmath/fix16.h#L122-L126

[EqualTemperament]

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.

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?

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.

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.

[alanza]

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!

[scanner_darkly]

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)

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.

[rikrak]

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.

[scanner_darkly]

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?

[rikrak]

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

[scanner_darkly]

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

[alphacactus]

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.

[scanner_darkly]

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

[misuba]

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

[scanner_darkly]

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.

[rikrak]

That sounds great! 20 characters of perfect.

[alphacactus]

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.

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