Read-only archive snapshot (as of 2026-06-03). The live forum is closed. For current support, see https://lzxindustries.net/.

LZX Community Archive

All topics · Categories

Using ESG3, TBC2, or Chromagnon in HD sync modes: Compatibility with earlier LZX modules and instruments

Category: Forum · Tags: chromagnon, esg3, gen3, hd, tbc2 · Posts: 62

#1 — creatorlars · 2022-08-25

Here are some guidelines for using ESG3, TBC2, and Chromagnon with earlier generations of LZX modules and instruments:

Here is a list of HD compatibility rules of thumb, in the absence of a more detailed compatibility chart:

General advice for system building:

I would love to answer any questions.

#2 — joem · 2022-08-25

+1 for a compatibility chart! I think it should be kind of like an emulator compatibility chart… not just “works/doesn’t-work”, but something like “perfect/good/poor/doesn’t-work”, with notes for any status other than “perfect” if necessary. Although I guess it gets a little complicated since there’s so many modes in the gen3 gear, maybe? I guess the notes part might need to be dropped.

@creatorlars Is this a good thread for people to comment about their experiences? Or do you want to keep this thread to a Q&A kind of vibe?

#3 — creatorlars · 2022-08-25

joem wrote:

Is this a good thread for people to comment about their experiences? Or do you want to keep this thread to a Q&A kind of vibe?

Discussion is great! The purpose of this post: make it easy for other community members to gain access to community knowledge on this subject.

Regarding data structure for a compatibility matrix, it is kind of tricky. Given the number of formats you could test in, and the number of modules, and the obvious benefit of logging notes from multiple user reports in any of these cases, the data is like a cube – and that’s not easy to represent in a single table. Maybe there’s a better way.

We could use the forum’s tagging system, and then perhaps provide an index and “ratings chart” in this thread or one like it. For example, all posts tagged “Navigator” and “Gen3” is a good indication of user reports on Navigator’s compatibility with Gen3’s HD modes. This makes the forum’s search functions more powerful.

#4 — mauiey · 2022-08-25

Although this is a topic about formats, I think power would be a useful dimension especially for the system building topic.

When building a 2x84HP or bigger system, with mostly but not exclusively Gen3, it seems difficult to get around having 2 types of power supplies (a bus board and a DC distro or cheaper alternative). In that case the potential of Gen3 offering a more affordable power solution seems lost. Especially if we don’t want to introduce any noise form cheap power supplies meant to power only a couple of non-Gen3 (/non-LZX) powered modules.

Curious what you recommend or how others are planning to do this.

#5 — Marizu · 2022-08-25

I’ve just added a DC Distro to the PSU2/PSU3 cases that I’ve been using. I’m committed to a mixed case for a while because I love the vibrance of the DIY scene and the legacy modules are all fairly distinct from their Gen3 replacements.

#6 — creatorlars · 2022-08-25

mauiey wrote:

Curious what you recommend or how others are planning to do this.

I would either have 2 separate cases (one DC Distro, one EuroRack), or a rack case with multiple rows (some rows EuroRack, some rows DC Distro), or if a single combined case was a must, I’d install a EuroRack power supply/busboard with enough 12V DC current to supply both EuroRack and Gen3 modules. It’s also a question of proportions. If you’re just putting a couple of Gen3 modules in your existing case, powering them from the EuroRack shouldn’t be a problem in most cases.

Cheaper input power supplies is only one reason for the Gen3 power distribution scheme, that’s only part of the puzzle. Some of the modules are massive analogue circuits, and just require more power in general. Making them possible as low HP modules is quite a task, and so I don’t think there are any off the shelf EuroRack supplies that could handle an all Gen3 system.

#7 — wednesdayayay · 2022-08-25

will the LZX euro power supply be coming back at any point?

I’ve got one of the LZX power supplies a 5a dc distro for the big modules and a 3a dc distro for a row of regular gen 3 plus a 4ms black row power that I’ve used for a long time but is kind of noisy. So I think I should be set for the moment to get things rolling again.

