Ok this effects/filter box is exactly want I want to build in PD

http://createdigitalmusic.com/2010/02/24/oto-machines-biscuit-8-bit-analog-filter-effect-designing-new-hardware/

(check out the video)

I think it's all possible in PD just based on the experiments I've done with the waveshaping demos ...I think the samplerate stuff has to be done in a subpatch with a [switch~] object. I've come across a few old posts about smoothing out aliasing so I think that's possible too.

Anyone have any tips or patches that might help me get started? I've been using PD for about 6 months, really getting the hang of it and would love to be able to build this for my future music productions.

-Kai

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.

[swap~] inverts bits, I think

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!

How does oto biscuit handle the bit inversion?

Is it signal inversion of individual bit-levels?

From my understanding, if the 8 bits are invertable or mutable seperately, this must mean the signal level of the individual bit is remapped to a level of opposite polarity in the case of inversion, and in the case of muting, that particular level is remapped to zero?

If this is how the unit is operating, it's a simple question of setting up an if-then expr~ object that remaps certain signal levels.

I'll draft something up in a moment.

edit---

Here we are. Attached file is how I see it

http://www.pdpatchrepo.info/hurleur/lxi_guessingBitInversion.pd

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 .

atarikai if you do this abstraction please share
sounds quiet interesting

@Maelstorm said:

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 .[/quote]
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

@LarsXI - yes, that's how the box works and thanks for your patch.

@Maelstorm - where would I edit LarsXI's patch to incorporate your bitdepth calculation? You said the calculation could be achieved with a [quantize~] but I already see a [quantize~] in the patch (after the signal gets multiplied by so I'm confused. Does the [quantize~] come before or after the [decimate~]?

Ultimately I'd have to duplicate the expr 8 times (for each bit) then make a toggle that will change the variable to 1, -1, or 0. sound right?

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?

http://www.pdpatchrepo.info/hurleur/lxi_biscuit_mockup.pd

@LarsXI thanks for your help! It seems to work as designed though it will take some tweaking to get the 'character' you mentioned. I noticed that when 'bit 3' or 'bit 4' are set to mute the signal goes wild...in a good way! Is there some reason that those bits are chaotic and the others aren't? Maybe it depends on the signal you feed into it.

I've attached what I built built so far... I've added one of my samplers and beat mangler abstractions for loading and manipulating wav files.

I'll keep hacking away and adding the other features and effects.

Thanks again for your help Lars

-Kai

http://www.pdpatchrepo.info/hurleur/kai_biscuit_beta.zip

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.

people.... what the fuck are you doing?
whatever happens it looks interesting...
but that's not a bitwise operation

in this example the input signal would be thrown through the function (signal+1)*(pow(2, highest bit)-0.5)
and afterwards through the inverse to get a normal signal again
and you'll need a hip because the signal is attracted to -1 if you zero the higher bits

maybe you should think about doing this through an array to save cpu time
8 expr~objects alone for the bit operation could be quiet heavy
but it would be more complicated and not so straight forward to build

http://www.pdpatchrepo.info/hurleur/example-bit-confuser.pd

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

@slur said:

people.... what the fuck are you doing?
whatever happens it looks interesting...
but that's not a bitwise operation

yes, I had a sneaking suspicion I had no idea what the hell was going on.

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.

http://www.pdpatchrepo.info/hurleur/bitbashing.mmb.pd

ahhh much better version
stupid me...

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

http://www.pdpatchrepo.info/hurleur/bitinvert.pd

@Maelstorm I've been studying your patch making sure I understand how it works and what it's doing to the incoming signal. I want to see if I understand this in laymen's terms (the mathematics involved are over my head, but thanks to your explanation I understand what they do).

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 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?

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

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.

@atarikai said:

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.

i was just thinking, for the bit 'mute' function, it would maybe be an improvement to make the mute value = 128, so then when you do the conversion back to a -1->1 signal, the muted bits would all be zero.