Teletype 3.+ feature requests and discussion

[alphacactus]

edit:
@Starthief beat me to it. definitely need to update the docs so that this is more clear(I’ve made the mistake myself once or twice).

[apeirophobe]

ah crap … I always mess that up! In any case, my original scene (which uses the correct syntax for DEL.R) is still not working but I can confirm that the (corrected) scene I posted above does so I need to do more debugging. I should clean up my scene and post it here. I really appreciate the help people.

[100microdots]

I really enjoyed some of the scripts I made on some the 3.0 betas but had to set them aside until recently. Looking at what I made and what I’m working on now, here are a few updates that make my life a little easier.

I’m primarily using the Teletype to sequence three or four voices. In the near future I’m hoping to get a few Telexo and/or Ansible and think the updates below would be even more valuable with the expanded outputs.

• More patterns: I frequently find myself using up most of the pattern space. For the voices it can be a combination of gates/gate patterns, velocity, duration, and pitch. I also tend to store some values related to the scene or song, like bpm and time signature. I would love to have a few more so I can sequence additional aspects of a voice from the Teletype.

• I like the Shadow Scripts proposal, timeline proposals, or anything that would let me make a slightly more complex scene. I don’t want longer scripts, I just occasionally want to be able to do a few more things independently. I’m using scripts 1-4 for voices and frequently use 7 and 8 for song and scene related duties. I’d like to keep those kinds of things relegated to something like a shadow script and have the flexibility of more scripts triggered by the eight inputs.

• I know this can be done if I made a custom build (someday…) but with all the places I used PN.HERE and PN.NEXT, it would be nice if they had a shorter alias. Replacing the N with the pattern number, i.e. P4.NEXT, would keep it readable and still save two character but trimming it to P4.N still makes sense when I look at it.

That’s really it for my wish list at the moment. All the stuff added to 3.0 is still keeping me busy, thanks to everyone who worked on it.

[jimi23]

Crossposting into here for visibility, Ive been working on MIDI output for Teletype. It requires a bit of hardware sitting on the back of the Teletype, but will be pretty inexpensive. The MIDI ops will support saving and loading of ‘select bus’ enable modules. I dont have an entire list but from what I know:

Malekko Varigate 4+/8+
Malekko Voltage Block
Malekko Quad LFO/Envelope
Make Noise Tempi
Make Noise Rene Mk2
Disting Mk4
Mungo maybe (?)

Here is a quick test loading some Disting Mk4 presets

[chapelierfou]

Wow, this opens great perspectives !

[sam]

Just catching up with this thread… so sorry that some of the replies are late…

my guess is that indeed the idea is that you would want to keep the current values when you switch scenes with SCENE op

I believe that is correct, I think the use case would be for breaking a ‘song’ up into multiple scenes, but still allowing some communication between scenes by setting variables.

this sounds like a bug to me (although perhaps there are some specific reasons for why SCENE shouldn’t work from the init script).

SCENE is banned from the init script because you can lockup your Teletype requiring a firmware flash to fix!

e.g. if the init script of scene 1 calls SCENE 2 and the init script of scene 2 calls SCENE 1, then you Teletype will bork. Worse… when you reboot the system it will probably try to re-run the last saved scene… and the only way around it is a firmware flash.

so, saving the last mode to flash definitely has an effect. the question is - is it significant to be fixed? personally i don’t think anybody expects teletype to be super precise with timing, but if it does affect its use in a musical context then improving it should definitely be considered, especially if there is an easy fix for it. saving the last mode seems like a nice to have, not a must have. the only practical application for it i can think of is where you use teletype with one scene and don’t even plug keyboard or grid into it, and you want to see a specific screen. but that’s such an edge use case. with keyboard/grid it’s very easy to switch to the screen you want, and it does not affect teletype operation otherwise when you boot it up.

IIRC I discussed getting rid of the mode saving and there was some pushback, but for the life of me I can’t remember why… it might have been something to do with some users only using a keypad. Personally I think it should go…

[desolationjones]

IIRC I discussed getting rid of the mode saving and there was some pushback, but for the life of me I can’t remember why… it might have been something to do with some users only using a keypad. Personally I think it should go…

I agree, and @EqualTemperament’s above suggestion to only save mode when saving scene should satisfy anyone running without a keyboard.

[rikrak]

I have a feature request for TT.

Would it be possible to add a “SEED” op to expose/set the random seed used internally?

I would like to be able to get the exact same numbers from random elements every time I run a Scene. Sometimes when composing generative, a lovely serendipitous sequence will emerge - it would be great to be able to repeat it and develop it further using other modules whilst knowing that TT will always play it the same way with the same seed.

