This sentence in timer-help helped me find a bug in one of my envelope generators made with [vline~]:

I was wondering why [timer] sometimes returned fractions when set to [tempo 64 samp(--now I know. But hold on--bangs are only processed between audio blocks, so that implies that the bang must carry with it some attribute that indicates its actual timing, one which might be within the next audio block.

Awright, then maybe [vline~], being all sophisticated and stuff, takes a peak at that attribute? Holy smokes, yes it does:

So my mistake was assuming that [vline~] always started at block boundaries, and that made it misaligned with other audio processing that was initiated at block boundaries. How have folks dealt with this? I suppose I could look for a way to use [vline~] to potentially delay the other audio processing. Is there a way to zero out that bang timing attribute, so that the bangs are quantized to block boundaries? Or some other way to force [vline~] to start at the beginning of the next audio block?

Edit: it's not just bangs that have that intra-block timing attribute--you can see in my example that it's preserved through the message that's sent to [vline~]

@jameslo "Even if I run it via a delay with a fractional block time it's the same."

Yes, the same data...... but 1 block later........ vs.pd
In tabwrite~ vs print~ you banged [tabwrite~] also after the delay..... effectively delaying the data and the display.
If you start [tabwrite~] first then you see that the data is written in the next block.
And if you link the top bang to print~ you will see that it is different.
But anyway..... the data write has simply been delayed by one block.

So my premise that [tabread~] collects data from the previous block was wrong in a previous post... of course....!
Because Pd being deterministic stuff only happens after it has been asked for.
David.

@jameslo I just discovered that if you give vline~ negative delay time value it clears the scheduled ramps and immediately jumps to the value

so if you use a negative delay time in a vline~ message it will start at the same time as a sig~ one, at the beginning of the block
it will only work for jumps and not ramps I think, but sig~ only does jumps..
edit: created a pddp issue to add to the docs: https://github.com/pure-data/pddp/issues/267

@seb-harmonik.ar Like this?

It looks like the second ramp (jump in this case) is still timed relative to halfway through the block though.

@jameslo said:

It looks like the second ramp (jump in this case) is still timed relative to halfway through the block though.

yes that one doesn't have negative delay and the first message cleared the queue already so that one gets processed normally
edit: it isn't relative to the start of the block, but if you're trying to sync with block-synced objects that would be an issue regardless

Hi, I'm simply lost with so many messages. Can I ask someone to explain me why not just use [line~] if you want to be bound by block boundaries? That was my suggestion. I mean, what is the use case of trying to make [vline~] behave like [line~]?

And, well, we now also discovered a hidden and obscure feature of negative delay schedule times in [vline~], but they don't seem to account for any real world use case yet and I wonder if it is actually bugged...

@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