#149

:bowing_man: My beta above is lagging the official beta by a few commits, so no way currently to use the B and X nomenclature with my OPs yet! My goal this weekend is to rebase the code.

#150

Thanks for testing! The G is for geometric, as the op is producing a geometric sequence of delay times. I had some vague idea to make a corresponding arithmetic sequence version called ‘DEL.A’ which would add or subtract a value for each repetition, but I couldn’t think of any use cases.

#152

Yeah, not sure, nothing strikes me right away but sometimes it takes me a while to come up with ideas for various ops. One thing that crossed my mind with DEL.G (or any of the DEL family of ops) is that they could be pretty interesting with the S.POP op, though I haven’t experimented yet.

That was my understanding. Was just going to load your latest hex and convert outside the box but if you beat me to it with re-basing, even better!

A thought on the immediacy of the X and B representations of numbers. I understand why they work the way they do. Would it be possible to have some keyboard shortcuts, for example ALT+D, X, and B if not already in use, that would function in live and script edit mode?

If your cursor is over a number and you execute the shortcut it could convert the number to the requested representation? Then a commit/enter would still transform it to decimal for storage in the script/pattern/variable. I think that could be really useful for editing purposes.

1 Like
#153

I was looking at the P.NEXT implementation this morning and it got me thinking that it might be useful to set the step size for each pattern instead of always incrementing/decrementing by 1.

I took a stab at implementing get/set P.STEP and PN.STEP ops this morning and it mostly works, although there are some bugs I need to iron out with the wrapping logic for start, end and length.

One bit of weirdness is how it interacts with P.PREV. The step can be positive or negative, and P.NEXT adds the step to the current index, whereas P.PREV subtracts. It feels like there’s some overlap between P.STEP, P.PREV and maybe even P.REV because you reverse a pattern by doing P.STEP -1, switching from P.NEXT to P.PREV or calling P.REV on the pattern.

1 Like
#154

the reason it does that is because the live screen history stores parsed scripts, not the actual text (another side effect of this is - if you provide invalid input, it will not be stored in history).

this unfortunately also extends to editing scripts - it will convert when you enter a line (same if you edit a script and upload it via a usb stick). the fix for this would be to also preserve the number format in addition to its value. doable but quite significant and risky change.

this would also not solve the case of the live screen always displaying results in decimal format. one option would be to try and determine the format based on what numbers were used in a calculation but it gets more complicated if you do something like + XFF B0101. the proper way would be to be able to choose the format you want, and it could apply to both the output and variable display.

this is also a bit complicated - what if you are trying to convert a decimal number to binary and there is not enough space in the line? and this is somewhat covered by the existing functionality, since you can enter a binary/hex, hit enter, then use the history to add the rest of your line.

2 Likes
#155

Linking @csboling’s thoughts here for discussion. The proposal is the MUTE x would mute both external triggers and $ OPs, while $.POL 0 would simply mute external triggers. I like it because $.POL is already exclusively used to define script behavior in reaction to external triggers.

EDIT: Oh! Reading through the code suggests $.POL 0 already works as a trigger mute.

2 Likes
#156

I was experimenting with a local change to N.S, N.C and N.CS where instead of just wrapping back to to zero, the d argument will add will add or subtract octave offsets appropriately. Is anyone else interested in this, or are people attached to the previous behaviour?

1 Like
#157

I can’t seem to find the place in the source that handles “SCENE RECALL” (pushing button, turning knob, pressing button to load scene without keyboard attached), can anyone help me in the right direction?

#158

I think d works great as an octave offset and makes a lot of sense. In fact, that behavior is present in the QT.CS beta where the octave offsets are applied to the output. It’s a bit unique, perhaps, to have your quantizer also offset the result, but I figure it’s a nice treat for people who are playing with out-of-range degree values. The alternative is to cap or wrap the values, I guess, and lose the octave switch functionality.

Anyway, the behavior makes even more sense as part of the N.x OPs.

The other potential change would be 1-indexing degree. I’m still uncertain about this one, mostly because if degree is indexed from 1 then degree = 0 feels more like degree = -1.

1 Like
#159

You’re probably looking at preset_r_mode.c already.
The handler_Front function in main.c gets you into M_PRESET_R mode.

1 Like
#160

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?

1 Like
#161

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 run
#162

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

#163

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/teletype
#164

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
#165

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

#166

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
#167

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.

#168

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.

#169

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