#1176

Thanks so much for the && suggestion, this is just what I was looking for!

1 Like
#1177

ProTip: You can use * (multiply) instead of && if you need to shave that one char of…

1 Like
#1178

Just picked up a Teletype (that is, it’s on its way). I’ve got several ideas for this thing. A couple of them raised questions about what can be done with it…

I see that there’s an internal “time” counter. I presume this is asynchronous from the scripts execution? (that is, it keeps counting even when a script isn’t running, so you could, for example, use it to time how long in ms occurs between triggers?

Also, are scripts multitasked? That is, if two input triggers fire off two separate scripts “in parallel”, are they timesliced so that they’re semi-simultaneous? Or does one get first dibs and then the second one is held off until the first one completes?

And similar-- can a script run in an endless loop without blocking other scripts?

#1179

The short answer to all of your questions is, “yes, this is possible*”.

The execution of scripts is single-threaded but very fast. So if you fire “simultaneous” external triggers into two different scripts you might create a race condition where one completes before the other–or vice versa–unpredictably. This can be coded around by having one script call another (using SCRIPT X OP), or altering behavior based on order of operations (e.g. using variables as flags), or altering behavior based on current hardware input state (using the STATE X OP). There is also a stack which can hold 8 commands. Many options exist for achieving your desired flow!

There are no blocking calls but it is possible to slow the Teletype to a crawl using very fast metro rates and/or long loops. Endless loops are best avoided or attached to clocked events like the metro script.

The relevant operations are TIME, which returns the current system time in milliseconds (resets every 32 seconds), and LAST X, which returns the elapsed duration in milliseconds since script X was run. So it’s either way you’d want!

#1180

Thought of another one-- are variables shared across all the script instances? Or does each instance have its own copy of the variables? Or some combination? (some are shared some aren’t)?

And I guess, related to that do variables persist across successive invocations of a script?

#1181

All variables are shared except I, J, and K. I is unique because it is incremented during loops and because a calling script passes its I value to the called script. J and K are unique per script.

The value of every variable is initialized to default when the device is powered up. This can be overridden by declaring values in your init script in each scene.

1 Like
#1182

Ok, good. So I’m kind of presuming that you can attach the same script to two different trigger inputs. Assuming that is the case, can each invocation of the script tell which input triggered it, and vary its action based on that? Or would you have to create two separate scripts?

#1183

Each trigger has a specifically assigned script, but you could call one script from another.

#1184

Ok, so what I could do is have a “common” script X, and have scripts A and B each invoke it-- with a parameter? (so that it knows which script called it?) Though worst case I guess it could leave a breadcrumb in one of the variables…

#1185

Yes, exactly – for instance, this would give you two parallel sequences/sequencers, one clocked by trigger input 1 with note data in pattern 0, with trigger probability controlled by TXi parameter 1 and output going to CV output 1 and trigger output 1, and the other clocked by trigger input 2, using pattern 1, using TXi param 2 for trigger probability, and with output going to CV 2 and TR 2:

script 1:

I 1; $ 3

script 2:

I 2; $ 3

script 3:

CV I N PN.NEXT - I 1
PROB TI.PRM I: TR.P I

– here scripts 1 and 2 simply call script 3 as if it was a function or subroutine, with I as an argument.

Note that if you send a trigger signal to input 3, that will run script 3 with an I value of 0, which in this case won’t do much (CV 0 N ... or TR.P 0 won’t do anything because those aren’t real CV or trigger outputs).

2 Likes
#1186

Cool. Looking forward to playing with this thing, have got a few ideas and I’m sure I’ll be thinking of more-- it’s giving me a lot of food for thought…

#1187

Thinking about the Teletype further, and reading a few things on it I’m wondering to what extent the Teletype can deal with data. I’m thinking in particular, a Markov note model.

Markov modelling is a method whereby the probability of a next event is based on the state of the current event. Applied to musical sequences, there are two aspects.

The first is training a model. On something like the Teletype, that could consist on using a trigger and the CV in to run a script that would adjust the current in-memory model, updating the probability information given the previous note and the new note.

The second is producing a sequence derived from such a model. Here, on Teletype, a trigger could produce an output trigger and CV value randomly but based on the model.

The question then is, to do such a thing, is there sufficient data storage available to a script to store a model?

It its simplest form, the model could be built on reducing the notes to a single octave, which would reduce the necessary amount of data storage. It’d be nice to have a multi-octave model, but a single octave model would at least make such a thing possible.

The data required to do this for a single octave, could probably be done in an array of integers, 16 bit integers probably enough in a pinch. And it would require an array of such integers of length 144-- for each note in a 12 note scale, you would have 12 probability values for what the next note might be, 12 x 12 = 144 integers.

Can the Teletype accommodate that kind of data storage? And if so, is there some way to write and read the data from some kind of removable media?

An enhancement to such a model could be to maintain the probability of the length of the note, which could be derived from the time between notes.

#1188

If I’m understanding correctly, this has already been implemented as the CHAOS operators, the outputs of which may be subjected to all manner of arithmetic in order to tame them into something musical. Search around the forum for details on those.

As far as creating your own rule using 144 integers: the tracker holds 256, although it’s 4 wide not 12. However, I’m sure you can map it to be moved through as though it were 12x12. Not sure about loading from external media but probably? I recall the number of rules being 1) logically arrayed and 2) vast, so am not totally sure you’d even still want to make your own knowing that CHAOS ops already exist.

#1189

Well, it doesn’t look to me that the CHAOS operator works with a user-supplied weighting array so I’m not seeing how that’s of any help…

And with regards to the “Tracker”, do you mean a pattern? I’m not seeing much in the way of references to what the tracker is and how it works.

1 Like
#1190

I don’t know why it’s referred to as a tracker, it’s just 4 arrays of 64 integers with some associated handiness for looping, popping, etc.

#1191

Check out study 5, and I think calling it a tracker is confusing as well.

#1192

Yeah, I’m finding the documentation is kind of spotty and inconsistent. Looks like there may be some old info floating around as well. I’ve been trying to figure out how the JI operator works, looks like it’s the closest thing to a 12-tone quantizer but it’s not at all clear why there are two inputs. And I’ve seen references to “WW” but haven’t found a definition as to what it is.

#1193

WW is referring to white whale, I believe, a discontinued module, and I would think you would be using QUANT to generate a 12 tone quantizer, right? Im new to TT myself…

#1194

I’m so new to TT, mine’s still in the mail. Hadn’t seen a QUANT op, the docs I’ve looked at so far didn’t mention it that I’ve seen…

#1195

Edit: Study 7 discusses quantization a bit, I think. Seems the TELEX extensions do it too.