Teletype 3.+ feature requests and discussion

[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?

[jnoble]

Metro is +/- a few milliseconds best case, isn’t it?

That much jitter will definitely cause audible issues with a clocked delay and some other things.

[scanner_darkly]

yeah, it’s not rock solid (detailed measurements in this post) but removing saving last mode to flash should provide some noticeable improvement.

[jnoble]

Yeah, I recall reading that: +/- 1ms will probably be somewhat audible if you got consecutive timings at the limits.

Is there still an issue with scrolling in the tracker screen interfering with metro stability? I always use a TXo for clocking, so I haven’t paid attention in quite a while.

[scanner_darkly]

any scrolling will probably have an effect but hard to say how big. there are also many other variables (i2c / grid if you’re using grid, delays) that might also contribute, so scrolling might not actually be the most contributing factor.

[adrianf]

I’m treading off topic at this point but here’s an another example of recent popular module using a similar distribution musically.

https://mutable-instruments.net/modules/marbles/images/distributions.jpg

[Starthief]

Heh, I never really think about Spread/Bias in Marbles, I just roll with whatever comes out. (Also if I remember right, the manual included with beta test modules was a little less clear on a few points than what was published on the website, and that might have been one of them.)

(I think generally I have them both near 12 o’clock most of the time, though.)

[alphacactus]

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 ]

so I made a dirty build with a SEED op using srand() last night for @rikrak. seems to work as you might expect.

digging deeper into the code I found the following ops all currently use rand(), and thus are all effected by setting the seed with srand(). so I’m kind of curious what thoughts there are on whether a single SEED should control them all. we could give each a random_state_t as linked by @zebra, and have variations of the SEED op i.e. SEED.TOSS.

TOSS
RAND
RRAND
PROB
P.RND
DRUNK

as a side note I’m not what concerns there are(if any) with increasing the size of the scene_state_t

[scanner_darkly]

if we do separate seeds i think TOSS.SEED etc might follow the naming conventions better (grouping by the main op, like P.NEXT etc).

adding random_state_t to scene state is not a concern (even if we do separate ones for each random op), it’s only 6 bytes.

[rikrak]

If there are separate Seeds, it would be great if there was a way to have a command that would affect all randomness - as it does with the build you very kindly sent me.

I’m using Seed to populate a TT pattern with 64 values which are then sent out across the rack to control other modules. Seed sets loop lengths, envelope shapes, pitches, filter cutoffs, reverb levels, etc etc.

Everytime the Seed is set, the entire patch changes - and to recall those settings, you only need to have made a note of the single Seed value. By exploring random Seed values and then making a note of those that work best together, you can then use another pattern with those ‘curated’ seed values, to rotate through saved states of the entire patch. It’s a really fast and powerful way of working with generative compositions. I love it!

[alphacactus]

wow that’s really a really great use case of SEED! ya I think a base SEED op could have that functionality, and then the OP.SEED ops would give you granular control.