Totally agree 1 based indexing makes more sense musically. It’s a breaking change w.r.t. old scripts though, so I think we’d need to be quite sure about it.
degree = 0 is also totally weird, I agree. Maybe 0 should just be a dead-zone, and return the same as degree = 1?
I just installed the latest firmware from github, and something is either wrong or has changed with LAST. Here’s my dead simple scene (NB: changing $ to 1 gives same result):
#1
A LAST $
Triggering script 1 (either from trigger jack or by pressing F1), A just counts up, seems like it counts time from last time I was run (pressing F10 to run init confirms this since A starts counting from 0 again).
I suppose something went wrong with the new feature mentioned in the manual:
FIX: LAST SCRIPT in live mode gives time since init script was runJust reviewed that change and I don’t think it could be causing your issue.
My studio is torn apart right now for renovation so maybe someone else can try to replicate the problem. I’m behind a couple firmware revisions but I was definitely using M LAST 8 in script 8 for tap tempo a couple weeks ago…
Ack, dead zones bug me even more. If you’re modulating these discrete musical parameters using a continuous CV it’s desirable to have a smooth response rather than a lag around 0. How about we go to 1-indexed degrees and just let 0 feel weird? It’s probably an edge case, anyway, because most theory-inclined coders will limit their scale degrees to I thru VII.
Thanks! It would be awesome if someone else could look into it, it’s definitely not working correctly here…
NB: If it matters I pulled the latest (no tags) with:
git clone --recursive --config core.autocrlf=input https://github.com/monome/teletypeThat’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.
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):
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:
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!
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
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.
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
Thanks for the confirmation! Maybe I’m seeing things but at least I’m not alone 
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.
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!
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 
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).