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.

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.

there are a few bytebeat things in pd... here's a good one:
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.

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?

here i tried to generate midi sequences with one-liners: https://forum.pdpatchrepo.info/topic/10797/algorithmic-compositions-from-one-line-of-code

@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