Teletype 3.2+ feature requests and discussions

That’s true, it’s really weird in the quantization use-case! Alright, I’ll move to 1-indexing with 0 being the VII one octave down. I’ll post a beta and people can see how they get on with it.

1 Like

Apologies if this is the wrong thread or not the right time, but having a way to calibrate TT’s CV outputs for 1v/oct tracking would be an awesome addition to the next TT release. At least on my TT especially the lower end of CV1 is noticeably off (please see this post for details).

I’d like to propose
aligning the playhead positioning behavior between
pattern length changes on the one hand and
pattern start & end changes on the other hand
.

Currently changes made to pattern length (P.L, PN.L) affect the playhead position differently than changes made to pattern start or end (P.START, PN.START, P.END, PN.END):

  • On changing the pattern length, the playhead position is automatically forced to index 0. This ensures that the playhead is always in the index range defined by the pattern length.
  • But on changing the pattern start or end, the playhead position is not changed. So if e.g. the pattern end is set to an index before the current playhead position, the playhead will continue to proceed thru all index values after the end index, until it reaches the end of pattern length.

For me, this has led to confusing situations during “live coding” of pattern start or end values, as I can not rely on the playhead being bound to the range I define by pattern start and end value. Depending on when I commit a change to pattern start or end, the playhead might wander thru an undesireable range of values.

This can not happen with changes to pattern length. The current implementation ensures that playhead is always confined to the index range defined by pattern length. But as a the start of pattern length can not be changed (it is always index 0), I can not “window” thru a range of indizes, but have to use pattern start and end values for this, and have to ensure that both start and end values are inside the pattern length, while making sure that I change start and end values in the correct order and at the correct time in order to prevent the playhead moving thru indices outside the new range defined by start and end.

To make this less error prone (at least for me, admittedly) I propose the following new behavior for changing start and end values:

  • If the new start value made the playhead be outside of the range defined by the new start value and the current end value, the playhead should be set to the new start value.
  • If the new end value made the playhead be outside of the range defined by the current start value and the new end value, the playhead should be set to the current start value.

This change would ensure that the playhead is always confined to the index ranges as defined by pattern length or pattern start&end.

My apologies if this has already been discussed and dismissed, or if this behavior already exists and I did not find it. Thanks for listening!

1 Like

This seems nice, and has certainly been an outstanding Teletype issue for a long time, but I think probably figuring out what the ops / user interface should be is the hard part here. How would you expect the calibration procedure to work for outputs? It’s unfortunately not possible to wind up with CV 1 V 0 giving exactly 0 volts for a given output because the DACs are unipolar, so you would probably have to apply an offset and scaling factor to each other output to get them to match.

The most consistent thing with existing calibration ops would maybe be to have a CV.CAL.MIN for each output which you could set to some value that, from experimenting, causes that output to best agree on the voltage of CV 0 with whichever output is furthest offset. You would also need to determine a CV.CAL.MAX value that would result in all CVs having approximately the same slope with their new offsets applied. This MAX value would probably be greater than 16384 (beyond the actual upper limit of the DAC).

The current code for performing fixed-point rescaling of the values set by e.g. IN.CAL.MAX is here.

That sounds super annoying and I can’t conceive of reason not to try fixing it (except that my CPU is currently dead). I’ll take a look!

Patterns OPs have got my attention lately. I was thinking we should have a way to shuffle through pattern indices, touching each index only once before reshuffling. But then I saw the new pattern shuffle OP and it took some wind out of those sails. Despite being destructive, the new shuffle and mapping OPs are incredible. I could make an easy case for non-destructive “shuffle play” but I just don’t play around with pattern length or start/end enough and those are the cases with the most notable differences.

I was wondering if there is demand for an OP that displays specific screens such as the tracker screen? I use a script where values arriving at the IN jack are copied into the tracker, and it would be great to be able to a see that without having the need for a Grid or keyboard to switch screens

1 Like

To me that sounds a bit dangerous – you could get into a situation where a script keeps hijacking the screen and you can’t stop it or do much of anything.

1 Like

I can confirm that I am also seeing all variables count up when I try , and not update the time

A LAST 1

My build is 58DCD46

1 Like

Thanks for the confirmation! Maybe I’m seeing things but at least I’m not alone :grinning:

I did try with CTRL-F.. but doesn’t this mute scripts rather than the actual trigger outputs? If I have TR.P 1 in one script and also in another, then its not really muted. In other words, the cables I am “pulling out” are the trigger outputs , not inputs, for clarification.

CTRL-F and MUTE apply to incoming triggers. there are no equivalent shortcuts or ops for trigger outputs, but you could use a trick - set trigger pulse length to 0: TR.TIME x 0 where x is the trigger number.

2 Likes

posted new beta:

8 Likes

Thanks!

I can confirm that LAST is working again (building from GitHub)! Just a heads up: building the docs (again from GitHub) is currently failing, but the .hex is fine.

Thanks again!

1 Like

thanks for confirming!

what error are you getting when building the docs? it’s likely from me adding new sections but since i don’t have the toolchain set up for building docs i can’t verify.

Isn’t the build stuff (latex + friends, I guess) included in the docker image, or did I provide those myself ???

Anyways, first stop is here:

Underfull \hbox (badness 10000) in paragraph at lines 1153--1155
[]\TU/RobotoMono-Regular.ttf(0)/bx/n/9 G.FDX id x y w h type level script

Underfull \hbox (badness 10000) in paragraph at lines 1157--1159
[]\TU/RobotoMono-Regular.ttf(0)/bx/n/9 G.GFX group id x y w h type level

Underfull \hbox (badness 10000) in paragraph at lines 1221--1223
[]\TU/RobotoMono-Regular.ttf(0)/bx/n/9 G.GFDR.L group odd_level
[4]
! Extra }, or forgotten $.
<recently read> \egroup 
                        
l.1233 \begin{op}{MI.\$ x / MI.$ x y}
                                     
? 

Next (after pressing enter):

! Extra }, or forgotten $.
<recently read> \egroup 
                        
l.1233 \begin{op}{MI.\$ x / MI.$ x y}
                                     
? 

Next

! Missing $ inserted.
<inserted text> 
                $
l.1235 \end{op}
               
? 

And then it goes on on each press of enter a few more times…

Hope that helps :slight_smile:

2 Likes

thank you! looks like i’ll need to get the toolchain set up, no idea how to fix that (not using the docker image here).

even with the posted warnings, it’s possible that somebody might forget to backup scenes to a USB stick before reflashing the firmware.

i suggest that we update flash.sh and update_firmware.command files so that it creates a backup of the existing firmware/scenes before flashing a new one. it will only take a few extra seconds but this way at least you can restore it and backup the scenes if you forgot to do it. thoughts?

8 Likes

Sounds like a good idea. When reflashing firmware I’m always super careful with my scenes. I’m not sure I’d trust the flash.sh to save me, but an extra level of safety net is a really good idea!

1 Like

That would be great!

Hi, I have had a tough bit of trouble finding direct information on this;

What is the status of potential ghost scripts and how do I access them? I wanted to put my 16n faderbank read on one of them.