I understand if i have to ask what this brings to Teletype that I’m too early in the process of working with more complex operations with the device, all the same could someone explain this like I’m five?

Are you asking what bitwise operations are in general, or why we’d want them in teletype?

They are now in firmware 2.2 beta 1 and I’m trying to understand what they will be offering to Teletype and maybe even how they’ll be used?

You could encode 2 tracks of trigger logic plus 2 tracks of midi note data in a single pattern!

```
A P.NEXT
IF BGET A 15: TR.P 1
IF BGET A 14: TR.P 2
CV 1 N & RSH A 7 127
CV 2 N & A 127
```

Why you’d want to is another story…

Would someone please verify if N represents a Note in all circumstances?

Then if it is, is it also essentially a variable?

Edit: So I think I figured it out that “n” represents bit position and that maybe “N” is indeed note, but I’m not 100% certain.

The | command is missing from the Help file although Bitwise A OR B is to the right of where the pipe should be.

Regarding the operators &, ^, |, and ~ their values are listed in the Help file as A and B but does that mean A and B represent variables or bit position?

BTW in the user manual variables are listed a X and Y, what am I missing that should be obvious to everyone else that they are different?

Bitwise AND, XOR, and OR have position independence for arguments. A | B == B | A.

In the documentation, arguments are lower-case in the blurb. So `x`

and `y`

and `a`

and `b`

are placeholders.

In `BGET`

et. al., the arguments are positional. `BGET x n`

means `get bit n from value x`

.

Hope that clears things up!

Of the variables A, B, C, D, X, Y, Z, and T which of these can be used for Bitwise operations? And are there any other potential variables or positions where bits can be read by Bitwise?

you can use bitwise ops on any values, so any variables or pattern values or `IN`

, `PARAM`

etc etc (this is the case for all ops that take parameters)

i’m returning some unexpected BGET results, wondering if somebody could help verify. running TT 3.0 RC1.

BGET 11 0 returns 1

BGET 11 1 returns 1

BGET 11 2 returns 0

BGET 11 3 returns 1

but 11’s binary representation should be 1011, yeah?

that looks correct. bits are counted from the lowest (the rightmost) bit. so in this case:

```
3210
1011
```

i will leave this up for anyone else with similar q’s but it sorta hurts how obvious that was in retrospect. exactly like ones/tens/thousands counting. i legit had an elementary school flashback. thank you for the continued education!!