the skirting and stairs on our new house should be finished by tomorrow so we should be moving in in the next couple weeks! Then once things are moved in I can start setting the dedicated space up again. I’m so pumped to start streaming with a system again. I should be getting a package from LZX today with a bunch of good stuff.

#8 — creatorlars · 2022-08-25

wednesdayayay wrote:

will the LZX euro power supply be coming back at any point?

We could do a combined EuroRack and DC distribution busboard at some point, likely when we offer a new version of Vessel or a new case. But it would be a higher priced variant than the base option, which would be DC distribution only. It would be very good to hear everyone’s thoughts, complaints, desires, etc for all of these solutions as you confront integrated setups. What percentage of a system is going to be Gen3 vs earlier generations of modules, for example? If it’s 90% Gen3, a couple old modules, that could be annoying. If it’s 90% old modules, a couple Gen3 modules, then most Euro supplies should be fine. If a new busboard design (Euro + DC) is something that solves a lot of folks issues in the short term, we could prioritize that.

We’ve tried to engineer a low impact solution that solves basic Euro power vs Video modules issues that have been around ever since the introduction of non linear power supplies and shallow skiff cases into the EuroRack landscape (something that happened in early 2010s, between Visionary and Expedition series.) Even with linear supplies, distributed +/-12V always proved a big problem for us, since any modern (past few decades!) video parts run off of +/-5V.

So high power, ultra low noise, miniature-scale form factor – it’s a tall order! There are of course going to be some integration road bumps – our hope is that our solution is a balanced one, that allows the growth of the format and systems, while still allowing integrated systems rather than ditching EuroRack power entirely.

#9 — cinema.av · 2022-08-25

changing from PAL to 1080i60.

esg as master sync to cortex.

image

https://www.youtube.com/watch?v=EjfUiTpCntA

#10 — creatorlars · 2022-08-25

That all looks as expected. Visual Cortex does not support 1080i60 modes (it runs in NTSC or PAL only).

#11 — creatorlars · 2022-08-25

mauiey wrote:

Especially if we don’t want to introduce any noise form cheap power supplies meant to power only a couple of non-Gen3 (/non-LZX) powered modules.

More on this point. I don’t think you’ll suffer a decrease to any existing EuroRack power supply performance when using distributed DC 12V in the same case as EuroRack modules. The DC 12V entry never touches the analog signal path – that’s all being powered from the rear power entry board on the LZX modules. On that board is a big EMI filter right at the input, and a power supply topology that produces very low noise +/-5V rails (and those are what power the IO and the rest of the signal path.)

If you are seeing some kind of noise like that with DC distribution, make sure you are using shielded jumper cables and that all modules are secured to the case with mounting screws. If you’re still seeing some kind of noise, give us all the details on your setup so we can try to recreate the issue in the lab.

#12 — mauiey · 2022-08-26

What I mean is, if next to a couple of Gen3 + DC Distro (or other supply) modules, you also have a non-Gen3 module that is powered by a different very noisy power supply. Maybe I’m misunderstanding but if that noise has entered the patch via one dirty power supply, it will not be filtered by the Gen3 modules anymore, right? Or do all signals you patch go through those EMI filters?

#13 — creatorlars · 2022-08-26

mauiey wrote:

Maybe I’m misunderstanding but if that noise has entered the patch via one dirty power supply, it will not be filtered by the Gen3 modules anymore, right?

Ah okay, I get you now. And yes, that’s correct. You can’t expect the Gen3 modules to remove any noise from other modules. So it’s best that you always use a lower noise EuroRack power supply, same as it’s always been, to get the best performance out of EuroRack powered modules.

#14 — joem · 2022-08-27

Has anyone used Castle modules in HD workflows? I’m curious how those do.

#15 — meudiademorte · 2022-08-28

Used caste adc and dac. They work as expected with some rough edges

#16 — DaydreamDevices · 2022-08-28

susynct - thank you for a needed boost of confidence in the upcoming merger

#17 — rempesm · 2022-08-28

There’s no inherent reason the Castle modules, apart from Castle Clock VCO, won’t function correctly in HD timings.

