#121

Hi,
I’m trying to get my head around how patterns operate and I’m finding it a bit confusing.

I had thought that:
//
P.N 1
P.I 40
//

would set the index of pattern 1 to 40 but is having no effect. Another script uses:
//
P.N 1
CV 2 P.NEXT
//
which I thought would move the pattern one step on from where ever the index was so if the second script was triggered following the first it would read step 40 and then move the index to step 41. However the index doesn’t move to 40 and the pattern keeps looping around steps 0 to 7

Also found that commands like

//
CV 1 PN I X
///

Which i had thought would loop through each pattern number reading the index at X position, instead writes X to the current index position - really weird!

I also noticed that the documentation provided in the box uses the term pattern ‘bank’ and also ‘pattern number’ - just to be sure these are referring to the same thing ie one of the currently loaded script’s stored pattern data (0-3)

Is that correct?

Cheers,
Alex

1 Like
#122

Thanks!
Any idea how I can have a trigger switch a pattern length between two values (that are not 0 and 1)? The P.L would start at 64, then on the 1st TR would switch to 32, then on the next TR back to 64, etc…
Apologies if I’m missing something obvious, here…

#123

be sure to set P.L first. P.I and P.NEXT wrap around P.L

unfortunately there’s a bug with using PN for reading a pattern value. i’ll have it fixed in the upcoming firmware update-- many apologies! PN will work for writing values presently.

yes, bank and pattern number are used interchangeably, i should fix the docs for consistency

#124 
X EZ X
Y MUL ADD X 1 32

or:

X EZ X
IF X : Y 32
ELSE : Y 64
#125

Thanks!
So X EZ X flips X between 1 and 0?
When X = 1, EZ X is false, so X becomes 0
When X = 0, EZ X is true, so X becomes 1
Is that how that works?
X would need to be set in the INIT script?

#126

Moved colon, thanks, but still I cannot get TT to accept - IF P.I 0 : TR.PULSE C
Returns - TOO MANY PARAMS IF

However It will accept IF EZ P.I : TR.PULSE C

So I am almost there…

#127

This is the code, which TT is now allowing, but I think I may have run into a bug. I hope not, maybe I’m missing something obvious here, but pattern 2 is not playing all 64 steps when the pattern length is set (on the first step of the pattern) to 64, instead it is only playing 63 steps and skipping the last step.

HEADLIGHTS (the name of the piece)

Clock goes to TR INs 1 and 2. CV 1 with TR A plays melody 1, CV 2 with TR B plays melody 2. Human (for now) plays the underlying chords.

I :
P.N 0
P.L 16
P.I 15
TR.PULSE D (connected to TR IN 8 to extend the INIT script beyond 6 lines)
TR.TIME A 5
TR.TIME B 5

1 :
P.N 0
X P.NEXT
IF X : CV 1 N X
IF X : TR.PULSE A

2:
P.N 1
Y P.NEXT
IF Y : CV 2 N Y
IF Y : TR.PULSE B
IF EZ P.I : TR.PULSE C (TR C is connected to TR IN 3 to execute the next script every time the pattern is at position 0)

3:

P.N 1
Z EZ Z
IF Z : P.L 32
ELSE : P.L 64

8: (extension if init script)

P.N 1
P.L 64
P.I 63
Z 0

The two patterns are melodies represented by note numbers and zeros, which is a nice way to have CV and triggers coming from one pattern. Both patterns are played with P.NEXT in scripts 1 and 2, and the INIT script sets both patterns at the last step so on the incoming clock they will play the first step.
Pattern 2 is initially set to 64 steps, the first clock pulse sets the P.I to 0, and the script to set the pattern length is executed making the length 32, the next time P.I is 0 the script is repeated and Z flips and the pattern is reset to 64, etc

Except the pattern is not playing all 64 steps…

So close… Can anyone spot an error in the code?

1 Like
#128

Ok, this looks like a bug, and if it isn’t, it’s very odd…

I have a scene with two patterns, 0 and 1.
Pattern 0 is preset, 12 steps. Script 1 reads it and using two variables generates CV and gates.
Pattern 2 uses a methodology similar to the SAMPLE AND PLAY scene I posted a week or so ago, the keyboard generates CV and gates and at each gate a number is calculated and added to the start of a pattern. In this case I was wanting to have script 2 add to pattern 1, generate an array, and then later have the scene take over playing the notes I’d input.

Script 2: (the delay is to compensate for keyboard gate being slightly faster than CV change)

P.N 1
DEL 75 : Z DIV QT IN N 1 N 1
DEL 76 : P.INS 0 Z
DEL 76 : P.L 16

