• ### How to translate crazy one-liner symphonies to Pd

Was curious to know if someone attempted to recreate these weird one-liner symphonies in Pd. It should be possible right? Is there any bitwise math genius able to understand this?

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

``````

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

• Posts 7 | Views 395
• You need something to drive this. In the code chunks of the link you provided, t is a variable that increments by one on every loop of the code. Perhaps feed a [phasor~] multiplied by some value to an [expr~] which will run this code. Be careful to check the output and normalize it before sending it to [dac~], no idea what the function above produces.

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.

• you can use rpole~ with a "1" going into it to generate a signal that counts up every sample. If I understand the code correctly everything is put into a character, which I assumes just truncates the extra bits. so this means you have to divide the output by 256 and wrap~ the result: (and I did a `[-~ 0.5]` to get rid of dc)

and it seems like the sample rate was 8000 hz originally?

• @seb-harmonik.ar regarding rpole~ as a sample counter i made the experience that it stops after a few minutes. i tried to replace it with expr~: https://forum.pdpatchrepo.info/topic/12644/vanilla-ofeliasamplecounter

• @Jona I think the issue with your method is that the value stays the same over the entire block, so using it to drive a function would only output changed values at the beginning of every block.

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

Posts 7 | Views 395
Internal error.

Oops! Looks like something went wrong!