@manuels and @Obineg so I tried with opposite signs which was fun waveshaping weardness, but no 90° phase shift.

Hm, strange ... Did you make sure you only changed the signs of the feedback coefficients (first two arguments of biquad~)? I tried that, and it kind of seems to work: hilberto-test.pd

The reason for the opposite signs, as I understand it, is that in Pd the difference equation only uses additions. (Not sure if this is just a matter of taste or maybe a more efficient implementation.)
The topic is also discussed here: https://cycling74.com/forums/converting-pure-data-biquad-coefficients

I think the feedback coefficients in your hilberto~ implementation should have opposite signs (all positive). And yes, the second sideband seems to be a product of the imperfect orthogonality. With a perfect 90° phase relationship it should completely disappear. That's why it's called "single sideband modulation", I guess.

I can't open the video, but what you describe seems to refer to reverberators based on feedback delay networks (FDN). You can find a lot of useful information about this and other techniques in Julius O. Smith's "Physical Audio Signal Processing" book, including references to the original papers by Gerzon and Stautner/Puckette, and there is also a section about different matrices used in FDN reverberators. As for the implementation in Pd: Both rev2~ and rev3~ use Hadamard matrices. So you are guessing exactly right: It's just adding and subtracting/inverting delayed signals, and then normalizing by a factor of 1/sqrt(2) per stage. See also G08.reverb.pd from the audio examples.

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).