Delay / h-phase issues

Forum Modular Systems
1

Hi,

Wasn’t quite sure where to post this. It’s not a technical problem per se, but more of a design concern.

Long ago I resigned myself to the inevitability of delay / horizontal offset in a modular system. I’m just going to lose ~5% of my picture. That evil bar on the left side of the screen is always going to be there. I’m going to have to scale the footage up in post. But that’s not the end of the world. Especially in high definition, there won’t be any scaling artifacts. And I grew up with overscan CRTs and masked projections, so I’m used to some amount of acceptable loss around the edges.

But now I’ve entered the amazing world of separating luminance and chroma via Swatch, and processing them separately. AAAAANNNDDD… now the luminance and chroma are being delayed by different amounts. So they’re not lining up when they get re-combined.

This can also be dealt with in post, but since editing programs are not set up for this, it’s a PITA and will seriously complicate the whole process. I.e., now suddenly we need four layers in the timeline instead of one.

So, I’m wondering if this could be solved with some kind of adjustable delay line module. Just 4HP, three in, three out, and a delay knob. I guess since Gen3 has a minimum of 8HP for the power board, a Gen3 delay line would have to be a dual module.

And related to that, would it be possible for future encoders to have an h-phase adjustment? If I understand the problem correctly, it would need to internally delay the sync to line up with the incoming delayed picture. The component / composite signal coming out of the encoder would be delayed relative to the sync it’s receiving, but the sync loopthrough to other modules would NOT be delayed.

Are these ideas practical?

Thanks

2

A delay line module is something we’ve discussed in the past – a voltage controlled or manually controlled solution would be very difficult, but fixed delay taps is more achievable. Something like an RGB delay line with 3x1 ins and 3x6 outs, each delayed +11ns would be pretty achievable. Or a rotary switch to select tap. General de-noise, AGC, type functions would be interesting to include on a module like this too. A “correctional filter/phaser” (as opposed to one focused on blur/sharpen effects.)

I think a practical solution for now would be introducing negative delay as a feature on TBC2’s outputs. That way you could have a single source coming in, but coming out of RGB on the dual outputs at different phases. So rather than delaying the signal at the encoder by 1% of the frame, you delay it at the decoder/frame sync by 99% of the frame. That way it hits the patch a little early, and arrives at the encoder perfectly in phase. This is not a feature of TBC2 at present, but could be added to the development roadmap.

Design philosophy wise, I feel like we don’t want to overengineer the solutions too much. The intention behind the designs isn’t to provide a precision image processor – it’s to expose the raw functions that you don’t always have full control over in a device that auto-corrects everything. The fact that IQ goes out of phase with luminance after processing is something very unique to analog video in how it presents on the screen. Of course, that doesn’t mean we can’t have functions like phase/delay taps in the system of course, or correction functions on input decoders – just musing on the topic in general.

6 Likes
3

Thanks @creatorlars. From my perspective, the level of “overengineering” is dependent on the module function. I get that analog is messy. I get that this is a creative pursuit and we shouldn’t expect military grade precision at these price points. But encoders and decoders should be at the top echelon of specs and technical capabilities. Everything else is dependent on how good the signal is coming out of, and going into, the modular system.

For an encoder, my top priority is that the signal coming out of it is as clean as possible, with no loss, whether that be bandwidth or picture information. So e.g. with ESG3, I understand the reasoning behind the handy controls for contrast, brightness, invert, and mute. The encoder is doing multiple duty as an image processor. It’s especially helpful in small and/or portable systems, for artists just getting started in the medium, and people on a tight budget. That’s all great, and I’ve put those value-added features to good use. But frankly, I would sacrifice all of that to have an H-phase control.

I think a 3 in / 3 out delay line with a rotary switch to select fixed delays would be plenty good enough for me. An 8 HP dual module like that would solve the problems I am encountering. Maybe someone would want to mix and match delays, e.g. delay individual signals rather than dual / triple signals, but I haven’t envisioned that use case yet. For my purposes, I would prefer a rotary switch rather than a module bristling with jacks. Sure, you can eliminate the cable mess with internal normalling. But then you’ve got wasted HP space.

I neglected to mention that I had already considered the TBC2 workaround for the chroma offset issue I’m currently experiencing. Based on some Facebook post you made a long time ago, it looked like you were translating and scaling the picture around via MIDI. And based on Johnny Woods’s video, it looked like we could map the same physical input to each of the two “encoders”. Those two features in combination would give us the power to introduce different horizontal offsets to each of the TBC2 outputs.

But needless to say, a negative delay would be way better. It would solve both problems… the delay introduced by any and all modules, and the differential delays caused by split-signal patching, e.g. Y vs. I&Q.

The fact that TBC2 is a programmable digital computer opens up so many incredible possibilities. Here I was thinking “TBC2 is a switcher, someday it may be smart enough to do everything, including upstream and downstream keying”. But this example shows that there are more things in heaven and earth than dreamt of in my philosophy.

Thanks as always!!!

1 Like
4

Agreed, and I like a switched approach. If you were to purchase a video delay line box for broadcast, it would usually have a rotary switch to select the output tap. The real question is what time constants to target as far as ranges.

It is worth mentioning that Swatch has been very carefully designed to output YIQ signals that are all in phase with each other at all IO points (there are some extra buffer opamps where necessary thru the summing stages). So no X factor to account for there.

From my perspective, the level of “overengineering” is dependent on the module function.

Agreed, and that’s my point really – some things can be approached at a systems level. That’s the beauty of a modular system after all. A delay line module is something that solves a specific problem – but if we built adjustable delay lines into all module outputs, it would be a bloated cost – since the feature is not as relevant (or maybe even undesirable) in the case of abstract generative art, or the artist wanting to purposefully impart analog chroma phase issues into the signal as an effect.

2 Likes
5

Yeah! Swatch is amazing. I knew all along that the delay I was seeing was due to how the signals were being processed by other modules. Not an issue with Swatch I/O. Verfied this by bypassing the individual internal normals with patch cables. Flawless.

2 Likes