Castle Clock VCO expects H/V sync on the CV/Gate power connector which is a deprecated standard in Gen3.

To get H/V sync into the Clock VCO, simply take a H or V ramp from DSG’s SUM output (use a dummy cable to disable the other ramp), sum it with an adjustable bias (Passage, Proc, Fox Access, etc.) and plug it into the front panel’s Sync input. Same principle applies for syncing any oscillator that doesn’t have an RCA connector. Cadet IX may be modified for a front panel sync input.

You can use the same H/V ramp + offset approach for any of the other Castle modules with Clock or Reset inputs that can benefit from being locked to H/V pulses.

#18 — sean · 2022-08-28

/forum/t/319/#post-67

I am hoping this is still the case, however.

#19 — creatorlars · 2022-08-28

sean wrote:

I am hoping this is still the case, however.

Yes, HV sync outs are available on TBC2, same as Cortex. (The 2-position DIP switch enables HV sync to the CV/Gate bus on the EuroRack power header.)

#20 — nerdware · 2022-08-28

Very good. That solves a sync problem that’s been bugging me. Thanks.

#21 — dryodryo · 2022-08-28

creatorlars wrote:

Yes, HV sync outs are available on TBC2, same as Cortex.

By this I guess you mean composite sync is available on the power bus, for compatibility with legacy video modules. TBC2 does not currently provide separate H or V sync outputs either at the front or rear panel, right?

As I mentioned previously, it would be super sweet to have vertical sync available as a patchable signal, for purposes of vertical interval switching, oscillator and envelope triggering, and full frame/field sample and hold. I’ve made this work with Syntonie video sync’d oscillators, and it’s awesome. But it would be even better if I didn’t have to tie up an entire oscillator and comparator just to provide vertical sync to a sample/hold trigger input.

Which also brings up the question, what is the square wave input on the front of TBC2?

Thanks!

#22 — nerdware · 2022-08-28

“HV sync over power bus” refers to the older sync system used for the Gen1 oscillators and early Prismatic Rays.

#23 — creatorlars · 2022-08-28

dryodryo wrote:

Which also brings up the question, what is the square wave input on the front of TBC2?

Assignable trigger function input, like Memory Palace.

By this I guess you mean composite sync is available on the power bus, for compatibility with legacy video modules. TBC2 does not currently provide separate H or V sync outputs either at the front or rear panel, right?

Correct. There are no 3.5mm patchable syncs on the front or rear of TBC2.

dryodryo wrote:

As I mentioned previously, it would be super sweet to have vertical sync available as a patchable signal,

There’s an HV ref / sync generator module coming, which will have discrete sync outputs and HV reference ramps. Unlike previous generations, a module like this isn’t required for every system, since modules like ESG3 can also function as a standalone sync generator.

#24 — dryodryo · 2022-08-28

creatorlars wrote:

There’s an HV ref / sync generator module coming, which will have discrete sync outputs and HV reference ramps.

That’s awesome… but I’m out of rack space.

:slight_smile:

Any chance you’d be willing to make Vsync available from TBC2 Y output via a firmware update?

Thanks!

#25 — creatorlars · 2022-08-28

dryodryo wrote:

Any chance you’d be willing to make Vsync available from TBC2 Y output via a firmware update?

The Y output is an analog sum of the RGB outputs, so addressing it individually won’t be possible. It is possible from the RGB outputs, by purposely misaligning the start of active video with the start of the sync interval. So it could be in a list of things to consider in a future firmware version, but beyond the scope of the initial release. You can get creative by syncing things off of the image loader in the meantime though. Just make a still image with the top scanline white and the rest black, and that will create a vertical reset pulse. If you do this with Red line on top, Blue line on left, then you will have some usable HV syncs out of R and B jacks.

#26 — nerdware · 2022-08-29

creatorlars wrote:

There’s an HV ref / sync generator module coming, which will have discrete sync outputs and HV reference ramps.

Will this module also output the HV sync signals through the power bus? That would be wonderful.

#27 — creatorlars · 2022-08-29