Is it possible? Am I alone in wanting this? The CHAOS ops do get part of the way there but it would be much quicker and more useful (to me) to have set a SEED which affected all randomness.

[alphacactus]

pretty sure this would be incredibly easy to implement. from what I can tell the RAND and RRAND ops are just calling the stdlib(standard library) function rand(). so we could just add an op that calls the stdlib function srand() to set the seed.

http://www.cplusplus.com/reference/cstdlib/rand/

http://www.cplusplus.com/reference/cstdlib/srand/

[adrianf]

Don’t mean to hijack but the above request had me thinking. Would creating a “Random Number from Normal Distribution” OP be feasible?

RANDNORM x y (x=mean, y=standard deviation)?

[jimi23]

Far out idea. Given the Teletype and Ansible are built on the same hardware, is there space in Teletype to port Ansible apps to run natively? Im imagining all the timing and clocking would still be handled by Teletype ops. Something like an extra page for when a grid or arc is plugged in to Teletype, which allows you to select the behaviour (ie existing Grid Ops, Kria or Meadowphysics)

I dont think its such a huge issue to tie up the TR/CV of Teletype for this purpose now that Teletype can communicate with Txo for extra CV/Gate outputs

Or maybe some Arc ops in the future? I have an Ansible, Teletype and Grid (and an Arc incoming). When the Arc arrives id like to use them all together, but at the moment that means using Arc with Ansible and writing my own Grid ops sequencer with Teletype, or buying a second Ansible.

[rikrak]

pretty sure this would be incredibly easy to implement. from what I can tell the RAND and RRAND ops are just calling the stdlib (standard library) function rand() . so we could just add an op that calls the stdlib function srand() to set the seed.

Great! And it would be possible to both get and set SEED? Or is the seed value too many bits? Just setting the SEED for RAND and RRAND would probably be enough.

Don’t mean to hijack but the above request had me thinking. Would creating a “Random Number from Normal Distribution” OP be feasible?

RANDNORM x y (x=mean, y=standard deviation)?

Interesting! I’m not sure what the implications are for this. What advantages do you see over setting a single SEED value?

[adrianf]

A Random Number from a Normal Distribution would provide a central tendency with adjustable “spread” versus, say, a uniform distribution which i believe RAND provides.

I think this could be useful if you wanted to modulate something and found a sweet spot (mean) and wanted the modulation to vary about this mean by a certain amount (standard deviation).

[zebra]

Would creating a “Random Number from Normal Distribution” OP be feasible?

you’re probably aware of this, but the simplest way to approximate that is to take some number (N) of uniform-distributed random numbers and average them. the higher the N, the better the approximation. of course this also linearly increases the computation time.

the Ziggurat algorithm is on average more efficient than high-N approximation if statistical soundness is needed. but its an iterative algo and my hunch (could be wrong) is that the worst case is just as bad, and that for music application it’s not a great tradeoff.

settable mean and deviation is just an offset and scaling factor. asymmetrical scaling can also be pretty useful for music.

TL/DR: yes. kinda expensive.

---

from what I can tell the RAND and RRAND ops are just calling the stdlib (standard library) function rand() . so we could just add an op that calls the stdlib function srand() to set the seed.

huh, your’re right, surprised it’s not using this even quicker and dirtier LCG from the libavr32 sources:
[ https://github.com/monome/libavr32/blob/master/src/random.c ]

i made this for aleph noise generator and it seemed pretty good. think you wanna be a little careful with seed values if you want this to have long periods (aka “random looking”)

[Starthief]

Gaussian is cool in graphics… for music I expect it’d be better for micro-scale stuff, like granular or for noise as an FM source, than for the “sequencing” time scale Teletype is generally dealing with. But maybe that’s just me.

Hmmm, now I’m thinking about Perlin noise and erosion algorithms as compositional elements

[zebra]

Gotta disagree, different distributions (normal, 1/f, 1/f^2) have extremely different aspects when used as coarse-time parameter sequences (especially pitch.) all tend to feel more “natural” than flat distribution.

[Starthief]

I admit that was just an off-the-cuff guess based on not really trying it

[SimonKirby]

I’ve been using teletype to clock the looping delay mode in Clouds and the pitch warble whenever I interact with the teletype UI is certainly problematic - especially in live use, so if there’s a fix for this it would certainly make me happy!

[jnoble]

Best fix I know of is to get a Telex Output, the timing seems to be very stable.

[scanner_darkly]

i’ve removed saving last mode (which is what caused the metro timing issue) in the latest beta. it was originally posted in Teletype 3.0 thread as that’s where we were discussing the issue with scenes getting overwritten, i’ve updated the OP here as well to avoid confusion. if you have the time want to give it a try?