I’m wondering if the following can be done with a teletype:

I’d like to visualize live loops of different lengths on a grid.

The idea is to map a button of the grid to a pedal looper unit of an ER-301. When pressed (1) it records, when released (0) it plays the loop.

I can count the time elapsed between the two states of the button (record and play) using LAST, store the value in ms in a variable and then divide this value by the width of a fader but the second part is more complicated: incrementing the value of this « dot » fader at regular intervals. I tried to use DEL.X and DEL.R to do that but I can’t make it work. I don’t know much about the internal timer of the Teletype. Can it be done without an external module, without external triggers ? Edit: There’s no easy way to re-trigger the DEL.X when it reaches the last command, so I guess my question doesn’t really make sense…

1 Like

I would probably just use the script that the grid ops button calls do update the display. I may not be understanding your question. If you need to do something at regular intervals the Metro script seems well suited.

1 Like

Thanks for your reply :slight_smile: Yes I could use LAST to set the tempo of the internal metronome and then update the value of a fader but (correct me if I’m wrong) there’s only one metro. The idea was to reflect the position of different/ asynchronous playheads on a grid, I should have exposed the goal like that in my previous post sorry, something like MLR. I don’t own Norns so I was looking for a similar solution using Teletype and ER-301 :smiley:

Oh, I see now. You could set metro to run very fast, say 50ms though you could go faster if needed down to M! 2. When the record button is released, set some pattern variable (say in P.N 1) to the total loop length in msec. And also set some corresponding pattern step (say in P.N 2) to 0.

Then each time metro is called, increment that value in P.N 2 by LAST. These value pairs in P.N 1 and P.N 2 should then be the ratio/percentage of how far the loop has progressed and you could update the fader(s) to display that percentage.

Then the only other tricky bit would be that if the values in P.N 2 are exceeding the loop length in P.N 1, reset them to 0 plus the difference - basically wrap them around the loop length in P.N 1.

That’s what I’d try, anyway.

1 Like

Thanks ! I’m trying the solution you provided, it seems to work. Here’s what I have so far, script 5 writes the length of the recorded loop in PN 0 then PN 1 is the current position in ms (it starts playing, looping as soon as the button is released) and PN 2 is the position of the fader It’s not fully optimized but each fader moves/loops from 0 to 15 at its own speed.

M:
SCRIPT 1; SCRIPT 2

I:
G.FDR 0 0 0 16 1 2 0 3
G.FDR 1 0 1 16 1 2 0 4
G.BTX 0 0 2 1 1 1 0 5 2 1
M! 2; INIT.P.ALL

1:
J PN 1 0; K PN 0 0
PN 1 0 WRP + J LAST $ 0 K
PN 2 0 / PN 1 0 / K 16
G.FDR.N 0 PN 2 0

2:
J PN 1 1; K PN 0 1
PN 1 1 WRP + J LAST $ 0 K
PN 2 1 / PN 1 1 / K 16
G.FDR.N 1 PN 2 1

5:
J G.BTNI
IF G.BTNV: PN 0 J 0
IF EZ G.BTNV: PN 0 J LAST $

// (not connected to ER-301 yet)

Edit: I’ve added the code for two asynchronous faders and two (latch) buttons for recording/playing. I’m not sure what I’m going to do now : reverse or speed change, I’ll try. At least the first goal (visualizing two asynchronous loops on a grid) is reached :slight_smile: / video for info.

Another version with speed control and reverse (work in progress^^)

#1
J PN 1 0; K / PN 0 0 A
PN 1 0 WRP + J LAST $ 0 K
PN 2 0 / PN 1 0 / K 16
G.FDR.N 0 PN 2 0

#2
J PN 1 1; K / PN 0 1 B
PN 1 1 WRP + J LAST $ 0 K
PN 2 1 / PN 1 1 / K 16
G.FDR.N 1 PN 2 1

#3

#4

#5
J G.BTNI
IF G.BTNV: PN 0 J 0
IF EZ G.BTNV: PN 0 J LAST $

#6

#7
IF EZ G.FDRV: BRK
IF == G.FDRI 2: A G.FDRV
IF == G.FDRI 3: B G.FDRV

#8

#M
SCRIPT 1; SCRIPT 2

#I
G.GFX 0 0 0 0 16 1 2 0 3 1 2
G.BTX 0 0 2 1 1 1 0 5 2 1
G.GFX 1 2 4 2 5 1 2 0 7 2 1
M! 2; INIT.P.ALL; G.GFDR.N 1 2
G.GFDR.RN 1 -2 2; G.FDR.PR 2 4
G.FDR.PR 3 4
1 Like

I had a similar requirement (independent speeds) when I was writing a Scene a few months back.

I did it by storing separate speeds in the table as ‘timers’. Each timer value decreased by 1 every cycle. When a timer reached zero, the lit cell (or ‘ball’) moved right and the timer was reset.

I needed to have multiple balls per grid line and the balls accelerated as they proceeded. So not quite the same, but I did write comprehensive notes that may help.

3 Likes

Thanks for sharing, it looks fun :slight_smile: I’ll take a closer look at the code

