I was watching some of miller's videos on the internals of pd and got inspired to try a different (probably processing intensive) method of parallel processing for multiple oscillators/additive synthesis & came up with this ugly thing after some hours. Basically it uses upsampling to use every "location" in a block as a separate oscillator. (so sample 2 in a block is oscillator 2, etc.) The subpatch is upsampled x64 with 64 block size so every sample 1 sample of 64 oscillators are being processed. [tabsend~] and [tabreceive~] are used for storing the phase of the sine waves in-between samples. It's probably relatively heavy on the processing. still I thought it was kinda cool.
If anyone knows how to get the sum of all samples in a block in vanilla that would also be helpful (I'm using [rfft~] now but don't need to do an entire fft just for the sum)
additive.pd

@seb-harmonik.ar [iem_tab/tab_sum] maybe......
David.

@whale-av thanks, one tricky part is to trigger it between block boundaries in an upsampled patch, I think [bang~] only works at the base samplerate.
Basically what I need is to have the sum of all samples in a block from a signal in the first sample in the same block.
I was trying to do something with vanilla but might just write an external for it myself if it comes to it.

@seb-harmonik.ar Sorry to revive this old thread, but I was intrigued by the perversity...um, I mean cleverness...of your patch

I originally thought to use [rpole~] instead of [fexpr~] but the right inlet is control rate and so I was back at the [bang~] problem. And then I couldn't figure out how to get the sum into the first sample of the current block, so I just pushed it to the head of the next block, which in the downsampled environment is just a 1 sample delay so maybe that's not a problem?

@jameslo ? the right inlet of [rpole~] is signal-rate tho.. (this is why I think it's a good idea to use a version of pd that has different looking inlets & outlets for signal-inlets and outlets)
not a bad method, it probably is easier to just output the sum on the next output sample in general.

@seb-harmonik.ar Huh, sorry for the weird claim about [rpole~]...the idea came to me in the middle of the night, so I got up to try it. I remember not being able to connect [tabreceive~] to it. Anyway, I know you get it but for others following along you have to init $0-sumCtrl with [const 1, 0 0( when using [rpole~].

@seb-harmonik.ar I just learned about [lrshift~] and it brought me back to your patch again. This should be equivalent to your use of [rfft~]

Update: I built a 128 sample block version to compare with the way I've always done this (using 100 clones) and your way uses less than a quarter of the CPU!