Would anyone be interested in the turtle being able to optionally interpolate between cells?

(Needed to write this down before I forgot)

I guess the same result can be achieved by using CV.SLEW at the end of the signal chain.

I don’t agree for several reasons.

First, I don’t want to use “other tools”, I’d like to keep everything inside my Eurorack system in general and in TT in specific.

Second, if we get a predictable quantizer, those who like unpredictability can add it via DRUNK, RAND, RRAND or TOSS. But it doesn’t work the other way round, i.e. you can’t turn an unpredicatable quantizer into a predictable one.

2 Likes

Assuming that you use the pattern grid for CV data, yes. It can be used for more than that, though.

@wolfgangschaltung, your TELEX expanders can handle some of the quantizing duties for you. They are designed to convert voltage to/from note numbers based on a number of different configurable scales (equal temperament is the default). Many are 12 note scales, but some divide the octave into more/less steps as well. Think of the functionality as auto-tune for your Teletype.

The tuning algorithms use fully rendered tuning tables that are compiled into the firmware. It’s pretty easy to add your own, if you want. I included a bunch of standard and fun ones if you want to exploit micro tunings. They are built out of SCALA files; there is a little utility in my GitHub that helps create your own default set of scales if you are interested. The expanders use these tables to find the nearest pitch and employ a bit of hysteresis to keep things from flopping around too much.

Also, the TXo supports greater resolution than the TT for its output as it has 16bit DACs. When you pass it a note number, instead of a 0-16383 value, it can use the full precision of its DAC to send out the corresponding voltage (or oscillation frequency). This is good if you are experimenting with micro tunings and want things to be more “in tune” with your selected scale.

Now, the expander’s quantization functions are not designed to help you manipulate pitch sets (the issue that @sam was referring to above). The design choice here was to leave that to your TT patch where you have the full language to experiment with.


Here is a patch example that translates equal temperament voltages from TXi IN 1 and outputs them as voltages using Werckmeister Temperament II on TO CV 1. It uses the experimental M! command to pulse the metronome script every 2ms. Use at your own risk. :wink:

I
TI.IN.SCALE 1 0
TO.CV.SCALE 1 3
M! 2

M
TO.CV.N.SET 1 TI.IN.N 1

Instead of passing voltages, TI.IN.N returns a note number. This can then be manipulated or, in this example, passed directly to the corresponding function on the output (TO.CV.N).

There are some more quantization-related functions as well in both devices. For instance, you can also quantize voltages using the TO.CV.QT x y syntax. They are all outlined in the documentation.

Does the above make sense?

6 Likes

Thanks very much for the explanation!

Regarding the unpredictability of quantizers: I wonder (and have not tried it yet!) how the quantizing algorithms react to voltages that are jittery and sometimes touch the “in-between land” 2 quantization steps. Is there some kind of hysteresis used to avoid the resulting notes being as jittery as the input signal?

Yes there is.

It is a pretty simple algorithm that just extends the bounds of a quantization target after it is selected. Also, the TXi has software low pass filters to reduce the jitter on read as well. The unit uses the Teensy’s ADCs, which have 13 bits of usable resolution, for both the PARAM and IN.

1 Like

it would be great if we had a shorthand increment/decrement alias like ++
something like PN X Y + PN X Y 1 I think is really long for what it does.

2 Likes

That would be difficult to implement. I’ll explore what would be required, but I think it would involve leaving a pointer on the command stack in addition to the value, and as such would be quite a change. Additionally, these pointers would only be used by increment and decrement, so don’t provide much value.

this would be nice, yes, but it’s really outside the language as it is now. i’d like to avoid any outlandish operators like this.

rather, if we wanted to add some sort of operator like PN.ADD that’d be fine.

ie

PN.ADD X Y 1

is increment. but you can change 1 to -1, or 2, or whatever.

2 Likes

PN.ADD would be useful as pattern slots can easily be used for storing variables.
I was thinking more in a general context as incrementing values required extra lines in my scripts because of their length, but yes ++ does seem a bit off in the tt syntax.

I’m pretty new to teletype, so excuse me if I’m incorrect. But I think what you’re suggesting is already implemented in the form of the O operator

1 Like

I guess you could:

O PN X Y; PN X Y O

But that’s no more succinct, and it robs the O of carrying other meaning in the script.

tehn, any chance to have thoses in the next update ? it would be great ! thanks :slight_smile:

i spoke about this :

with white whale, i would love to have a read position script, there’s actually only “cue to postion” (WW.POS) . with that, you will be able to synchronise trackers positions with white whale positions, So more CV OUT to white whale, it’s just an exemple…

and with ansible, i would love to be able to change the Edit position of LEVEL, like when you push buton 1 on the module.

these are both reasonable requests, i’ll get them on the list

16 posts were split to a new topic: Teletype (feature) EVERY+SKIP+OTHER+SYNC

Filtering out these two observations from the EVERY thread:

:+1:

I’m also open to these ideas.

1 Like

doesn’t IF see anything non-zero as true? so there’s no need for EZ in there.

EQ Z MOD X Y

logically is the same as

MOD X Y

right?

edit: checked, yes, non-zero is true for IF

edit again: gah, i was thinking EZ not EQ Z

you mean EQ? it’s not equivalent though. consider the following script:

IF MOD T 3: TR.P 1
IF EQ 2 MOD T 3: TR.P 2
T WRAP + T 1 1 4

triggers will output the following:

T:   12341234
TR1: 11011101
TR2: 01000100

apologies, i read the intention as checking against zero— i totally missed the point.

i get what you’re saying now and it makes sense.

1 Like

Not sure if this thread is dead or if we need a separate thread to discuss potential future operators 2.2, 2.3 and beyond… BUT…

I think a ratchet operator would be extremely useful. I’ve put ratcheting into a few teletype scenes, but in the latest one I was working on, I found the constraints of the DEL pre insurmountable for what I was trying to do.

TR.RATCHET (TR.RAT or TR.R?) with arguments for how many ratchets and delay between ratchets would be a really simple and powerful syntax for triggering ratchets on the trigger outputs.

This is the R feature, which is planned for sometime before 3.0.