Originally I was using variable Y which was calculated the same way in script 1, from the keyboard connected to IN, but when the trouble I’m about to relate occurred I was worried that as Y was associated with script 1 that may cause confusion. I don’t think that was the case but to be safe I created Z which is not mentioned in script 1.

The results were the same either way, the notes values that I wanted to add to pattern 1 were sometimes added as expected, and other times added to pattern 0. Script 2 specifies pattern 1. I’m not sure what more I can do to stop the script modifying pattern 0.

#129

EZ is “equals zero”, a logic test. it returns 0 (false) or 1 (true). it takes one argument, the value to test.

so X EZ X tests if X is zero. if it is TRUE, it returns 1, hence X becomes 1. and vice versa. it’s a trick, sortof.

TOO MANY PARAMS because that first line is incorrect. P.I 0 is a set operation-- trying to assign P.I to zero, but not leftmost, so it’s busted. you’re probably looking to use EQ P.I 0 but EZ P.I is better, so you’re correct on the second try.

trying to spot the bug in the last code but can’t see it on first glance. i’ll test out a similar situation tomorrow. is the 32 step portion playing correctly?

#130

Thanks. So I understood X EZ X… or I guessed right…

And that makes sense with P.I being a set although my documentation says it is get/set hence my confusion. I’ll erase get.

Yes.

#131

the problem is likely that P.N 0 is getting called while the DELayed commands are in queue. can you simply remove the DEL from these? i don’t see why they’d be necessary, but i recall there was some other issue earlier?

edit:

if this is also the same script with the Z EZ Z then Z is getting smashed. for script 3 do this instead:

IF EQ P.L 64 : P.L 32
ELSE : P.L 64

basically, check if P.L is 64. if it is, make it 32. if not, make it 64.

#132

Just to clarify here, P.I is both get & set. If it’s at the leftmost position it is ‘set’:

P.I 15

Sets P.I to 15.
If you’re using a PRE, P.I is no longer the leftmost operator (the PRE is). So in the following, P.I is being read:

IF P.I : do something

In general, when using the IF, ELIF, ELSE PREs, you’ll want to use some kind of logic operator to test for a condition, as you’ve done above with EZ or EQ.

#133

I’d note here, that if you use @tehn’s approach, you could replace the last line of script2 with those 2 lines, and you wouldn’t need the self-patched trigger.

///

Regarding the script with DEL’s in it, I would also DEL the first line by 70 so DEL 70 : P.N 1 will ensure the pattern is changed right before the value is inserted, and not flipped by a different script before it can occur.

#134

Experimented with the DELs and you were right. The line defining which pattern is being edited needs the same delay. Once that was fixed all seems OK.

@tehn - I did try getting rid of the delays but the old problem of the previously selected CV being sampled returned. I’m not sure I completely understand this, but with my WMD / SSF Monolith keyboard, the gate is output very slightly earlier than the CV chosen by the key pressed is changed. Others wishing to use a keyboard gate and CV out to enter data, be warned. Maybe it’s just my keyboard… I experimented with shorter delays but they were not reliable. 70 - 75 ms was needed.

Regarding my general understanding of how TT is working, which should hopefully help me code better - so the various scripts are not actually isolated from each other, or only for composition, and ultimately they all converge into the same stream? Is that the case? I had somehow imagined independent streams of commands for each trigger in…

#135

Yes. There is no need for a variable in this case. In my defense I will blame tehn, as it was his idea, before he came up with the better one.
It is taking some time for my brain to think in the way that TT needs me to, but I think I am getting closer.
Certainly IF 32 64, IF 64 32 is much more elegant.

#136

OK, some ideas. Thinking aloud. Call this the “I’m too lazy to setup patterns manually feature” request.

I’m pretty sure the monome crew will be way ahead of me here - and have a better approach or some coming new features - but I’ll throw this all out here anyway.

I’ve also been drinking a beer or two while flipping back and forth through the various TT studies and docs, so my brain and eyes are a little crossed right now.

Anyway… on we go.

What I was trying to do, lazily : Setup a fast musical pattern coming out of CV1, in a simple scale, e.g. A Minor, with a complimentary second slowly playing pattern coming out of CV2. In other words, a lead line and a bass line.

Or, the bigger picture : make patterns more immediately musically “generatable”, to enable all sorts of interesting melodic and harmonic modulations possible, with a very minimal command set.

After doing a few P.PUSHes to setup patterns (before I tried Tracker mode), I thought there must be a better way to quickly get some simple scales going.

Well, before I get into that, I think P.CLR might be useful, which would set all pattern steps to 0, but also do a P.L 0.

Anyway, back to scales.

I initially thought the following might be useful (written in “pseudo TT code” to be simpler to read!) :

P.GEN A MINOR // generate a pattern of notes from the minor scale in the key of A

Maybe.

