#1

Has anyone used the bitwise operators on Teletype to store multiple pieces of data in each cell? I’m working on a scene using the grid integration where i’d like to maximize the number of patterns I can switch between and since I’ve got the grid to visualize the data in the pattern view, I figured I could maximize the storage by stuffing those bits (sorry prob not the correct term).

The first piece of data is a division between 0-32 (inclusive) so that needs 6 bits. The next piece of data is an offset between 0-16 (inclusive) so that’s another 5 bits. The last is between 1-4 so that’s another 3 bits.

The pattern cells hold values between -16384 and 16384 so I think that means there are 15 bits used to store them? 6 + 5 + 3 = 14 so theoretically this should be possible right?

I guess what it comes down to is the syntax for stuffing and unstuffing the individual pieces. My bitwise operation skills are basically non-existant, but I suspect with the limits on space in a TT script, it might be prohibitive.

Can anyone demonstrate what this code might look like?

1 Like
#2

@sliderule i see that you implemented bitwise ops here (Teletype) Bitwise Operators (Done!) so maybe you can comment on the plausibility of this

#3

it’ll be much easier once we have the dedicated bitwise ops, but yeah, you can do it now. you can store 16 bits (the range is actually -32768…32767), in most cases you can just treat it like an unsigned 16 bit integer (not sure if RSH / LSH are signed or not, so that’s something to be aware of if using these ops).

i used this technique to store 16 bits in pattern values here: Grid ops / integration

1 Like
#4

Storing requires shifting and bitwise OR:

Here, C is the result of a 6 and a 5-bit field.

A 31
B 15
C | A LSH B 6

Extracting the fields requires shifting and AND.

A & C 63
B RSH C 6

Here, 63 is a mask to isolate the first 6 bits (63 = 0b111111).

More fields will require more careful usage. A field in the “middle” will require a shift as well as a masking AND.

As the numbers are signed, I would simply avoid using the most significant bit at all if you are counting on doing math with the numbers. Poking the top bit will screw with the results of your RSH. It won’t be a problem if you always AND mask the top field when extracting, though, I think.

Also, don’t try to store negative numbers this way.

#5

we don’t have bitwise OR yet though (i think you added it in 2.2)

#6

True, but 2.2.0-beta.1 is available and stable, so it’s no hurdle to presume the adoption of that final syntax.

2 Likes
#7

thanks for the example code. i guess i’ll hold off until 2.2 and grid integration meet up.