Hello. I am here after working in a series configuration with FKG3 and noticing a blue discoloration of the both RGB and monochromatic video streams with CBV001. To begin, here is the patch diagram:
So from my experimenting with this, at all settings on the first FKG, the tint is visible. At some settings on the second FKG, tint is visible unless keyed out.
FG mode, inverted, tint appears on all settings.
FG mode, no inversion, MAX threshold, MAX softness, tint appears.
FG mode, outline, HIGH softness, tint appears.
Excluding the CBV001, the blue tint disappears, so this is clearly a result of the way the CBV interacts with monochrome signals. All of my converters have no hue correction applied. Mix is off on cortex. I’ve tried the out of CBV001 direct into the RED of FKG and also buffered into RED, BLUE, GREEN. I’m trying to understand what specifically is causing the tint.
It’s also worth mentioning the out of CBV001 is capable of colorizing when running directly into Visual Cortex as a monochrome signal. I’ve heard before that the way the VC encoder works, it’s not clipping the chrominance introduced into the signal by CBV and similar circuits. But the specific blue tint is most definitely not something I’ve seen before.
I’d like to isolate this issue down to just one module, but it seems like the interactions between Cortex and these types of glitch devices can allow for this to happen. I’m not entirely sure what, if anything, FKG3 is contributing to this.
Use a passage or something similar directly after cbv to offset and attenuate. At what point does the blue tint disappear, if you only offset, if you only attenuate, both?
Could you recreate this with the minimum number of modules and cables possible, and with no modulation present on FKG3?
It looks like the Blue tint is coming from the Blue output of Cortex, right? The Luma out from Cortex isn’t going to carry a blue channel at all, so if there is any blue present in the input signal it’s being stripped out, there.
Simplest possible patch though please, and with all switch positions marked, and we’ll be able to figure it out.
Yes, I can simplify the patch to a single FKG, cortex, and CBV. In the “outline” example, the modulation from castle is the most subtle. I would expect the result to look very similar. I didn’t make an isolated test of the CBV, and I’ve gotten weird colorization from it before on what should be a luma signal, but not the specific blue tint in the examples.
As a side note, I did take test captures with both color video and b&w video, opting to post the results of the b&w because it is not tinting based off the color of the video.
Well in the patch shown, you have RGB from Cortex patched into the keyer as well as the processed Luma output – so you may have your blue offset coming from that output jack on Visual Cortex rather than the CBV0001. What’s the source device? What colorspace are you receiving? Is there a possible RGB vs YPbPr mismatch in settings? (Cortex expects YPbPr sources.) That could explain a consistent color offset from Cortex RGB using a monochrome source.
@creatorlars Source is video out of Resolume, through an Atomos HDMI/SDI Digital to Analog converter, 480i YPbPr. The colorspace conversion is handled by the device and in all other circumstances has no tinting, hue shift, or any color issues. In all my use with it colors are represented as exactly as they are on the digital preview.
I had previously been using Color Chords to composite the RGB of cortex and the processed Luma together, as well as other texture elements.
Here’s a video of a very similar process to the FKG workflow, using Chords as the compositor. Both the RGB and Luma outputs are active in this example.
Let’s take a look at the simplest patch you can make to recreate this. A good photo of the patch is fine if it gets annoying to annotate in the illustration. Capture a screenshot of the RGB outputs when patched directly to your output as well as a screenshot of the FKG3 out. Try to just establish that RGB passthru thru FKG3 looks consistent with direct passthru first, without any other sources connected. Then as a third screenshot, replace the RGB cables with a direct connection between Cortex Luma out and the Red/Luma input jack on FKG3.
I went through meticulously to find the point when the tinting appeared, and only in configurations where CBV and FKG were used was any tint apparent. Here are the rest of the tested configurations. No Diagram for Visual Cortex RGB passthrough
At this point, I think it’s pretty easy to say the FKGs are contributing to the tint, clearly more so on the dual FKG passes. It’s hard to say that I think that the FKGs are solely responsible for the tinting, being that in the pass throughs, no tint is apparent. I’d imagine the reasoning behind this falls in line with something @pbalj mentioned on the discord server. The CBV has both an AC coupled output and is clearly not in-spec with typical LZX modules. I can say from my own uses with it I have had it colorize the final output of Visual Cortex with the sort of typical rainbow noise seen of BPCM and T+ circuit bends.
I’m still perplexed why the discoloration has this specific turquoise tone, being I’ve never seen that through any combination of modules which included the CBV. It’s also worth note that I went and specifically set saturation to 0% on then Atomos D/A converter I’ve used throughout all of the images in this thread, to remove the possibility of the converter tinting the video.
EDIT In the interest of thoroughness I’ve added two more tests and diagrams. Luma signal is buffered to avoid bleed at the input, which is an issue on the composite input, as well as with the predecessor the AVE mod.
Just went through that entire region with the eyedropper tool, surprisingly, more than anything else the green value was highest, with red and blue staying equal within ±3.
Also @7pip I’ve got Kiss the Demons of Rock. They printed some of those in real LSD.
I bet what you’re seeing is subcarrier/high frequency oscillation bleeding through (from CBV) into a composite output. Do you still see the tint if you view Cortex’s Component output instead?
In any case, try simplifying the patch to this and see if you have the same tint. If so, it’s more evidence to confirm the above theory.
So make use of those normalled inputs on FKG3! If the source is mono, you just patch to the red jack and the other colors inherit from it (cascading normalization scheme is shown on frontpanel diagram.)
I’ve got enough time to test it so let me grab some extra cables! Also I did add some extra patch diagrams in which the normalled inputs on FKG3 are distributing Luma from VC to RGB rather than the buff mult.
EDIT In the interest of thoroughness I’ve added two more tests and diagrams. Luma signal is buffered to avoid bleed at the input, which is an issue on the composite input, as well as with the predecessor the AVE mod.
Here are the results of the Component Output test, unfortunately there is no difference. Still using the buff mult here to avoid and bleed from the input of the CBV, over using stack cables. LUMA CBV + FKG Diagram, Component Output
It’s worth noting that it’s normal to get some minor tint on any analog RGB passthru in the system. 1% resistors can stack up to a few points of off difference, which could result in a light tint if you compare the values. So if you were using all this with the need to get perfect color balance, you’d be calibrating your output encoders. But in this current case I don’t know that normal tints are what you are seeing or not – we just need to find where that blue is in the signal path, then measure it, then decide if that’s outside the tolerance ranges we’re shooting for with the circuit. If you can find any possible way to patch it and still see the tint with ramps instead of with the CBV in the signal path, that would help. I don’t have a CBV here for recreating the full issue otherwise.
On the Component outputs, the blue looks less saturated than your previous captures. So that’s a clue. If you could take a shot of CBV passthru using the same Cortex settings that would be good.
After examining this more, my running theory is that the CBV001 output must be far outside the 0-1V input range expected by FKG3, and that this is pushing some of FKG3’s circuits into overdrive. In overdrive, I’d expect any gain differential between channels to show up in a more exaggerated degree. This appears to be happening at the inputs to FKG3 rather than the outputs (since there’s no tint in the foreground.) If you can’t find any native LZX sources (0-1V constrained outputs, DC coupled) that produce the offset error, it would support this theory. I don’t have a way to test for sure until I can see CBV001’s output on a scope.
Another X factor is your 2hp buffered mult. Depending on it’s IO impedance and opamps used, it could be doing something unexepected to the signals. If you can try using an LZX module like Passage or Color Chords to buffer the signal instead, that might be illuminating.
Yes so there’s a couple more tests worth running that I will do tomorrow morning.
Test the config on the second FKG and see if results vary
Use color chords to clip the output of CBV to 0-1v
Use color chords to distribute a monochrome RGB signal to FKG
Use a passive attenuator to scale the voltage
I’m not sure if the buffered mult is offsetting the colors much if any, there very well may be a difference but not one I’ve noticed. I think overall the best consensus is that the CBV output is well out of spec in relation to typical LZX circuits. I definitely agree CBV is causing FKG to tint, not FKG having any tint on its own, because it’s functioning entirely as expected in all other scenarios.
I actually tried this same patch with ramps and found that a 0-1v gradient had no discoloration. For now I’ll have to wait to try CBV with a clipped output, and see if that resolves the issue.
Actually, you can use your second FKG3 as a Black/White level clipping amp (it can do all kinds of tricks like this.)
Patch CBV0001 to EXT KEY LUMA IN. (Note when I am referencing LUMA IN I mean that the luma source is in the red jack, and there’s nothing patched to green or blue jacks.)
Set FKG3 to EXT KEY source.
Set FKG3 to LUMA KEY.
Turn Softness all the way up.
You will effectively be using the overdriven CVB001 to crossfade between Black & White, but only throughout the 0-1V range – creating a clipping circuit. The RGB outs should all be identical mults of your clipped input luma.
So patch one of the RGB outs of clipper FKG3 into the BG input of your initial compositor FKG3.
Will try this first, as well as the other clipping methods. I suspect this thread may solve an issue for anyone using CBV001, CBV002, or Fluxus Duo as a foreground or background element in an FKG patch. I’m not sure if anyone else has had any similar results with the particular combination of modules here but I’m sure, sooner or later, some other users will.
IIRC there was a mention of a GEN3 RGB clipping amp that would hopefully cover a lot of the textures these non-compliant glitch modules have to offer. Still, someone other than may find this thread useful!
That’s right, processing LZX signals with CBV001 is a bit of a hack: 3.5mm jacks in/out are directly connected to the RCA in/out, so the impedances doesn’t match the LZX 100k/499R standard, signal gets AC coupled and the overall gain is little more than x2 without any distorsion involved, which will definitely result in weird behaviour with modules that expects 0-1V.
Waiting for my FKG3 I preordered through Raw Voltage so i can try reproducing the issue, but as suggested before, using a module to clip or attenuate+offset the output of CBV001 to 0-1V should solve this.
Well we’ve finally arrived at not just a solution to the interaction between CBV001 and FKG3, which is great, but also an answer to how and why this interaction happens. I would assume the gain of the RED channel of FKG3 is lower than the BLUE GREEN channels, which is why the tint appeared turquoise, when receiving signals above 1v. I will edit this thread in the future to document which GEN3 modules have similar interactions when receiving signals from CBV001. For now I have two more reference pictures and patch diagrams to show the difference between the normal and clipped CBV001+FKG3 patch. Thanks @creatorlars@pbalj and @syntonie for helping me sort this out.
