@porres Yeah, this thread is definitely hard to follow, but please don't feel any pressure to follow it. The subject I introduced was already way down in the weeds and each respondant (you included) brought their own focus, interests, and experience to the table. The result is more like cool party banter than a research paper. Plus, my interest in it turned purely academic after I found a solution to my practical problem (i.e. delay everything else using [vline~] so its timing is aligned), and so if any speculation that followed seems impractical, well, yeah, that's how academic things are sometimes. Personally, I think it's fun, but I get that many people don't, which is why I issued my warning at the end of post 12.

Speaking only for myself, I'm just wondering if there's an alternative to the way I aligned the start of my [vline~] audio processing with my other audio processing that can't do inter-block timing. @lacuna, @seb-harmonik.ar and I found one way, and I'm still looking for a way to do that same thing one block earlier, which I suspect doesn't exist without resorting to externals. I think your and @seb-harmonik.ar's [line~] suggestion requires that every segment of the piecewise linear function align with block boundaries, am I wrong? If that's good enough for most purposes, then that was worth noting and I'm glad it was suggested, but it's more restrictive than I required.

Yeah, [line~] does start and end ramps at the boundaries of blocks. Why is that not good for you? What is your use case? What do you want to achieve in a patch? Is it all just something you wonder if it can be done or not for academic reasons?

@porres Yes, my curiosity is entirely academic. I solved my problem by leaving the existing [vline~] as is and converting the other block-aligned processing to use [vline~] (somewhat trivially) in order to synchronize things. Rereading the [vline~] documentation, I found a discussion of [sig~] which suggests that my solution is not entirely unreasonable. Here's my patch--not that it's relevant to my questions, but you seem curious:

The adaptation is in the random volume for each envelope trigger.

I am indeed curious, but must of all of what you are exactly trying to achieve in a real world example. I have no idea what to make of your patch.

@porres Thanks for your interest! This is an envelope generator that is trying to copy and improve on an effect I used in a piece way back in the '90s. It was originally done with a Valley People Gatex, which I'm about to give away to the friend who turned me on to them. Anyway, if I set the Gatex to 0.2s release time, a 60dB range, and then ride the threshold to constantly trigger on an external key (for which I usually used speech so it would be fast and unpredictable), I'd get a pleasing chattering sound with a consistent soft click on the attack. Even though the release is so short, the triggers are coming awfully fast so the gate is retriggering before it has had a chance to fully close.

I made some recordings of the Gatex and tried to measure what it was doing, but as these things often go, I found that the Pd simulation sounded more true to the original with parameters that didn't quite match what I had measured. The release curve I'm using is much steeper at the beginning, release time much longer, and the attack curve is longer and logarithmic. I kept the 20ms sustain time as is. I found that if I retriggered the same [vline~] before it had had a chance to fully release, it would either pop too much (if I made it jump to 0 first), or had inconsistent attacks (if the new attack didn't start from 0), so that's why there's two of them computing the ramps and hold. I'm outputting whichever one is higher at any given moment. When a new trigger comes in, I look to see which EG is lower (and thus not seen on the output) and route the new trigger to it. It first jumps to 0, but you don't hear it click because I'm outputting the other one at that instant.

To control the curvature of the attack and release, I use [vline~] again to synchronize the values used to shape the attack and release via [pow~]. Finally, I noticed that the Gatex had a unpredictable amplitude variation, probably based on the key signal at the moment the trigger was detected. That's what the randomized volume stuff is for, although the Gatex's actual variation is only 3 dB, if that. I'm not trying to copy their detection algorithm because for my music there's usually been no correlation between the main channel and the side chain, so I just use randomized [delay]s to trigger it, which is how my troubles began. Without the intervening [vline~], the unsynchronized random volume part added unpredictable discontinuities, especially when the trigger density was high.

Here's some sound: jittery gate demo.mp3