No, not unless we included an extra/secondary Euro power header (maybe there is room.) We took a lot of care for the Euro header to only touch the internal circuit thru its 12V connection, which goes thru the EMI filter. A buffered output coming from the core board (on a separate Euro connector) might be possible. A module that is specifically a legacy sync adapter might be the right answer, for that and 14-pin sync.

#28 — dryodryo · 2022-08-29

creatorlars wrote:

You can get creative by syncing things off of the image loader in the meantime though. Just make a still image with the top scanline white and the rest black, and that will create a vertical reset pulse. If you do this with Red line on top, Blue line on left, then you will have some usable HV syncs out of R and B jacks.

ZOMG you just blew my mind. That is so clever. Too bad it ties up a whole TBC channel. With a Chromagnon and a Syntonie decoder I should be fine, though.

But the headline here is actually “RGB channels carry arbitrary information”. In the digital graphics world we use channel packed textures all the time, carrying arbitrary parameters such as roughness and metalness in stacked channels in RGB files e.g. PNG. Now I’m realizing that can be applied here.

In combination with other tools e.g. Color Wheel we can do some really creative stuff with channel mapping, color space conversion, color correction etc.

I’d love to try processing footage in hardware or software to convert to and from YUV and HSV. Maybe there is a way to make the decoder outputs and/or encoder inputs handle YUV.

Exciting stuff!

#29 — mauiey · 2022-08-29

Is there a limit to how many modules you can sync with one sync generator? Could you build a huge wall of DSG3’s synced to one ESG3?

#30 — creatorlars · 2022-08-29

Is there a limit to how many modules you can sync with one sync generator?

No limit… in Gen3 every sync node is buffered, so the transmission lines between modules should perform identically no matter how many modules are in the chain. No more loop thru weirdness woes.

Could you build a huge wall of DSG3’s synced to one ESG3?

Yep! During testing, I had 5x DSG3s and 5x ESG3s all synchronized at the same time.

#31 — creatorlars · 2022-08-29

dryodryo wrote:

But the headline here is actually “RGB channels carry arbitrary information”. In the digital graphics world we use channel packed textures all the time, carrying arbitrary parameters such as roughness and metalness in stacked channels in RGB files e.g. PNG. Now I’m realizing that can be applied here.

Yes! Once it’s a voltage in sync with the video frame, the sky’s the limit. You could encode not just sync pulses for oscillators, but different sync patterns in an image. So “image loader” seems like a mundane feature at first glance, but in our context, it’s wildly powerful.

#32 — dryodryo · 2022-08-29

Yeah, we could for example make a still image that has H and V ramps plus a wipe gradient, each in a separate color channel!

#33 — Rik_bS · 2022-08-30

much like what is covered here LZX Video Synth Techniques: Gradients - YouTube

:upside_down_face:

#35 — gliss · 2022-10-19

I was hoping to jump into the HD arena as well but have mostly Cadets and a Vidiot. I know the Vidiot is a beast that will forever roam SD land, but I was looking at the schematics for Cadet IX and Cadet IV to see whether it would be possible to cobble some HD into them or if my system would need a total upgrade.

On Cadet IV, C18 and C29 could probably be swapped out for something smaller to generate the appropriately sized ramps, yes?

I think Cadet IX should be okay (unless the timing cap here is also too large), but perhaps the op-amps on the exponential converter would need to change over to something faster for HD FM inputs? I remember LM6172 not being recommended in place of the TL072s in this case – there was a better suggestion earlier in the forum I can’t recall off the top of my head.

Forgive me if this has been answered already elsewhere or if I’m barking up the wrong tree!

#36 — Fox · 2022-10-20

gliss wrote:

On Cadet IV, C18 and C29 could probably be swapped out for something smaller to generate the appropriately sized ramps, yes?

That should work, but you may run into an issue finding perfect cap values to replace them with.

Let me run a simulation real quick… (time passes)

This is directly from the Cadet IV’s schematic (The H-rate section). The trimmer (R1) is for adjusting the ramp’s peak to exactly 1V.

image

