PURE DATA forum~

I don't know too much but you could try decimate~ for bit conversion.

It won't invert different bits but decimate~ is close enough in sound, might be useful.

How would I get the 8 individual bits of the 8 bit signal?
8 [decimate~] objects? I didn't see in the help file if it can choose a bit, It looks like it just sets the overall bit depth you want. Would I route the [decimate~] to [hip~] or [lop~] filters to isolate the bits?

As for [swap~] the help file says that it converts the signal to 16 bit before it inverts the bits. So would I route the signal through the [swap~] then [decimate~] that to 8-bit? or vica versa?

Thanks for the tips guys!

Hey LarsXI,

Just took a look at your patch, and you're actually creating a 4-bit signal. To get the correct range for bit depth, you need to raise two to the power of the bit depth. So 2^8=256, but since we use zero the range would be 0-255. And then quantize it with int(). I've always done it like this:

[expr~ $v1*.5+.5]  <-put the signal in 0-1 range
|
|                           [8\ <-bit-depth
|                           |
|                           [expr pow(2, $f1)-1]
|                           |\
[expr~ int($v1*$f2)]  \
\                               |
  \                             |
    [expr~ $v1/$f2*2-1]  <-bring it back to -1 - 1 range

I've never used [quantize~] before, but from looking at it's helpfile it would seem all of that can be done by sending it the [8bit( message, but that's not as fun ;-).

Last edited by Maelstorm (2010-02-25 10:06:08)

Maelstorm wrote:

Hey LarsXI,

Just took a look at your patch, and you're actually creating a 4-bit signal. To get the correct range for bit depth, you need to raise two to the power of the bit depth. So 2^8=256, but since we use zero the range would be 0-255. And then quantize it with int(). I've always done it like this:

[expr~ $v1*.5+.5]  <-put the signal in 0-1 range
|
|                           [8\ <-bit-depth
|                           |
|                           [expr pow(2, $f1)-1]
|                           |\
[expr~ int($v1*$f2)]  \
\                               |
  \                             |
    [expr~ $v1/$f2*2-1]  <-bring it back to -1 - 1 range

I've never used [quantize~] before, but from looking at it's helpfile it would seem all of that can be done by sending it the [8bit( message, but that's not as fun ;-).

hmm, yes I worried about that when I started thinking about it. If that was 8 bit then cd quality audio would be rather crappy.

Makes me wonder how bit inversion works

the expr~ int() works just like quantize in Maelstorm's example.

for the conditional expr to work nicely, I think it helps to have a separate quantized signal that expands the signal to eight quantized integers

like so

I don't think this captures the character of actual anolog-digital 8 bit converters, but I think it makes the bit inversion concept slightly clearer?

hmm, I'm not sure why this is happening. I only ran a sine wave through it, so how it deals with complex audio, I don't know.

What I did notice is that my technique for muting is actually incorrect. If it was working right, it would send the signal to zero, at the center of the -1 to 1. I forgot about the offset. Where it's at now, it simply takes the bit and clips it at -1.
That may be where the problem is coming from.

this editing time i won't edit again! :3

if you do the array version you could even make a completely variable bit rate
in most programming languages it would be a short for loop or recursion
but doing this in pd will be a hell

but you could always do less than maximum bits just by changing the value for max_bits

Last edited by slur (2010-02-26 02:31:06)

Yeah, bit inversion and such is done on the individual binary digits. Take a look at the attached patch. It should do what you're looking for, and hopefully is able to explain how it's doing it.

Edit: oops, forgot the int(). ;-) Reposted.

Last edited by Maelstorm (2010-02-26 06:11:17)

i think all this got covered already, but here is my version for messages

atarikai wrote:

So the first [expr~ int()] (which can also be a [quantize~] right?) is converting the signal from (numerically) -1 - +1 to 0 - 255. Converting it so it can be manipulated easier down the line.

The first [expr~] is only a portion of what [quantize~] does. The one at the end would be the other portion. So you can't just replace it with [quantize~]. The reason why it's converting it to integers in the range of 0-255 is because that is all that 8-bits can represent. Technically (and possibly to confuse things further) all numbers in Pd are represented in 32-bits. Using integers between 0-255 only uses the first 8-bits, while the other 24-bits are zeroed out. So this allows you to treat a 32-bit number as an 8-bit one.

he next 2 [expr~] are the inverter and muter. Would you describe what they do being 'masking' or 'filtering'? Maybe the inverter is a filter and the muter is a mask?

I would just call it distortion. ;-)

The last [expr~] is converting the 0-255 back to -1 - +1 (otherwise it wouldn't fit in the array).

Not just to fit in the array, but also to not clip your dac. With 32-bit floating point audio, the standard is to fit it in the range of -1 to 1 when it is send to the soundcard. It will then convert that range to the bit-depth your soundcard uses. Anything out of the -1 to 1 range is considered headroom for processing in Pd, but once it reaches the dac anything out of that range is clipped.

Thanks alot for building this for me. I didn't realize you could manipulate a signal this way...I thought we'd have to convert the signal to integers, manipulate the bits then convert back to a signal again.

Well, that is what we're doing, more or less! It's just "not really" integers, as explained above, but we can still treat them like integers. And technically, it's always a signal.

Last edited by Maelstorm (2010-02-26 19:17:03)

You know I was just thinking that the mute and invert sonically sound the same, the invert just sounds a bit louder...

Wait, where/how would you make the bit = 128? when all the bits added together = 255? Sorry, I'm still learning the math aspect of all this.

-Kai

yeah, i know, but in pd you have 32 bits, so you can cheat.

if you make the mute default to 128 instead of 0, then you don't have to account so much for the DC offset you will get if mute is 0 or 255