I have been scouring the forum. Just to confirm: there is no easy way to do a phase shift with sinesum. Right. One could make a patch that could do a phase shift of a certain partials and then combine the two or three or more arrays, though.

Correct?

there is no easy way to do a phase shift with sinesum

Correct-ish. You can shift any partial by 180 degrees bu multiplying it's amplitude by -1 I suppose

One could make a patch that could do a phase shift of a certain partials and then combine the two or three or more arrays

Yes. The solution is in this thread: https://forum.pdpatchrepo.info/topic/3506/phase-timing-help-basic

Alternatively, if you need phase control of each partial you could stack a bunch of [cos~] modules driven by the same phasor like this:

[phasor~]
|
[*~ n] (where n is partial#)
|
[+~ p] (where p is phase)
|
[cos~]
|
[*~ a] (where a is amplitude (duh))

Rethinking this, in the proposed array solution, phase shifting an entire array of sines is problematic as the phase shift will be relative to the fundamental only. Thus shifting it 45 degrees will shift the 2th partial 90 degrees and the 3rd partial 135 degrees etc...

You won't have this problem with the [cos~] stack, so the most viable solution would be a sinesum omitting the partials you want to shift and add those as [cos~] stacks (I think...)

@raynovich I thought this way by @jyg was clever

edit: oh but you'd have to add in the imaginary input AND you'd have to know how to map the phase you want into the real and imaginary FFT coefficients. Yeah, I guess it would be clearer to just generate the sum by hand, even using counters and cos in control rate.

@jameslo as far as I can tell @jyg 's method only allows you to vary amplitudes, not phase. But I am not well versed in fft operations...

@bocanegra Yeah, sorry, I edited my comment after I realized my mistake.

@raynovich For a single frequency (rather than a group envelope) a phase shift is a delay.
Maybe for a group envelope too, but I think not because different frequencies will have been shifted in time by different proportions of their waves.
So this might be no more correct than using an audio delay for any other signal than a sine wave.
phase-shift.pd
Or it might be what you want.
David.

@whale-av I think that last patch you did could be a nice way of shifting wave forms. I just, after 6+ years of using puredata "discovered" sinesum. I was surprised that it did not have a simple way of manipulating phases and could look into using it in the future.

@raynovich This could also work:

arrayshift.pd

Right- the problem with Davids solution, like he suggests, is what I pointed out already- the phase shift is proprotionaly different for each partial.

I decided to give the ifft method a try, and lo and behold:

phase_shift_sinesum.pd

By calculating both real and imaginary partials as
A x sin(P) (real partials) and
A x cos(P) (imaginary partials)
And routing the two lists into the ifft's real and imaginary inputs, you can shift the phase of each partial independently and proportional to it's respective cycle (measure in radians)

There are small issues that could be smoothed/tweaked. For example the phase sliders need a bang on startup for everything to work... it was a quick and dirty mod...

Shoutouts to @jyg (mentioned above) for the framework i used

@whale-av @bocanegra @ingox
I am so appreciative of your responses. Each one of your responses has taught me so much. whale-av gave a really nice implementation and then ingox made it so simple. Wow.

I really like bocanegra's response, though the ifft implementation is above my understanding right now.

Thank you all for your input. I am indebted.

@raynovich Surely not, since sharing knowledge benefits all