If I change the sync rate from 15.734KHz to … 33.75kHz, then a cap of about 22nF to 24nF results in close to a 1V peak. 24nF is about the highest you should use since the tolerance of any given ceramic cap might be 10- or 20% higher.

image

image

Tayda has 18nF and 22nF ceramic caps, so it should be easy to find one that fits. The trimmer, R1, should let you trim it to 1.0V even if you’re use the 18nF cap.

Changing the cap is the easy part. Getting the HD sync pulses on a 14-pin ribbon cable will be more difficult. @joem may be working on this though.

gliss wrote:

I think Cadet IX should be okay (unless the timing cap here is also too large),

The timing cap will still work. You will just be limited by fewer bars. Changing the cap with the ratio we used above should get you fixed up.

EDIT:

I corrected the H-rate pulse width in my simulation to 525nS as listed in the LMH1980 datasheet. This changed the perfect cap value closer to 27nF. 18nF should still work since the R1 trimmer allows for such a wide range of attenuation.

image

#37 — joem · 2022-10-20

Fox wrote:

Changing the cap is the easy part. Getting the HD sync pulses on a 14-pin ribbon cable will be more difficult. > @joem> may be > working on this> though.

Indeed I am.

:slight_smile:

I’ll update in that thread sometime soonish hopefully when I have some more progress.

#38 — gliss · 2022-10-20

That’s amazing, thank you very much @Fox!

And yes, I was/am indeed watching @joem’s project intently

:slight_smile:

#39 — Fox · 2022-10-21

:+1:

For the record, I found the LMH1980 datasheet to list tHSOUT for an HD, H-sync pulse width as 525nS, not 4.7uS as I had originally simulated. The best cap value is now 27nF. 18nF will still work since the R1 trimmer allows for such a large range of attenuation.

#40 — creatorlars · 2022-10-22

That 525ns is the propagation delay to expect between input and the logic outputs in the SD input modes of the LMH1980. This equates to exactly 10 clock periods of the 27 MHz pixel clock. (That’s what I have programmed as the correction factor in ESG3 firmware.) The actual HSYNC period for HD is about half of the period for SD.

A good way to do the 14 pin sync adapter would be with an embedded fpga sync generator to generate the pulses and genlock to an external source. So it could be implemented with the plugin syncgen boards from the ESG3 or the VU007B I reckon.

LMH1980 generates both HSYNC and VSYNC, and auto-detects between SD and HD, so it’s a good option if you want to integrate sync separator directly into each module.

#41 — Fox · 2022-10-22

Ah-hah. Thanks for pointing that out. 525nS sounded a bit too short, but I am still reading about the finer details of HD sync.

I am still a little confused with the LMH1980 datasheet. tdHSOUT is listed as the 60nS propagation delay and tHSOUT as the 525nS pulse output.

When considering a ramp, should the falling edge of CSOUT trigger the shorting of the cap and the rising edge of the BPOUT begin the charging phase? I was only worried about HSOUT, but tri-level sync is different than SD.

image

image

#42 — creatorlars · 2022-10-22

You’re right on the timing details! I was mixed up on the SD vs HD timings in my head. 525nS is right.

For ESG3, we have the HD pulse width set to 44 cycles of the 74.25MHz or 74.176MHz reference clocks, so ~590ns.

Fox wrote:

When considering a ramp, should the falling edge of CSOUT trigger the shorting of the cap and the rising edge of the BPOUT begin the charging phase? I was only worried about HSOUT, but tri-level sync is different than SD.

That becomes very tricky – the right answer is that you start the ramp on pixel #1 when the AVID region goes high – and that timing is variable per video format. So it’s not something you can get a precise reference for from the LMH1980 alone – you’d need to tune the ramp start phase per format to get it perfect (maybe adjustable monostable delay of HSync with a trimmer?) Easier to base this on a sync generator/FPGA that is responsible for all of the timing. This is ultimately why we didn’t go with an analog PLL based ramp generator for DSG3 – we had an “auto calibrating” ramp circuit working beautifully, but the blanking periods would have had to be manually adjusted.

That said, all you need for a “working” ramp generator is a stable hsync reset – it doesn’t have to start exactly in the right spot to be patchable!

