#1258

That is very puzzling! Can you try typing KR.CV 4 at the “>” prompt and see what it gives you for different notes?

UPDATE: Hmmm… I just tried it myself and I get a value of 136 for 1 semitone which is wrong. (It should be 137.) So a bug in the Kria code I think.

UPDATE 2: just add 1 to the KR.CV value before you divide it and it should work how you want: D / + KR.CV 4 1 N 1

#1259

D + / KR.CV 4 N 1 1
…does not work, because, then I lose the lowest note in my pattern. The 0 value will also be N 1.
…I will try the beta tomorrow.

#1260

See my update above. Add the one to the CV value before the divide and you should be good to go :slight_smile:

(The VN op in the beta won’t help you here, you’ll still need to “correct” the KR cv by one first I think.)

#1261

D / + KR.CV 4 1 N 1
…this works for the lowest note, and the one above, but returns wrong values above the second semitone… I have to stop for today, it is pretty late here… Thanks for your great support… I am back on this tomorrow…

#1262

This is a strange issue because Kria and Teletype use the same note pattern code from libavr…

EDIT: From libavr first 12tet values for 14-bit DAC are 0, 137, 273, 410, 546, 683, 819, 956, 1092, 1229, 1365...

#1263

…or is it a calibration issue. I have never used it, but I think there is a possibility to fine-tune the Kria-Scaling…

the values I get are: 0, 136, 272, 408, 544, 680 and all of a sudden 820, 956, 1092,1228, 1364…

How does Ansible calculate note values for I2C?
#1265

EDIT: I’m going to start a new thread for this question because it could clog up this one with technical biz.

1 Like
#1266

From my understanding there are four “patterns” to work with. However is there a limit to the number of variables and size of variables one can assign? As an example, I may have all four patterns in use but want to generate some variation on them - can I store this variation in an array of some kind? or are the four pattern “arrays” all one has?

#1267

You can use the pattern buffers as an array-- though it could take some co-ordinate mapping depending on how you want to use it.

I put together a system for storing 18 short arpeggiator patterns in the pattern buffer, with a routine connected to the param knob that’ll select which pattern, whereby it copies the one from the “storage” portion I set aside in the buffers into a “working” section where the main script would cycle through the pattern. You’re limited to the 256 16-bit values, but you can use them however you want.

One thing that would make this sort of thing a bit easier though is if we could address the pattern array as a single linear array, 0-255 cells, in addition to the existing way, using another opcode or something. For me, I needed a 10x18 array so I had to “unmap” my 10x18 coordinates, and re-map them to 4x64 which could have been simpler with an array that didn’t assume how you might want to structure it…

But, I was able to get it going that way, so it can be made to work.

1 Like
Teletype 3.2+ feature requests and discussions
#1268

RE: address patterns as 0-255:

Say we have the address 0-255 stored in A, this will retrieve the value on location A:

PN / A 64 % A 64

And this will store 7 in location A:

PN / A 64 % A 64 7

But I guess you already figured that out :slight_smile:

EDIT: It’s not my itch, but if you’re ready to roll up your sleeves, this should be fairly easy to add as a new OP, could be useful to others. PX seems available, so the above could be:

PX A
PX A 7

The OP should IMO handle addresses outside the 0-255 range (including negative numbers) elegantly by wrapping them into 0-255, so the following should yield identical results:

PX 0
PX 256
PX -256

Or you could step it up a notch and have it accept user defined wrapping points:

PX.WRAP X (turn wrapping on/off default to on)
PX.MIN (lower bound, default to 0)
PX.MAX (upper bound, default to 255)

So to work with only locations 10-19 in pattern 1 () you could do

PX.MIN 74; PX.MAX 83
PX 0 (same as PN 1 10)
PX 1 (same as PN 1 11)
PX 10 (same as PN 1 10)

NB: Hope I got the wrapping right, but you get the idea…

I guess further discussion related to such new OP should go in Teletype 3.2+ feature requests and discussions

2 Likes
#1269

Yeah, I’ll post a link to this there. Having something like your PX would save quite a few characters in my case, and quite possibly obviate the need to even use the A variable to hold the coordinate (because I can likely get away with not having to use the index value more than once). Example: to store a value in a “virtual” two-dimensional array of arbitrary dimensions would reduce to something like this:

PX + X * 12 Y Z

Where Z is the value being stored, and X and Y are the indices of an arbitrary Nx12 “virtual” array.

#1271

Can a delay trigger multiple things to happen? For example, a delay causes both a trigger to fire and a CV output to advance through a pattern of values. Would the delay have to simply call a separate script to make this happen?

#1272

I think (but I’m not sure) that DEL operator will only delay code from the same line (post section). But you can have two commands on the post section. So I think it is possible a line like this:

DEL 300: TR.P 1; CV 1 N 7

2 Likes
#1273

I’m wondering if anybody has a tip for a simplified clock divider.
At the moment my approach is the following (with X being the clock division):

T WRAP + T 1 0 X
IF EZ T: TR.P 1

I would love to use EVERY but it doesn’t seem work for my purposes as I need the trigger to fire on the zero as in the case of the counter above. Or am I looking at this the wrong way?

> teletype : code exchange
#1274

Hello.
I would like limit the param knob range for controlling some parameters in Disting Ex.
(I control Disting with i2C from the Metro script for continuous value)

So I write
LIM PARAM V 0 V 2
In live mode but the Param is still to the same value.
Am I wrong with the command ?

#1275

I would use this operator:

PARAM.SCALE min max set the min/max scale of the Parameter Knob

2 Likes
#1276

@SMesquida thanks perfect :ok_hand: that’s pretty easy and precise with this.
:blush::raised_hands:

1 Like
#1277

I’d do

IF ! % T X: TR.P 1
T + T 1

I always maintain T (second line) as global time keeper in M after calling the “regular” scripts. This way all scripts share a common, clean clock and are free to handle time individually. If you want to start from zero automatically, the following resets T to 0 if not called within the last second (1000ms):

IF > LAST $ 1000: T 0
7 Likes
#1278

Such an elegant solution! Thank you for the tip!

1 Like
#1279

Super newb quick question here, as I’m busy with the TT studies these days:

Why if I set up TR.TIME x y within I SCRIPT doesn’t change the actual pulse width of an out in any case?
I’m able to achieve this command only in Live Mode.

Where I’m wrong?