[Bounty complete!] Teletype Circular Shift OPs

[EDIT: Bounty complete!]

I’m relying on @SimonKirby’s excellent Teletype quantizer haiku for an upcoming show, but it hangs up on scales which disclude the root note (see link for detail). This would be solved [EDIT: lol, it wouldn’t] with the addition of Circular Shift (aka bit rotation) OPs.

A working .hex which adds the following OPs to the most recent Teletype firmware:

  • Circular Shift Right
  • Circular Shift Left

OPs should accept the same arguments as the existing bitshift OPs.
OPs should have aliases of <=3 characters (perhaps CSR and CSL, or >>> and <<<).
Firmware changes should be open source and suitable to be merged with main Teletype branch.

I will pay $60 via PayPal for a solution delivered by December 1st. $30 anytime thereafter. This could optionally be paid to a charity of your choice or be split between you and any collaborating developers. Other users should feel free to chip in towards increasing the pool.

For stankin’ up the place with capitalism. The concept of bounties has been floated before but I haven’t seen one happen. If this proves a “not okay” thing then I’ll remove it. If we’re going to get into a deeper discussion of its “okay-ness” then let’s start a separate thread on the matter :slight_smile:

To @csboling for the excellent implementation with bonus features of negative shifts in all bit-shifting OPs!


After some research, I should add that I have no idea how the interpretation of signed integers happens on TT, or how bitwise operations interact with negative vs positive integers. It seems like the interpretation of a bit rotated signed integer may vary between ones complement and twos complement systems. I don’t know if anyone cares how TT will interpret the result because I think mostly people are using these bitwise tricks for storing patterns in numbers rather than doing math to numbers. But if there is a meaningful distinction then we should discuss!

Rotating bit ops would be great, but wouldn’t be a perfect solution to the haiku puzzle. A note near the bottom of an octave (lower than the lowest note in the quantiser pattern) would end up jumping up an octave from where you’d expect it. Really you only need a few more lines to get the behaviour you want from existing ops I think. Basically, a check for hitting zero and then subtracting 12 from X and setting J to 2048. It would need to be done with a separate script because otherwise the line would be too long, I think. Might be a challenge to make it a haiku!

This works…

B BSET 0 % X 12; K 0
W EZ & B A: $ 8
L 0 11: K ? BGET B I I K
X + * / X 12 12 K; CV 1 N X

X - X 12; B 2048

Ah yeah you’re right. I forgot how your octave math worked.

WELL bit rotation would still be hella sweet so the bounty stands!

twos complement, 16-bit: sign bit is 0x8000, (x * -1) == (x ^ 0xffff) + 1

how bitwise operations interact with negative vs positive integers

arithmetic: sign bit is unchanged, zero-padded if positive, 1-padded if negative.

1 Like

here’s a small program, i think the function bitrot16 does what you want.

1 Like

I really like allowing negative numbers to mean shifting the opposite direction. For Teletype’s existing LSH and RSH ops this is not currently the case: the implementation of LSH is just x << n with signed operands. This is technically undefined behavior when n is negative and therefore dependent on the compiler/architecture†, but it appears that Teletype always returns 0 for this. I’m curious to know how people who use these ops would feel about changing LSH 4 -1 to be equivalent to RSH 4 1? This seems like an interesting technique to me, but it would be a change to existing behavior. The alternative I suppose is to have an additional SH op which accepts negative shift amounts, but this is an extra op and I like the symmetry of the other approach.

Another detail to consider: I generally expect a circular shift operation to always preserve the number of set bits, so I expect a shift by n > 16 to be equivalent to a shift by n % 16.

† Interestingly it sounds like the Pentium SAL instruction truncates the shift amount to 5 bits so that x << -5 would be executed as x << 27.


I’m totally cool with adding the negative directions. That would make it really easy to phase a pattern with a single knob.

On the question of “circular shift preserves number of bits” my brain breaks down when trying to account for the sign bit. It’s been a long day :sweat_smile:

PR: https://github.com/monome/teletype/pull/189
build: teletype.hex (586.8 KB - b282c93 - 2019/11/15)

LROT x y   # left-circular-shift x by y places
<<< x y    # alias for LROT
RROT x y   # right-circular-shift x by y places
>>> x y    # alias for RROT

bonus op:

SGN x   # sign of x (1, -1, or 0)

I’ve also been wanting this for a while, so I think with the bounty you should treat a friend to dinner, or donate to a charity of your choice, as my thanks for you giving me something fun to do.

Here are some examples:

teletype      bits before         bits after          result
RROT 1 1      0000000000000001    1000000000000000    -32768  (most negative value)
RROT 1 2      0000000000000001    0100000000000000     16384
RROT 1 3      0000000000000001    0010000000000000      8192  (acts the same as RSH until we wrap around again)

RROT -1 1     1111111111111111    1111111111111111        -1  (same as RSH because shifting negative numbers sign-extends)
RROT -2 1     1111111111111110    0111111111111111     32767  (most positive value)
RROT -2 2     1111111111111110    1011111111111111    -16385 
RROT -2 3     1111111111111110    1101111111111111     -8193

The leftmost bit is set if the number is negative, but in 2’s complement arithmetic we need to invert the other bits and add 1 to get the magnitude.


Thank you, Sam. I’ve donated the funds today in support of a friend’s tattoo apprenticeship.

The Teletype user + dev community has been incredible these last few years; now with today’s announcement it looks like the hardware hackers can get in on the fun, too!

1 Like