#43 — ToppoWass · 2023-07-21

Hello everybody!

I’d like to connect Vidiot mini jack outputs on the panel (i.e. the diamond output) as video source for ESG3. I set the format switch to PAL.

However, the diamond shape image is not synced and it is scrolling left to right.

How to stabilize it?

thanx! : )

#44 — Agawell · 2023-07-21

I don’t have either - but, you’d need to connect sync out from esg3 to a sync in on the vidiot

#45 — ToppoWass · 2023-07-21

As far as I know there’s no sync in in the Vidiot…am I wrong?

#46 — Agawell · 2023-07-21

I checked the manual - you could try the horizontal sync input - page 7/8 of the manual item 18 - worth a try at least

or see page 13!

#47 — Vdot · 2023-07-21

I believe you can send the sync from the back of the ESG to the camera input of the Vidiot.

Or you can send the the Vidiot’s video output (or maybe the Eye output?) to the sync input on the back of the ESG.

Or if you have something connected to the Vidiot’s camera input, you can send the camera output to the ESG.

You’ll have to set the ESG to generate or receive sync accordingly.

#48 — ToppoWass · 2023-07-21

Thank you it works by VIDIOT camera output to ESG3 sync input!

#49 — Vdot · 2023-07-21

That’s how I sync my system

:slight_smile:

#50 — Z0NK0UT · 2023-07-24

If you are using ESG3’s component output for monitoring, you can also send it’s composite output to Vidiot’s composite input for sync. That also gives you an optional feedback output from Vidiot, if you want it.

#51 — Strutter · 2024-01-24

Would using the ESG3 as an output module for Rutt-Etra type stuff make any difference/sense?

I mean using the HQ mode.

Just ordered one in order to get better quality video out from my setup and haven’t looked into the other possible benefits and use cases yet.

It’s been a while, hello everyone!!

:slight_smile:

#52 — Z0NK0UT · 2024-01-24

Welcome back! Are you using any older LZX modules in your vector rescanning patches and want to work ESG3 into the mix?

#53 — Strutter · 2024-01-24

Thanks!!

Yes. I’ve got the usual suspects: VC, Passage, Nav and Shapechanger.

#54 — Z0NK0UT · 2024-01-25

If you are using Visual Cortex as part of your patch, you will be limited to NTSC/PAL when syncing your ESG3. I don’t think you would see any change in your vector rescan workflow by adding ESG3.

#55 — Strutter · 2024-01-25

That makes sense. Thanks!

:slight_smile:

Actually I do have the TBC2 so by using that the only thing coming from the VC would be the ramps.

#56 — Z0NK0UT · 2024-01-25

Well the ramps are synced, so anything out of the Cortex is still limited to NTSC/PAL. However…TBC2 makes its own ramps, so you would have an HD ramp source there. TBC2 can replace Cortex in your rescan patches.

#57 — Strutter · 2024-01-26

I will definitely give this a try.

It would be interesting to hear from someone who has done this with the new modules as of how noticeable the difference is.

#58 — dryodryo · 2024-01-27

TBC2 is good for HD ramps, I have tested this in a vector scan processing workflow.

If you care about the cleanest possible ramps, with no crosstalk, follow this procedure. Crosstalk between ramps will manifest as skewing of the raster, it won’t be perfectly rectangular.

Use one channel of TBC2 for the video image, if any.

Set up the other channel of TBC2 to output ramps. One of them on the Red output, the other on the Blue output. Turn the Green output off entirely… disabled.

But you know what, I got more control by using DWO3 or VU009 sawtooths to generate ramps. If you’re not able to get a single sawtooth cycle out of DWO3, send a static voltage (e.g. Matte) into the CV input and set the attenuverter to negative. This will slow down the oscillator more than you can by just turning the frequency down all the way.

#59 — complaintdept · 2024-01-28

I was wondering about HD vs SD ramps within the context of vector rescanning and lo and behold, it’s actively being discussed here. I’m considering buying a TBC2 for many reasons, one being the ramps.

