Oy. Of course, having posted this, I have now figured out the issue: formants. It's not that the [freqshift~] isn't working or that the math is wrong, it's that the chain of [freqshift~] objects is mucking with the formants. The stretching/compressing isn't really what's happening, it's that the sound is seriously altered. When I use a sine wave (I've been using viola samples), the pitch shift is clear as a bell. Seems like the solution is to sum the frequencies before sending them to the [freqshift~] objects, rather than chaining them. Any comments are still welcome.

what are you doing with Hz there? you dont need Hz at all.

My education in Max/MSP is full of holes. If you have an alternative approach, I'd love to hear it.

Frequency shifting is terrible at maintaining the harmonic relationships present in whatever you put into it. You'll have much better luck using pitch shifting (Yeah, it's actually different from frequency shifting). I don't really know much about calculating shifts in precise semitones, but I do know it's possible since Tom Erbe did it in one of his VSTs.

1. i havent looked at your patch and 2. pitch shifting is indeed not possible with the freqshift object.

besides that i would recommend to run parallel delays here - and not a feedback loop, which makes things extremly complicated, and reduces the quality with every loop.

you can mimic an echo with a feedback of 50% gain using [tapout~ 100. 200. 300. 400.] ... [*~ 1.] [*~ 0.5] [*~ 0.25] [*~ 0.125] ...

and then you apply a pitch shifting, spectrum shifting, or filter effect of your choice to each of the outputs. actually really simple!

alternatively you can combine a tapping buffer delay contruction with a granular pitch shifter, by reading out the tapouts using continiously raising signals, but that involves some weird math for the readout signal and expensive per-output windowing.

-110

btw, in your original approach to get frequency (in Hz, which is right for spectrum shifting) number 3 from frequency number 2, it would probably be best to just "undo" the calculation for frequency number 2 and so always start from zero/default/unpitched.

but hitting chromatic positions doesnt make any sense for spectrum shifting anyway. :)

you can at least do something similar in cases where the associated base pitch of the incoming musical event is known, say like you make an effect plug-in with a midi input, so that it can follow the melody.

to do so you combine spectrum shifting with spectrum rotation.

Thanks!

Noah, you hit it exactly. I think the artifacts introduced by the [freqshift~] object processing timbrally complex sounds are interesting in their own right, but not at all what I'm looking for in this patch.

Roman, it sounds like we're thinking similarly, even as your understanding is more nuanced than mine. If I'm following you, both in the original patch and in my "fix" of it (following my second post) I ended up applying several of the principles you suggest.

At this point, having demonstrated that the patch works as designed -- and coming to realize that getting it to do what I want may require much more complex processes than I want to invest the time in right now in order to compensate for the mucked up formants -- I'm going to relegate it to the "good ideas requiring more education and time" bin. In the meantime, I'll take a look at pitch shifting (oh, look! there's a [pitchshift~] object!).

Anything as sophisticated as preserving formants when shifting will no doubt require a trip into [gen~] territory. You might also need to be processing in the frequency domain, so check out [fft~] etc.

Omigosh. Clearly I was just using the wrong object. Rookie mistake. Rebuilding with [pitchshift~] produces a much more interesting and desirable result. Thanks all for your help!