How about this as attempt 2:

P.ROOT C // set the key
P.SCALE MINOR // set the scale
P.GEN // generate a pattern using the .ROOT and .SCALE values, i.e. C Minor
P. SCALE MAJOR // change scale
P.GEN // regen a new pattern, this time C Major

Hmmm. Not bad.

How about P.GEN n, e.g. P.GEN 16 would generate a 16 note C Minor pattern.

Or P.GEN n i // generates n notes from the scale, repeated i times.

OK. Interesting. Might not be the right way.

So let’s look at QT (quantize).

After a skim of the manual it looks like I can do some basic quantizations to semi and whole tones, and with some mathematical tricks I could get other things … but not predefine scales.

We could expand QT a bit, so we could go something like (again in “pseudo code”):

CV 1 N QT “MAJOR” RAND 12

That’s a bit more like it.

So let’s then look at the “note tables”, e.g. N 0-127.

Why not something like this:

S 0-10 … which are 10 predefined musical scales / modes. Your majors, your minors, your dorians, etc. You could have your 4tets and other craziness in here as well.

For example, let’s say that S 0 is Major.

So I could then go:

CV 1 N S 0 RAND 12 // pick a random note from the major scale, turning it into a volt, which goes out CV 1.

OK, that feels better.

Maybe.

CV 1 N S 1 RAND 3 // pick a random note from the first three notes of the minor scale

Then with a bit of CV.OFF (offset) I can set the key and away we go.

Anyway … I went on to dream up a visual “Scale Editor” mode, like Tracker mode, as a way to define the scales / intervals / roots … and realised I was getting carried away.

So, here ends the thinking.

Anything useful in here? Any other shortcuts or ideas? Did I merely lose the plot on the 3rd beer?

Brief not-very-exciting MP3 of what I was working on while fiddling with all this. Two oscillators, an 8 bar pattern over a 4 bar pattern, random jumps in pattern position.

20150826-T004.mp3 (2.6 MB)

2 Likes
#137

Here’s the patch I’ve been working on the last 2 days. It’s a reworking of Omni 7th from this album - http://www.lloydcole.com/album/plastic-wood/. The original (from around 2000) was made with Suzuki Omnichord, playing a Country and Western pattern, and taking the midi outs and playing, as I recall, amongst other things a MidiMiniMoog and an Oberheim Xpander.

In this new version all the parts are played by Eurorack modules.

At the beginning of the piece the player plays the root notes on the keyboard and they are sampled by the M script (every 5 ms) and output in all but real time. At the same time the notes are saved to pattern 1, and when pattern one is full, or whenever after that, the patch chord from TR 2 in connected to TR IN 3, the metronome is turned off and the Teletype plays on.
Bass, Kick, and chords are played, with an accent added by Script 4. The Trigger Riot is master clock and it’s div/3 plays the back beat and supplies the echoes and LFOs with sync.

M:
CV 2 N DIV QT IN N 1 N 1

I:
P.N 0
P.L 12
P.I 11
M.ACT 1
M 5
TR.PULSE 4 (continues INIT script on script 8)

1: (this script plays a bass line - pattern 0 alternates between 12s, 19s, and zeros - the zeros are rests and then the 12s and 19s are added to the keyboard in (or later sequence 1) to play tonic and 5ths)

P.N O
X P.NEXT
IF X : TR.PULSE 1
Y DIV QT CV 2 N1 N 1
IF X : CV 1 N ADD X Y
IF EZ P.I : TR.PULSE 2

2: (here the notes for pattern 1 are collected. the delay compensations are due to a latency problem my keyboard has)

DEL 75 : P.N 1
DEL75 : Z DIV QT IN N 1 N 1
DEL 75 : P.INS 0 Z
DEL 75 : P.L 16

3: (here the chord tonics are played, it takes over once the aforementioned connection is made)

M.ACT 0
P.N 1
T P.HERE
PROB ADD 30 T : P.I RAND 15
CV 2 N T

4:
P.N 2
A P.NEXT
IF A : TR.PULSE 3

8: (continuation of INIT)

P.N 1
P.L 16
P.N 2
P.L 12
P.I 11

There are a lot of variables in there and there may be some redundancy but with scripts triggering sometimes simultaneously, sometimes my machine, sometimes by hand I decided to be careful.
If I had one more trigger out I think I could have scripted the cable, maybe using the PARAM knob, but either way that change has to be initiated by hand.

4 Likes
#138

Question :
Is it possible to build a quantizer ? Write a scale in a pattern, have incoming CVs rounded to those values ?

#139

i’ve been thinking of a good way to do this-- will let you know when i come up with something.

#140

@tehn That’s what my long rambling semi-drunk post above is banging on about. Looking forward to what you’ve got cooking.