Right now I use both VC and Diver as ramp generators. Doing a lot of rutt etra type stuff with external video/images, but also stuff without external inputs (shapes, patterns etc generated within the system). I don’t want to change my workflow for the rescanning portion (I’d like to keep what I’m filming off the X-Y displays as SD, so I can process the rescan video with all of the normal SD LZX modules, rest of my projects are in SD as well) but if I could increase the resolution of the ramps in my vector patching (using ramps from TBC2), I’m assuming I’d get a lot more detail within whats displayed on the vector screen itself… am I understanding that correctly? Almost as if the “fabric” that is the ramps is larger, or to put it another way, if the gain wasn’t adjusted on the display the ramps themselves would be much larger.

I use navigator pretty early in the chain in nearly every vector patch, would still work to rotate the TBC2 ramps? It’d need to be synced to TBC2?

Very basic example of what I’m envisioning:

TBC2 (Set to an HD resolution)

Encoder A- R (h ramp) G (v ramp) B (n/a) (as described by dryodryo above)

Encoder B- media loader high def sized image

Both Encoder A H+V Ramps to Navigator (synced to tbc2?)

Navigator outputs to 2 cadet crossfaders

Encoder B image mixed in to taste for displacement effect

Crossfader output to X-Y display

(And run the Luma from encoder b the TBC2 to the Z input)

X-Y display rescaned by SD camera

Colorized, keyed to taste, etc etc then output by VC

So I guess I’m kinda suggesting an HD path to the XY displays then a seperate SD path for rescanning. In my head it makes sense that there’d be a big difference using these ramps instead, HD video is much larger, but I’m not sure if it translates the way that I think it does.

#60 — jwsmithwick1 · 2024-01-29

You could also use Angles for ramps. NGL, TBC2 ramp randomize function is pretty fun.

#61 — rempesm · 2024-01-29

Your display’s Z axis may not be able to cleanly resolve HD luma as I don’t think I’ve seen a vector monitor that can do over 10MHz on Z. The output impedance of your modules also makes a difference in whether the available details are cleanly output or simply low pass filtered.

If you are rescanning in SD prior to encode/capture, I’m not sure you’ll really be able to tell a difference regardless of how sharp HD ramps/footage appears on the monitor. You’re effectively downscaling at your colorizer/encoder stage with VC.

Post some comparisons if you end up going down this route!

#62 — dryodryo · 2024-02-03

I’m not 100% sure I completely understand all of that, but I can offer a few thoughts. Everything @rempesm said is true, I just want to add a couple points.

Vector monitors with a bandwidth higher than 10 MHz don’t exist, but XYZ oscilloscopes do. I have one that has 30 MHz on the Z axis. But it’s a moot point if the dot size is too large relative to the screen size. That’s the limiting factor for the vector display part of the patch.

HD ramps will give more detail than SD ramps. This is a big aesthetic difference, because SD ramps will more clearly “delineate” the lines of the raster. In my experiments with HD ramps, I’m getting much softer, ethereal, gossamer translucency rather than visible scanlines. The raster is rendering much more as a surface than as a bunch of lines. But this is also dependent on your settings. Suffice to say that an HD ramps setup can achieve some of the characteristic “looks” of an SD setup, but not so much the other way around.

In my experience, the performance of TBC2 as an up/down converter leaves something to be desired. I’m seeing it drop frames all over the place. So in any event, I recommend keeping everything in the system in the same format: camera, decoder, and encoder. As @rempesm points out, the Visual Cortex is the limiting factor here. ESG3 or Chromagnon is what you need if you’re trying to get more detail in the final product.

Also, a genlock setup is preferable to wild sync into TBC2. I’m getting frame tearing. A camera genlocked to TBC2, or a whole system genlocked to the camera via a Syntonie decoder, should solve the frame tearing issue. I guess this might also work by sending a copy of the camera’s composite or Y signal into the TBC2 Sync input? More experimentation is needed.

#63 — b4_H · 2025-07-10

Good Day,

For the record- Chromagnon has NOT shipped right? I’ve moved twice since I Bought it however many years now. 4-5 I take it. It’s hard to keep up. Thanks

Ofield