do you mean shadow scripts? they were never implemented.
Ah. Well, that there answers my question! Thanks! With a L function, I’m sure I’ll always have a line of space to have them around.
Looks like the $ in the new op names is interfering with LaTeX, which uses that symbol to start or end an in-line math section. I can take a look if you didn’t already.
that would be great! i thought it might have something to do with that and checked what the doc for
$ looked like and didn’t see any additional formatting there.
@desolationjones have your ops found their way into the consolidated beta yet? No pressure or anything but I also don’t want you to think there’s no interest. I’m eager to try these out, preferably alongside the binary and hex entry ops.
They have not! I had to RMA my CPU so the compy has been sitting idle. But the new CPU is working well and I hope to make time soon for this pull request. I am also eager to try the hex entry mode
Seems the docs are building again Thanks for the fix, you know who you are (but I don’t)!!!
that was generous help from @jngpng - super thankful as it saved me a lot of time!
Then I’ll say thanks @jngpng
My changes are in:
DEL.B (my favorite),
BTOG (bonus OP!). I can confirm they are all quite fun with the
DELAY_SIZE is turned up to 64 and seems quite stable so far in my testing.
@scanner_darkly I’m noticing that the
B numbers do not allow converting to a negative number. E.g.
X caps at
X7FFF. Is that intentional or a limitation of the input parser?
EDIT: To clarify, you can put in larger numbers but it will not display a result greater than 32767.
EDITEDIT: Ok I can see this is a limitation of what we are passing to the
strtol() function. I will hold further comment until I grok your implementation.
yeah that’s a bug. i’ll take a look.
One solution could be to wrap
val instead of capping at
INT16_MAX. The consequence would be that a user could input
32768 and receive
-32768 instead. For my own tastes I’d rather have no guardrails but I can see that tripping up new users.
SUB OPs already wrap, and there are purpose-made
LIM OPs for limiting output ranges.
BTOG? And 20 characters.
BTOG x y "toggle bit
y in value
So it flips the specified bit!
Very useful for things like
X BTOG X RND 15 for flipping a single random bit of a gate pattern.
fixed in this PR (also ran clang-format on files changed in your PR): https://github.com/monome/teletype/pull/226
Awesome additions! Nicely done!
Was playing with
DEL.B last night, and whilst it is awesome, I found the way it interacts with the
B numbers a bit weird. It’s reading the pattern starting from LSB right? So when you use
B you kinda have to write your pattern backwards? Maybe I was misunderstanding how
B works when you don’t write out the full 16 bits.
Yes, you have it correct. So
DEL.B M B1011: TR.P 1 would go “ping! ping! … ping!”
You don’t have to write out all 16 bits.
I guess the slightly weird UX is to do with the convention on writing binary numbers then, with LSB appearing last. Might it make sense for
B to go against the convention and write the LSB first? IMO, that would make more sense for using it with both
QT.B which both kind assume a left-to-right organisation (steps in the
DEL case, keys in the
QT case). What do you think @scanner_darkly?
I agree that the input is cumbersome if you are thinking of the lowest bits first while the cursor scrolls the “wrong way”, but the convention is firmly established. I think it is fair to compare it with the digits of a base-10 number. The smallest digit is always on the right, whether it is the “3” in “23” or the “0” in “B1110”.
Maybe we just need an input mode that scrolls the cursor backwards while inserting new characters
i would say that it’s better to change how
DEL.B reads a number - since this would limit the non standard convention to this specific op (where it feels more natural), rather than applying it to how binary numbers are defined in general, which would go against the standard convention.
is there any concern about changing
DEL.B to start with MSB instead?