Teletype 3.+ feature requests and discussion

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

1 Like

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.

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.

1 Like

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

2 Likes

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.)

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

4 Likes

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.

1 Like

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!

5 Likes

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.

2 Likes

Over @ teletype: grid # code exchange (Teletype 3.+ feature requests and discussion) scanner_darkly - 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 I raised the possibility of - Just wondered whether there could be an option on this - either at firmware load or specialised word? ie set the thing and TT boots w/o a script.

still learning the hardware side of teletype, but I think if you changed these lines in main.c to something like:

set_mode(M_PRESET_R);

it would be possible maybe?. this was just taking a quick look, so there’s probably some other steps I’m missing.

for SEED op syntax, would TOSS.SD be acceptable to save a few characters? I’m thinking:

SEED
DRUNK.SD
TOSS.SD
PROB.SD
RAND.SD or R.SD
P.RND.SD or P.SD

thoughts?

3 Likes

seems very reasonable to me - from a non expert on there matters :blush:

For completeness, how about SD and SEED versions of every seed op?

2 Likes

oh duh I forgot about aliases. thanks!

1 Like

excuse me, but is it possible to try the SEED-enabled fw yet? thanks!

still working on testing for the official pull request but I can send you the same build I sent @rikrak. it only has a single seed op instead of separate ones for each op using a random still works though!

that would be great, thanks!

Just had an idea for an op and wanted to get some thoughts and feedback

P.DIR Y / PN.DIR X Y

Controls directionality of P.NEXT / PN.NEXT

If Y is 1, NEXT moves forward (this is the default and the current behavior)
If Y is 0, NEXT moves to a random place within the current length of the pattern
If Y is -1, NEXT moves backward

You can already code up a pitch sequencer in a line (CV 1 N PN.NEXT 0), would be awesome to just have to set this one thing to change the direction of that pattern

As another idea, you could allow for any integers, not just 0 and 1, and that could set the amount of NEXT. In other words, PN.DIR 0 3 would make NEXT of pattern 0 move forward 3 indices each time it is called.

4 Likes

I can see how this would simplify a script, but also think it could be confusing since we currently have P.PREV to decrement the index and P.RND to get a random value between start/end. The semantics of the word NEXT would be more ambiguous.

Maybe something like this needs it’s own new word? Also, something that I personally haven’t explored a whole lot are the Turtle ops which have some interesting directional options.

You could code this up currently by having a variable to set and 3 if statements, one each for NEXT, PREV, and RND?

2 Likes