As an alternative to [lop~] in method #1 you could also use [slop~] ... just came to my mind.
Edit: Hm, I don't know ... But you should definately try a higher-order filter like [butterworth3~] in the Pd audio examples! It will do a much better job removing high frequencies.

@MarcoDonnarumma Sorry, I should have explained ... So the "samplerate" should be that of the incoming data, 500 Hz or whatever it might be. And [tabread4~] will then convert to Pd's standard samplerate. Maybe there is even a way to drop the metro and use the incoming data as a clock, but I'm not sure if this can possibly work without timestamp. Good luck and thanks for sharing your efforts with us!

As far as I know, [sig~] only changes at block boundaries, so it's not really useful for converting fast changing numbers to a signal. You could use [vline~] instead, but I think @jameslo's array solution is probably more suitable anyway. Here's how it can be used in "real time", that is with a min. delay of 2/"SR" for 4-point interpolation (in your case 4 ms). upsampling.pd

@jameslo That's quite an issue here, indeed! I think, it could be fixed by putting the wrap~ into the loop (which is, of course, a bit more expensive).
@whale-av Hm, I guess it can somehow. The way I tried might not be the most elegant and I'm not sure if the phases remain in sync over time ... (probably not)
So here is another try: phasor-unwrap2.pd

Isn't phasor~ itself simply a wrapped line? So what about unwrapping it? phasor-unwrap.pd

@teakaytee Sorry, I can't open your patch ... But I guess you just have to do exponential instead of linear scaling. Maybe something like this: delay.pd

While we're at it: Can anyone explain the "ampcorrect" of vcf~ which, according to the source code, is 2-2/(q+2)? Maybe this is related to the original topic, because it means that what I incorrectly called the "sum" of real and imaginary output is limited to 2 (instead of the real output gain being limited to 1, which it actually isn't).

@jameslo said:

Edit: hmm, but it also looks like your fft~/rifft~ scheme also fails on this example. Is it also broken, or is my reasoning broken?

Well, I wouldn't be too surprised if both of my attempts turn out to fail ...

@seb-harmonik.ar Thanks! Yes, I'm aware of this technique "partial fractions", and there is nothing wrong with [vcf~], of course!
It's just that in some cases the conjugate poles have quite undesirable effects (especially at low frequencies), and so I wondered if there are useful alternatives to the common pairing of poles an zeros ...

I just found an easier way to do it: Just make a (relative) 90 degree phase shift between the real and imaginary parts and add them! For better understanding I use the original [hilbert~] object instead of building a new one out of its two biquad filter sections. vcf-test2.pd