```
t*(((t>>12)|(t>>8))&(63&(t>>4))));
```

There is a nice write up here and a funny JS toy to play with.

]]>```
t*(((t>>12)|(t>>8))&(63&(t>>4))));
```

There is a nice write up here and a funny JS toy to play with.

]]>Mind that the videos in the link produce 8-bit audio. If you want to achieve something similar you should probably multiply [phasor~] by 255 and truncate the decimal part, in [expr~ int($v1)], or something like this.

]]>https://forum.pdpatchrepo.info/topic/12647/0xb105food-experimental-music-texture-generator-using-bytechip-equations-v1-alpha/1

which follows from https://forum.pdpatchrepo.info/topic/12638/bytechip-automaton-combining-automatonism-v3-0-bytechip-equations/1

there's also snd.bytebeat~ in https://github.com/megrimm/pd-fresh which works pretty well.

]]>`[-~ 0.5]`

to get rid of dc)and it seems like the sample rate was 8000 hz originally? ]]>

you could use your method of adding the samples of a block in conjunction with a `[tabreceive~]`

reading from a table that contains every integer from 0 to blocksize-1 and that would work though.

(btw I also have an object in my library `[pinb~]`

that simply outputs the current sample # in the block for situations like this)

also if you do run it at a samplerate of 8000 hz it will take a ~5.5 times longer for rpole~ to not be able to represent than @ 44.1k so in this case it might not be as much of an issue (though obviously a counter that doesn't do that at all is preferable)

of course any method will lose precision between samples, especially if the counter isn't reset to 0 after 2^32 -1 samples (assuming "t" is a 32-bit integer)

in pd-double it would probably be better to use phasor~ with / and *~ to scale phasor to increment 1 every sample, with a period of 2^32 samples. Unfortunately in 32-bit float pd you can only represent up to 24 bits of precision so you can't divide or multiply by 2^32 exactly