Recently got my TT so still grappling with the ultra basic stuff - I’m trying to construct a backbeat with Mutable Plaits, switching between the Kick and Snare models with CV and trig from TT.

Can someone explain why I’m getting a result where sometimes the CV switch doesn’t take place about 10-15% of the time? The TR output sends signal as expected.

Can’t see the fault in my code, but maybe there’s something I’ve missed. I was playing about with probabilities before this, but I still get the same result after turning off and on. Also tried both triggers externally and with the keyboard, with no change.

Here’s my code:

EVERY 2: CV 1 VV 0
OTHER: CV 1 VV 50
TR.PULSE A
1 Like

And if you add a small delay between the Cv change and the pulse ?

DEL 10: TR.P 1 ?

Edit: And is VV50 enough to jump to the next model ?

Ahhh… DEL 20 fixes it! Thanks!

1 Like

Depending on the module you’re sending the cv / trigger this is often a good solution. If I’m correct it’s more often for digital modules handling both pitch and envelope generation.

1 Like

5 posts were merged into an existing topic: Teletype 3.0

Hi all, so just finished the TT studies, it is quite a big lot to have to register in the head, but definitely enjoying the process. There is something that came up twice that I have no idea what it really means, if someone could please shed some light as to what it means “Smoothing”? When you avg out some numbers, its referred to as smoothing? Lost.

the analogy is really with graphs and/or filtering. The idea is this: when you’re generating random numbers, you might see big jumps in the value of the number you get, and for some applications, this big jump is undesirable. But, if you average the last two values you got, now suddenly your big jump is much smaller. If you were to graph this, the graph of the averaged values would appear to have more gentle changes than the raw values.

It turns out that if you want to implement a low-pass filter digitally, this same idea ends up being what you do: the filtering “smoothes out” the high frequency content (aka the spikiness or big jumps), giving you something which changes more slowly and gently.

6 Likes

I think what’s missing to make sense is over time. You’re not just averaging a batch of numbers, but averaging them over time. For example, if you sample the param knob every 100ms, you could by turning it quickly get big differences between numbers. And that mean big/harsh jumps that could be jarring musically.

By averaging the old value with the new value you are effectively reducing the gap.

For example, the param knob is at 0. You turn it to 100.
If it takes the value every 100ms and average previous and current value you will get:
0ms: 0
100ms: (0 + 100) / 2 -> 50
200ms: (50 + 100) / 2 -> 75
300ms: (75 + 100) / 2 -> 87
400ms: (87 + 100) / 2 -> 93

and so on.

5 Likes

Thanks @alanza and @electret for the replies and generous explanations!

I think I understand now!

3 Likes

Happy to have made the first patch with just type today! Really enjoying the TT!

3 Likes

Thinking about how cool the 16n Faderbank would be with Teletype, I realized I already have a sort of 6-slider faderbank in my rack… Stages.

From there I threw together a quick scene to poll and memorize a hands-on sequencer, with some scaling to make voltage ranges a little friendlier:

Patch sequencer output to TT cv input
Patch TR.1 output to sequencer step input
Patch TR.2 output to sequencer reset, if available (Stages doesn’t have it)

Patch trigger input 3 to clock, or use internal metronome.
Patch CV.3 and TR.3 outputs to whatever you’re controlling.

Set X to 0-3 to select the pattern
Set Y in the init script (or manually) to the sequencer’s length.
Run script 1 to perform polling

I:
TR.TIME 1 10
X 0
Y 6

1:
PN.L X 0
TR.P 2
DEL.R Y 20: $ 2

2:
TR.P 1
PN.PUSH X / IN 2

3:
CV 3 PN.NEXT X
TR.P 3

I originally wrote a continuous polling version, but it was silly because I could just use Stages directly. (And if I had a 16n, I would almost certainly read the values in real time instead of messing with storing them in a pattern. Unless that’s slow.)

This has some trouble trying to poll in a more automated way while playing back (say, every time PN.I X is 0). I believe if you use an explicit counter instead of PUSH that will fix it.

3 Likes

After having revisited the Just Type studies, Teletype has flown back onto my radar. With a burgeoning interest in coding (zero experience thus far) and the new edition just coming out, now seems like a great time to get involved.

Are there many people out there using Teletype as a small part of a larger system? To clarify, I have a 7U setup that I’m pretty happy with right now but Just Type seems to be along the lines of what I’ve been looking to get out of modular music for a while. JF is probably my favorite module and I’m really interested in the pair, particularly in terms of polyphony. I don’t know that I’d necessarily want it to be the foundation of my setup but it almost seems like a waste not to get one to pair with JF.

I guess to reduce my question down to its most basic form - is it crazy to consider getting TT only for JT stuff? I’m sure it would inevitably lead down a deeper Monome rabbit hole but that’s mostly all I’m interested in for now.

1 Like

I started with TT which led me to the TXo’s and TXi’s along with Just Friends, Ansible and modding my ER-301 so everything could talk i2c. With so many voices talking in the background I stepped up for a Grid and an ARC. Add a W/ to top it all off, thinking about a second one. The rabbit hole is real, be aware.

4 Likes