I am new to PD, doing audio experiments for now and may build a performance synth some day. I thought I would post this abstract for feedback because it does a few unusual things, and I'm sure there are things I'm doing wrong. It's supposed to mimic piano key hammers, but it can also make drum like envelopes if release is shorter than decay:

ab_env.pd

Also, how slow is fexpr~? I was thinking I could implement an audio rate version of "integrator", but not if it's too expensive, I plan to add polyphony next.

@adtubu Can you post a patch demonstrating how it is used and what unusual things it does?

I'm attaching my WIP midi synth using this, open synth1.pd to try it. You need a velocity sensitive keyboard for it to work well. Play with different combinations of attack/decay/release and tapping or holding notes. I think the unique thing is that it's additive, when triggering multiple overlapping notes, and it has infinite decay. I'm not sure if this is anything unique or not, but it has been fun to put together. Any comments appreciated.

ab_pd.zip

@adtubu The release is much longer if I play staccato than if I hold a key down--is that what you intended? Otherwise, things look and sound good to me, but I defer to others here who know more about synthesis than I.

@adtubu you can just use [rpole~] as an audio-rate integrator

@seb-harmonik.ar I'm not sure if that's true. @adtubu's "integrator" is more like a recursive linear equation but [rpole~] is strictly multiplicative.

@adtubu I thought of one thing that might be improved: @solipp pointed out to me that under some circumstances [lop~] never reaches the input value, even when the input is not changing. You could use [line~] or [slop~] instead which don't have that problem. But I use [lop~] that same way when I don't care whether it reaches the input value.

@jameslo well the time factor will be different by a constant because it's happening every sample vs every ms but it seems like the same exact equation to me (feedback and all)

except for different inlet order

@seb-harmonik.ar Oh I see, you're right. I missed that you would feed the additive term to the left inlet. Duh.

@adtubu I think there might be an issue with [metro 1] in your patch because it occasionally bangs twice between audio blocks. (background: control rate computations take place between audio blocks) Take a look at this test:
metro block aligned.pd

If you click on the toggle twice, you will see that you generate more bangs than you would expect in that time period--approx 1.45 times as many, which happens to be the number of milliseconds in a 64 sample block. If you change the tempo to 64 samples or to 1.45125 msecs, then the number of bangs you get exceeds the number of blocks by 1, which makes sense to me because [metro] bangs as soon as you start it. So you are driving your recursion at a faster rate than you probably intended, and that rate is inconsistent.

@seb-harmonik.ar thanks, I will try it with [rpole~], looks like it should work.

@james yes the [lop~] doesn't work that well, but if I can run it at audio rate it might be less of an issue. And I understand what you're saying about [metro 1], it should be a multiple of the block length. If [rpole~] doesn't work well I'll look into that.

Thanks for all the useful tips!