#582

I’m having a headache try to do this with the grid ops :

IF one button of group 1 is held down, set the value under the Turtle to the PARAM value, but only once a move in PARAM has been detected.

Any help ?

#583

you’d need to store the previous param value in a variable (or a pattern value), then when a button is pressed you compare the current value to that. for this to work you also want to scale the value to a smaller range as it will always fluctuate a little, so it’ll look like it constantly changes.

1 Like
#584

Has anyone developed a LPG response-esque AD or ASR envelope they’d like to share (either using CV outs on Teletype itself or experimental TXo modes)?

On the AD side, it’d be nice to also do a 1-param-knob transforms of A and D to control the duration of blips in a pleasant way.

This type of thing should be rather easy to code, but I’m wondering if anyone has done the trial-and-error of getting the response to “feel” right

#585

I don’t feel like Teletype scripts are the right tool for the job, given the available ops.

Linear ramps are pretty easy (CV.SET, CV.SLEW and CV). The first thing I would try would be multing a CV output through both inputs of a ring modulator to get exponential curves. Alternately, using an exponential VCA with a fixed CV offset to convert the linear ramp to a curved one – or some sort of triangle-to-sine waveshaper, maybe.

Otherwise, maybe a two-stage linear ramp is a close enough approximation – putting a second CV.SLEW command on a very short timer. I’m not sure whether Teletype’s timing is tight enough to accomplish that though.

Several weeks ago I brought up the possibility of a CV scaling function as a possible Teletype OP, for this purpose and for sine or sine-like LFOs.

1 Like
#586

The TO.ENV... series of OPs look pretty straightforward. Unfortunately I no longer own a TXo to help you figure out a good response range for ping-y envelopes.

#587

This is something i’m curious about as well. Check out the TO.CV.LOG example

Summary of TO.CV.LOG example from manual

|TO.CV.LOG x y|-|-|The following example creates an envelope that ramps to 5V over a logarithmic curve:

TO.CV.SET 1 V 5
TO.CV.LOG 1 2
TO.ENV.ATT 1 500
TO.ENV.DEC.S 1 2
TO.ENV.ACT 1 1

When triggered ( TO.ENV.TRIG 1 ), the envelope will rise to 5V over a half a second and then decay back to zero over two seconds. The curve used is 2 , which covers 0V-5V.

If a curve is too small for the range being covered, values above the range will be limited to the range’s ceiling. In the above example, voltages above 5V will all return as 5V.
1 Like
#588

…oh, I see there’s a TO.CV.LOG op. Nevermind what I said :slight_smile: I don’t know the TXo.

1 Like
#589

Well, not really, I think.
When i hold the button down, it should check the PRM value once, then wait for a significant change in the value, and keep the last value when leave the button up.

#590

yes, you save the current param value when a button is pressed in a variable, and then when the button is released you compare and update if different.

the obvious issue with this approach is you will only get the new value when the button is released. if you want to monitor the value while the button is pressed you’ll have to do that in a metro script. there is no way in teletype to continuously monitor PARAM or IN value and trigger some action when it changes - you would need to constantly poll/compare in metro script.

1 Like
#591

Clarifying question: The docs for I, J and K all say something like this:

each script gets its own J variable, so if you call
a script from another script you can still use and modify J without affecting the calling script.

This means that if I do something like J 0; SCRIPT 1, script 1’s J will be set to 0 as it runs, but if I alter it inside Script 1, the calling script won’t see any change, right?

#592

no think of them as variables with scope specific to each script. in that example the J value of the calling script will be set to 0, and the J value of script 1 will be unaffected.

however, you are correct that if you modify the value of J in script 1, then J will still retain a value of 0 in the calling script.

essentially J and K add 20 additional variables, two per script(including METRO and INIT scripts). maybe an easier way to think of them is like so:

J-METRO, K-METRO //only accessible in the METRO script
J-INIT, K-INIT //only accessible in the INIT script
J1, K1 //only accessible in script 1
J2, K2 //only accessible in script 2
...
J8, K8 //only accessible in script 8
4 Likes
#593

ahhhh, so only I functions like how I describe. Thanks for the clarification!

#594

yes I think one of the ideas behind the ops was that you could for example call a script using a loop like so.

L 0 4: SCRIPT 2

then in script 2 store the I value into J or K, thus allowing you to use another loop.

J I
L 0 4: X ADD X J
3 Likes
#595

So, I’ve got this running, but there is a problem :
If I move the PRM knob when not holding the grid button, the PRM is grabbed and Z is updated. I don’t want that. I want it to update only if I move the PRM knob after having pressed the grid button.
The reason is that the button(s) will have an action when I simply press them (like a “live mode”) and another action when i hold them (“edit value mode”).

STORE PRM WHEN HOLD

#1
M.ACT G.BTN.V 1 // toggles metro with the button
X + 7 G.BTN.V 1 // X is 7 when  the button is released, 8 when pressed

#2

#3

#4

#5

#6

#7
Z PRM // updates Z 

#8
Y ABS - Z PRM
IF GT Y 1000: TR.P 3; Z PRM // detects a knob move
IF GT Y 1000: X 7 // switches to script 7 to write values

#M
$ X // triggers either script 7 or script 8

#I
G.BTN 1 0 0 1 1 0 7 1 // the button
P.N 0; Z PRM
M 200
#596

I managed to make it work. I needed an extra variable.

STORE PRM WHEN HOLD



#1
M.ACT G.BTN.V 1
A PRM
X + 7 G.BTN.V 1

#2

#3

#4

#5

#6

#7
A PRM
IF G.BTN.V 1: Z A

#8
Y ABS - A PRM
IF GT Y 1000: TR.P 3; A PRM
IF GT Y 1000: X 7

#M
$ X

#I
G.BTN 1 0 0 1 1 0 7 1
P.N 0; A PRM
M 200
3 Likes
#597

if i correctly understand what you’re trying to do i think you could simplify the script:

#1
A PRM
M.ACT G.BTNV

#M
IF < ABS - A PRM 1000: BREAK
A PRM; TR.P 3
Z A

#I
G.BTN 1 0 0 1 1 0 7 1
M 200; M.ACT 0
4 Likes
#598

I’m experimenting with the cellular automata algorithms, using @dan_derks’s very helpful script here

I’m interested in whether it’s possible to alter the CA rules dynamically, either based on a trigger or using the param knob. But can’t think of a way to change the Init script etc. Is there a way to do this?

Derks CA Recipe

#1
X CHAOS
Y SCALE 0 255 0 13 X
CV 1 N PN 0 Y

#M
$ 1
IF BGET Y _: TR.P 1 # fill the blank with any number 1-8
IF BGET Y _: TR.P 2 # fill the blank with another number, 1-8
Z SCALE 0 16383 0 2 PARAM # performative gesture
CV.OFF 1 V Z # jumps octaves on demand

#I
CHAOS.ALG 3
CHAOS.R 30
CHAOS 36
M 190

#599

putting something like CHAOS.R RAND 255 into a script will change the rule randomly upon triggering.

depending, you might get better results by putting CHAOS instead of CHAOS.R: effectively changing the initial value, rather than the rule.

4 Likes
#600

(running off to try this, thank you!!) :bowing_man:

#601

This is much less accurate. Z gets wrong velues. Try for instance to set it to 0. not sure why, though.