#7

BGET 3 A is certainly more readable than MOD RSH A 2 2 :slight_smile:

should it be BGET n X or BGET X n? the latter feels a bit more natural.

2 Likes
#8

I guess the latter fits with the existing ops better, so it gets my vote.

1 Like
Bit stuffing/shifting on teletype
#9

that was my thought, since it matches LSH\RSH X n and such.

#10

Pull request #126 opened with this functionality.

Test build: teletype.hex (355.4 KB)

1 Like
#11

looked at the PR, couple of comments:

  • it probably makes more sense for n to be 0 based
  • should we also add a bitwise NOT? as ~?
2 Likes
#12

I can do bitwise NOT as ~, sure! Good call.

As to bit indexing, I don’t know why I was thinking it should be 1-based. Working between two programming languages crosses my wires about conventions sometimes.

I’ll wait for @tehn to weigh in, but you’re probably right.

1 Like
#13

yes, 0 based.

ie

X & (1 << n)

bitwise not, excellent! to be clear, ~ only takes a single arg, yeah? if we’re going all the way, ^ for xor?

3 Likes
#14

Re: bitwise not ~

Given that bitwise not of a signed integer is not very useful, maybe the not should be performed in an unsigned manner? I.e.:

sign = x < 0 ? -1 : 1;
x = ( ~ (x * sign)) * sign;

note this breaks for -32768

It’s an odd problem.

#15

guess i’d vote for having it do the obvious thing - flip all the bits including sign.

~(-256) = 255
~(-2) = 1
~(-1) = 0

2’s-complement is standard enough that breaking it would violate principle of least surprise…

let’s see, the alternative:

would mean, in int16, that ~(-1) = -1 * (~1) = -1 * 0xfffe = … 2? i feel weird.

1 Like
#16

Alternate would be illogical, as would all negative numbers. I shouldn’t have written that up. It’s wrong and bad and it was too late in the day.

I thought that NOT wouldn’t make sense to users in a signed context, but I guess it only makes sense to use that along with BGET.

My bad!

#17

inverting all the bits makes most sense, when using bitwise ops i would likely treat values as 32 bit unsigned ints (say, as a way to pack 32 step trigger sequence into a pattern value).

edit: 16, not 32… coffee!

2 Likes
#18

PR Updated with NOT and XOR, zero-based bit indexing.

Test Build: teletype.hex (356.0 KB)

2 Likes
#19

Bitwise AND, NOT, OR and XOR would be really nice

#20

They’re all there in 2.2-beta. Got hashed out in another thread. Full set:

BGET, BSET, BCLR, &, |, ~, ^
2 Likes
#21

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?

#22

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

#23

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?

#24

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…

6 Likes
#25

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.

#26

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