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
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!
X WRAP CHAOS 0 36
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
B RSH B 1
IF NZ B: BRK
X - X 12; B 2048
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.