Gen~ why no bitwise operators like >> or bitwise logic ops?

Well - bitshift / bitwise operators are more commonly used on integer values, whereas within gen~ all signals are 64bit float. There are bitwise instruction sets for floating point, although I'm not sure I've ever seen a fp bitshift, as it would be pretty meaningless.

I'm curious - what do you want them for? I do *A LOT* of low level DSP coding, and I rarely if ever use floating point bitwise ops - am I missing something here? The only real use for them (other than hardcore distorted sound munging) that springs to mind is for doing crazy efficiency hacks that really don't fit into the gen~ idea of the interface taking care of low-level implementation details.

I'm genuinely curious, as to what they are valuable for...

Alex

Cheap downsampling distortion effects in integer based audio. Personally, not a fan, but there are many fans of downsample artifacts.

Sure - I get that (hence the munging comment), but you don't *need* a bitshift operator for that, you can multiply the audio up, truncate the floating point part, and then divide back down. In fact, that gives you a lot more options for pseudo-fractional bit depths.

Now if there's no way to truncate that could be a more serious problem IMHO.

I'm still interested to here from Veqtor about what he had in mind to do with bitwise stuff...

Alex

Well, emulating old machines like atari 2600 and storing some information in upper bits etc

For example building your own pseudo-random number generator. I thought the point of gen was to get access to low level blocks. You can for example do some quite nice glitchy visuals using xor and bitshift, it would be a shame if they're left out of the jitter equivalent...

Okay, I can do it, but it feels wrong to build buckets of history to create a shift register...

Just chiming in to say that I'm loving the mult/trunc/divide pseudo-fractional thing!

Ironically, I spent some time in the last three months writing audio rate pseudo random stuff / MLS etc., so I should have thought of that! I have no idea of usefulness for jitter, as that is not so much my area, but I'm sure you are right - I can say however, that in jit.pix.gen (I think that's right) that all the calculations are floating point, so same issue is going to apply...

Actually that's a much better argument for it than I was expecting, but there are probably a couple of things worth bearing in mind:

1 - This is far lower level than a lot of people are going to want to go (or even be aware of).

2 - Really I can only seeing it make sense if there is a way to do specifically 32-bit int calculations within gen (perhaps in a specific gen object within there are a new set of int objects??) - the confusion of mixing 64bit floats and ints is just not a great idea, or going back and forth between the two...

It's not up to me though. I'd guess this won't come anytime soon, but let's see what happens!

@Rodrigo -good...

A.

I guess I will have to implement what I want to do with history objects then. Too bad, I did the same in reaktor until a friend of mine showed me how to do it with bitshifting, bitmasking, which took the cpu usage down from 23 to 1%...

Even though things like these are only useful for optimization I still believe the gen object doesn't magically optimize our code, the same optimization principles of ordinary programming still probably applies.

Perhaps Max could benefit from assignable datatypes inside gen like int, boolean and float w. 32 and 64 bit precision? Reaktor has this in core and it's quite useful given what a terrible waste it is to 64-bit floats to store bools.

I think a 'strongly-typed' [gen~] would cause more trouble than it's worth. It would need duplicate operators for each type, and you'd have to build your patches in a modular way so as to minimise casting. And once you start wrapping casts in higher-level stuff like [gen~], you're wasting a lot of cycles.

Perhaps it will be possible to write our own [gen~] operators? That would really be something. But if you crave the fastest performance possible I reckon the minimum overhead comes from writing your own MSP objects.

It sounds like you're already low-level enough to handle a bit of C. Consider taking it to the next level like this (XCode/Intel Mac syntax):

float *in = (t_float *)(w[1]);  // Object input
float *out = (t_float *)(w[2]); // Object output
long rounded;                   // Temporary integers for bit-twiddling
long truncated;
asm {
        mov     esi,    in      // Load pointer to input signal into esi
        fldl    [esi]           // Copy qword from address pointed to by esi
                                // onto the FPU stack
        fist    rounded         // Convert to integer using default rounding
                                // mode (usually round to nearest) and store
                                // in our temporary variable
        fisttp  truncated       // As above, but with truncation and pop
                                // the FPU stack (requires SSE3)
}

// MORE C OR ASM BIT TWIDDLING GOES HERE

asm {
        mov     edi,    out     // Load pointer for output signal into edi
        fild    rounded         // Convert integer back to floating point
        fstpl   [edi]           // Output a double-precision value and pop
                                // the FPU stack.
}

Oh, how silly of me. You probably just want to deal with bitwise representations of signals as floats, rather than casting them to ints.

In any case, if you're dealing with signals in the range +/- 1.0, you'll need to multiply them by 1<

Watch out for negative integers - they will be stored in two's complement form. There are also a couple of other pitfalls with fixed point; here is a good guide:

http://www.google.co.uk/url?sa=t&source=web&cd=2&sqi=2&ved=0CCIQFjAB&url=http%3A%2F%2Fjet.ro%2Ffiles%2FThe_neglected_art_of_Fixed_Point_arithmetic_20060913.pdf&rct=j&q=fixed%20point%20forgotten%20art%20%5C&ei=pUedTojeBMKp8QOzy43-CA&usg=AFQjCNHd3mE-875SyejyLLeRCtq4oKhdhg&cad=rja

long multiplier = 1 << 63;
asm {
        fild    multiplier
        mov     esi,    in      // Load pointer to input signal into esi
        fldl    [esi]           // Copy qword from address pointed to by esi
                                // onto the FPU stack
        fmul    st(0),  st(1)   // Upscale for 1:63 fixed-point arithmetic
        fist    rounded         // Convert to integer using default rounding
                                // mode (usually round to nearest) and store
                                // in our temporary variable

// ASM ONLY IN HERE, BECAUSE WE CAN'T TRUST THE C COMPILER NOT TO
// TRASH THE FPU STACK. MULTIPLIER IS LEFT IN ST(0), TAKE CARE!

//        fstp    st(0)           // UNCOMMENT ME IF YOU WANT TO USE C
//}                               // UNCOMMENT ME IF YOU WANT TO USE C

// ALTERNATIVELY, PUT YOUR C CODE HERE

//asm {                           // UNCOMMENT ME IF YOU WANT TO USE C
//        fild    multiplier      // UNCOMMENT ME IF YOU WANT TO USE C

        fild    rounded         // Convert integer back to floating point
        fdiv    st(0), st(1)    // Downscale from fixed-point representation
        mov     edi,    out     // Load pointer for output signal into edi
        fstpl   [edi]           // Output a double-precision value and pop
                                // the FPU stack.
        fstp    st(0)
}

If you just want to manipulate floats at the bit-level instead of worrying about fixed-point arithmetic, if you do play with any assembly, remember that 64-bit MSP signals won't fit in a 32-bit register! Hopefully Max will go truly 64-bit and we'll have access to 16 128-bit XMM registers, 16 64-bit GP registers, and even 256-bit YMM registers for Sandy Bridge peeps.