Also running on 3.0. Not a big deal tho, I can live with it.
thanks for confirming!
it might be pointing to some inefficient or buggy code which is why i want to investigate… i wonder if it’s only present on newer edition grids. i only have the 2012 edition grids, will get one of the newer ones so i can test.
I got a Teletype a few weeks ago - getting my head around it has been a great holiday project. Still very early days, but I thought I’d share something I’ve been working on as a learning exercise.
Feeling inspired by Noise Engineering’s Zularic Repetitor, but not having one (nor having room for one!), I thought it would be an interesting exercise to code up some patterns from the Zularic (which are available in the manual), and see how much of that module’s functionality I could emulate, including using a grid to visualise the patterns, select different patterns, and shift the phase of the individual “child” rhythms.
To get started I chose 4 16 beat patterns (Rhumba, Clave, Gahu, Funk 1) from the Zularic manual, transposed them into the pattern memory. For example, P 0 [rows 0-15] contains the top line “mother” rhythm and P 1-3 [rows 0-15] contain the “child” rhythm for Rhumba, and so on for rows 16-31, 32-47, 48-63.
Scripts 1 - 4 render the patterns out via triggers 1-4, and also render the pattern to the top 4 rows of the grid. In the bottom half of the grid, 4 buttons in column 1 jump between patterns, and the 6 buttons in cols 4-5 allow each of the 3 child patterns to be rotated forward and back. Drive the scene with a clock into Input 1 (Script 1 calls the other 3 children - not sure if that is really the right teletype ‘idiom’ - still learning about timing management, metro etc).
With this template it should be possible to create other scenes which have other patterns. It is probably easier to group patterns of the same length into the same scene, and then adjust Script 7 to jump the pattern start and end forward appropriately - I’m not sure it would be that easy to have patterns of variable lengths, but perhaps there’s a way.
I’m sure there may be lots more efficiencies that people could suggest to make this more compact. I imagine in theory that using some shift register math it would be possible to store a lot more patterns by using the “compiled” value of a pattern rather than an explicit string of 1’s and 0’s, but I haven’t tried to get my head around that just yet.
One limitation I’m experiencing with my current set up is that when I plug in an actual grid, I get a lot of weird additional triggers out of TR 3 (well at least the Peaks module I’m triggering is registering additional triggers, although I’m not seeing extra LED activity at TR 3 on the TT). I have a new batch TT, so I’m plugging the grid directly into the TT, so I guess this is an electrical noise issue? Anyone else seen similar things?
ZULARIC EMULATRIX
#1
A PN.NEXT 0; B - + PN.I 0 15 Y
IF A: TR.PULSE 1
IF A: G.BTN.L B 15
ELSE: G.BTN.L B 5
SCRIPT 2
#2
A PN.NEXT 1; B - + PN.I 1 31 Y
IF A: TR.PULSE 2
IF A: G.BTN.L B 15
ELSE: G.BTN.L B 5
SCRIPT 3
#3
A PN.NEXT 2; B - + PN.I 2 47 Y
IF A: TR.PULSE 3
IF A: G.BTN.L B 15
ELSE: G.BTN.L B 5
SCRIPT 4
#4
A PN.NEXT 3; B - + PN.I 3 63 Y
IF A: TR.PULSE 4
IF A: G.BTN.L B 15
ELSE: G.BTN.L B 5
#5
L 0 3: PN.I I Y
X 0
#6
A G.BTNI; B ? % A 2 -1 1
IF < A 3: PN.I 1 + PN.I 1 B
ELIF < A 5: PN.I 2 + PN.I 2 B
ELSE: PN.I 3 + PN.I 3 B
X + X B
#7
Y * - G.BTNI 7 16
L 0 3: PN.START I Y
L 0 3: PN.END I + Y 15
L 0 3: PN.I I Y
L 0 3: PN.L I 64
L 15 79: G.BTN.L I 5
#8
G.BTX 1 3 5 1 1 0 5 6 2 3
G.BTX 15 0 0 1 1 0 5 0 16 1
G.BTX 31 0 1 1 1 0 5 0 16 1
G.BTX 47 0 2 1 1 0 5 0 16 1
G.BTX 63 0 3 1 1 0 5 0 16 1
G.BTX 7 0 4 1 1 0 5 7 1 4
#M
#I
X 0
Y 0
SCRIPT 8
#P
64 64 64 64
1 1 1 1
48 48 48 48
63 63 63 63
1 1 1 0
0 0 0 0
0 0 1 1
1 1 1 1
0 0 0 0
0 0 1 0
0 0 0 1
1 1 1 1
0 0 1 0
0 0 0 0
1 1 1 1
0 0 0 0
1 1 1 0
0 0 1 0
0 0 0 1
0 0 1 1
1 1 1 0
0 0 0 0
0 0 1 1
1 1 1 1
0 0 0 1
0 0 1 0
1 1 0 1
0 0 1 1
0 0 1 0
0 0 0 0
1 1 1 1
0 0 0 0
1 1 1 0
0 0 1 0
0 0 0 1
0 0 1 1
1 1 1 1
1 1 0 0
0 0 0 0
1 1 0 1
0 0 0 0
1 1 0 0
0 0 0 0
1 1 0 1
0 0 0 0
1 1 0 0
0 0 0 0
1 1 0 1
0 0 0 0
1 1 0 1
0 0 0 0
0 0 0 0
1 0 0 0
0 0 1 1
0 1 0 0
1 0 1 0
0 0 0 0
1 0 1 1
0 1 0 0
0 0 1 0
1 0 0 0
0 0 1 1
0 1 0 0
1 0 1 0
0 0 0 0
1 0 1 1
0 1 0 1
0 0 1 1
#G
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0000000000000000
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Summary
This text will be hidden
13 Likes
Hi there - I have a Zularic Repetitor and it’s a great little module - look forward to trying out your script. It’s a perfect idea. You’ve done mighty well in a few weeks! I’m a much slower coder. Can’t help regarding the trigger issue. I’ve have an older TT and have just got used to automatically powering the Grid via battery pack. The one I’ve got lasts for weeks.
A[quote=“chailight, post:243, topic:10084”]
One limitation I’m experiencing with my current set up is that when I plug in an actual grid, I get a lot of weird additional triggers out of TR 3 (well at least the Peaks module I’m triggering is registering additional triggers, although I’m not seeing extra LED activity at TR 3 on the TT). I have a new batch TT, so I’m plugging the grid directly into the TT, so I guess this is an electrical noise issue? Anyone else seen similar things?
[/quote]
Weird things happen if you plug a grid directly into Teletype. I’ve had this sort of thing before so I stopped doing it, to avoid damaging Teletype. Best to buy an Offworld https://market.monome.org/products/offworld-1
Thanks @mlogger - I’ve tried using something similar to an offworld (a y-splitter cable that others have recommended) but saw the same issues. Have been doing some more investigation and it may not be a grid related issue after all.
Also, tehn mentioned is this thread that TT itself can’t really be damaged by using a grid directly: Teletype hardware update
but I guess it’s still best practice to power the grid separately, regardless, so that’s what I’m planning on doing from here on.
1 Like
Yes agreed, what happened to me was I put it in a small 42hp skiff with insufficient power. It did all sorts of glitchy things, sometimes almost powering down with the characters flickering when the grid attached. It also powered off and wiped all the presets and also locked Teletype up. Maybe no damage, but you could potentially lose work if you hadn’t backed up. ( I had backed up so it wasn’t an issue)
@chailight - that’s great, thanks for posting! added it to the code exchange list.
i think you can simplify your grid setup by changing this:
G.BTX 15 0 0 1 1 0 5 0 16 1
G.BTX 31 0 1 1 1 0 5 0 16 1
G.BTX 47 0 2 1 1 0 5 0 16 1
G.BTX 63 0 3 1 1 0 5 0 16 1
to this:
G.BTX 15 0 0 1 1 0 5 0 16 4
and yeah you can definitely pack trigger sequences of up to 16 bits in each pattern value (or variable) - check out BGET, BSET and BCLR ops!
very strange about triggers on TR 3 when plugging in grid - i don’t think i’ve seen a behaviour like this before, even when plugging in directly. does it happen if you try it on a completely empty scene?
odd behavior on TR 3 is a production issue with the latest batch of Teletypes!
2 Likes
somebody should try and decode the noise - it’s probably a hidden message about the NEW THING!
4 Likes
Thanks @scanner_darkly - BSET and BGET look super useful. I can see how I could potentially encode a whole 4 part rhythm with just 4 “magic numbers” stored in the pattern.
For example “King 1” looks like it could be encoded as four numbers: 2741 2741 813 813.
I’ve done some initial experiments around unpacking that kind of info into the grid. For example
L 0 15: G.BTN.V BGET I PN 0 0
seems to work ok in terms of unpacking the first part of the rhythm and with some adjusting for button id’s then the same can be done for the other parts - it starts to get tricky fitting everything into the line length tho!
It took me a while to get my head around the number limits in Teletype. I tried converting a binary number to an integer using a random conversion script that Google threw at me. A 16 beat rhythm might produce a decimal integer value like 37160, which is higher than the upper limit of a TT number storage type, which I guess is technically a “signed short”, rather than a “signed int”.
Once I realised that, then I found a more useful conversion site here:
http://www.binaryconvert.com/result_signed_short.html?hexadecimal=B5AD
Playing with that, I started to get my head around it more. if there is a beat on the very first note of a 16 note pattern, the decimal value will be negative.
A pattern like this: 0011010110101101 is encoded as 13741, while
a pattern like this: 1011010110101101 is encoded as -19027
This is stirring some memories of comp sci classes from a long time ago - hopefully my ramblings here have not confused the matter for anyone.
Hopefully I’ll have an updated version with more patterns embedded soon. The current version of the script is obviously much more friendly for every day editing, so I guess there’s pros and cons to both.
teletype numbers are signed 16 bit integers, so the possible range of values is -32768 to 32767. negative numbers are represented using two’s complement - that’s what pretty much every computing system uses, and this is why you get negative numbers if you set the most significant bit: for instance, doing this: BSET 0 15 results in -32768.
when using binary ops (BGET / BSET etc) you don’t have to worry about remembering how two’s complement works, unless you need to convert a binary value (like a drum pattern in your case) to a signed decimal value teletype uses, say if you need to initialize a variable. in this case yeah you can just use an online converter tool, or if you’re on windows you can use the calculator app switched to programmer’s mode. or just use the live screen and manually set the bits with BSET.
axe thing one
For the guitarist in you. Hopefully the video will serve as a quick manual.
requirements
- only tested on ER-301 firmware 0.4.10+
- requires teletype 3.0 beta with
J,Kops
download
axe thing one.zip (3.2 MB)
installation
- axe thing one.txt is the teletype file. rename it to ttXX.txt where XX is the scene number you want to load it into. copy to your USB drive root, and load on teletype
-
slot1 is an ER-301 quicksave. copy the files in the folder to one of the quick save folders on your ER-301 SD card. then load that quicksave
/ER-301/v0.4/quicksaves/slotX
other notes
- the ER-301 quicksave comes with 6 acoustic guitar samples inside the quick save folder, so it should load ready to play
- the first 6 or so default chord presets are in the key of G major. you might have to select a preset button other than #1 to get things started the first time
- some fun stuff to try would be using something other than acoustic guitar samples, trying some different tunings (e.g. bottom two strings doing bass)
13 Likes
For some reason when using teletype 3.0 ( I havent tried previous firmware), TR1 aka clock output doesnt follow the clock that I send to input 1. Any idea why that could be happening? It sort of skips certain clock pulses, but stays in sync. Maybe the issue is with the clock pulse width?
it sounds to me like TR.TIME 1 might be set longer than the time between clock pulses coming in?
1 Like
are you seeing something similar to this? Teletype dropping TR.P -- with video :-)
i’m planning to look into it when i get a chance.
edit: actually not sure that’s related. could you describe what happens exactly and post your script?
Teletype / Grid Ops Rene / Rungler… getting there.
I’m working on a scene to make a Make Noise MATHS, plus an STO (or whatever), and a QPAS (or whatever). Into a sort of melodic Benjolin. Using shift register methodology to create patterns and fluid variable, based upon just 2 gate/trigger ins, from the two MATHS function generators.
It’s not a deep as a Benjolin or a Rene. But it seems like a playable ‘instrument’.
Overview -
Script 8.
CV input of notes to the melodic sequence pattern. Shift register style. Once there are 16 values, any new first value is added and the 16th (now pushed to 17th) is deleted. Keeping the pattern 16 steps long. These values can be entered at any time.
Scripts 1,2,3
Triggers/Gates 1 and 2 generate the Rungler values. Trigger 1 is the ‘oscillator’, Trigger 2 is the clock. A 4 step sequence/shift register is created and a 4 bit value is generated.
The second row of the grid displays the current (Z) rungler value 0-15.
The 7th row of the grid displays the current (Y) intermediate variable value 0, 4, 8, 12…
These two trigger/gates also clock the melodic pattern.
Trigger 1 advances the melodic seq by 1 step, Trigger 2, by 4.
Script 4 plays the basic melody. Taking the data generated by scripts 1-3 and the grid.
The 16 steps are represented by a 4 by 4 square of buttons at the centre of the grid. Any of the stages can be muted. The default - unlit button setting - is unmuted.
Script 5 randomises the melody using the Rungler value and the buttons to the left of the square. More buttons pressed, more random.
Script 6 sporadically transposes the melody using the Rungler, the fader at the bottom of the grid (semitones), and the buttons to the right of the square.
Script 7 generates stepped and smooth CVs from the Rungler.
The top row or the grid is a fader controlling the gate length of TR.P 1, which plays the melodic part. High values will mute some triggers.
Apologies, again, for video glare making the centre 16 buttons into an indistinct blur…
RENE RUNGLER
#1
X EZ X
PN.NEXT 1
TR.TIME 1 LSH G.FDR.N 1 6
$ 4
#2
G.REC 0 1 16 1 0 0
PN.L 0 4; PN.INS 0 0 X
PN.L 0 4
Y + * 4 PN 0 2 * 8 PN 0 3
Z + Y + PN 0 0 * 2 PN 0 1
G.LED Z 1 15; $ 3
#3
G.REC 0 6 16 1 0 0
G.LED Y 6 15
L 1 4: PN.NEXT 1
TR.TIME 1 LSH G.FDR.N 1 6
$ 4
#4
G.GBTN.L 0 4 4; A PN.HERE 1
IF EZ G.BTN.V PN.I 1: CV 1 N A
IF EZ G.BTN.V PN.I 1: TR.P 1
G.BTN.L PN.I 1 8; $ 7
IF NZ G.GBTN.C 1: $ 5
IF NZ G.GBTN.C 2: $ 6
#5
B QT DIV Z G.GBTN.C 1 1
EVERY B: PN.INS 1 Z PN 1 15
EVERY B: PN.L 1 16
#6
C QT DIV Y G.GBTN.C 2 1
EVERY C: CV.OFF 1 N G.FDR.N 0
EVERY 2: CV.OFF 1 0
#7
T TIME; TIME 0
CV 2 VV LSH Z 5
TR.TIME 2 15; CV.SLEW 3 / T 2
EVERY Z: TR.P 2
CV 3 VV LSH Y 5
EVERY Y: TR.P 3
#8
DEL 20: D DIV QT IN N 1 N 1
DEL 20: PN.L 1 16
DEL 20: PN.INS 1 0 D
DEL 20: PN.L 1 16
DEL 20: CV 1 N D
DEL 25: TR.P 1
#M
G.GBX 0 0 6 2 1 1 1 6 0 4 4
G.GBTN.L 1 2 4; G.GBTN.L 2 2 4
G.FDR 0 0 7 16 1 0 5 6
G.FDR 1 0 0 16 1 0 5 0
TR.TIME 1 150
M.ACT 0
#I
G.RST; X 0; Y 0; Z 0
L A D: I 0
PN.WRAP 1 1; PN.I 1 0;
G.GBX 1 20 0 3 2 2 1 3 0 3 1
G.GBX 2 23 10 3 2 2 1 3 5 3 1
PN.L 1 16; M.ACT 1
10 Likes
Thanks!
I’m a little confused regarding where things like these should be posted. There’s the original TT code exchange page, here. There’s this page, and there’s your page at GitHub. Sharing here feels right, but don’t want to add redundant posts…