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?
How to translate crazy one-liner symphonies to Pd
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:
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?
@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
Oops! Looks like something went wrong!