Karplus strong and strange issues with fexpr~

Reply to Karplus strong and strange issues with fexpr~ on Sun, 03 Dec 2023 20:43:32 GMT

reubenm — Sun, 03 Dec 2023 20:43:32 GMT

Hello! I have noticed something a little bit weird trying to implement a karplus strong algorithm with fexpr~

I was previously using delwrite and delread with feedback and this worked fine up until delays of 1 milisecond. When i try to use fexpr~ for a per sample delay however the resonance of the karplus strong dies down as delay times get lower. interestingly the lowest pitch i am able to produce with this algorithm is about 660 hz which is roughly the same as the highest frequency with delwrite~ and delread~.

I have written in my fexpr~ object $x[0] + ($y1[0 - $x2] * 0.95)

I can't see why this would function any differently and yet it does?

I understand that it is possible to implement samplewise delay with subpatches and order forcing but i've never been able to get this to work properly.

Reply to Karplus strong and strange issues with fexpr~ on Sun, 03 Dec 2023 20:47:10 GMT

reubenm — Sun, 03 Dec 2023 20:47:10 GMT

Another aspect to the weirdness is that the drop off in resonance happens when the second input of fexpr~ is at around 64 which i guess is the same number of samples delread will process at once when delread is given a message of 1?

Reply to Karplus strong and strange issues with fexpr~ on Sun, 03 Dec 2023 21:12:42 GMT

reubenm — Sun, 03 Dec 2023 21:12:42 GMT

these are some pictures with the pd patch and below a spectrogram so you can see what I mean

Reply to Karplus strong and strange issues with fexpr~ on Sun, 03 Dec 2023 21:45:33 GMT

jameslo — Sun, 03 Dec 2023 21:45:33 GMT

@reubenm It sort of works for me, but I have the opposite problem in that I can only get frequencies above 689 hz, which makes sense to me because fexpr~ only buffers the last block of audio (I mean, right? There's got to be some limit!).
KS in fexpr.pd

I'd be surprised if [fexpr~] is the way to go for this application. I think you have to sit down and work out how to make Pd's delay line go to zero. Give a look at Help->Browser...->Pure Data/->3.audio.examples/->G05.execution.order.pd

Edit: Wait, maybe you're saying the same thing as I am. You wrote "as delay times get lower" but maybe you meant "as delay times get longer" in which case my observation about the maximum fexpr~ lookback is the answer.

Reply to Karplus strong and strange issues with fexpr~ on Sun, 03 Dec 2023 21:50:59 GMT

reubenm — Sun, 03 Dec 2023 21:50:59 GMT

ahh I see that does make sense! I've just tried putting the fexpr~ in a subpatch with a larger block size and now i can get lower frequencies! I wonder what the difference in computational expense is with this method and the order forced delay line? I am quite new to all this stuff so I'm pretty ignorant when it comes to computer science.

Reply to Karplus strong and strange issues with fexpr~ on Mon, 04 Dec 2023 12:58:20 GMT

jameslo — Mon, 04 Dec 2023 12:58:20 GMT

@reubenm I never care about computational expense until it's a problem, and even then it sometimes generates some cool stuttering that I would never have thought of. But if that fexpr~ way of doing things speaks to you, then maybe you should look into supercollider And I'm not trying to be a jerk because as a former java/c# programmer I'd probably prefer it!

Edit: Ouch! I think I'm confused about the delay line and forced order of execution. In KS you're feeding back the output of the delay line into the input, so either you have to have the delay line read upstream of the write (and so you have a min 1 block delay) or you have to send the delay line read signal back up to the delay line write (which also incurs a 1 block delay). So either way I think you have to reduce the block size to get frequencies above 689hz.