Story

I am using a two-hopper redstone clock to make a redstone lamp blink on and off as an indicator. The hopper clock looks like this:

The lamp is supposed to blink on and off at a constant rate to indicate to the user that the item that the lamp represents requires important attention.

Problem

The redstone lamp is expected to have a 50% duty cycle, that is it is on for the same amount of time as it is off. Instead, it stays on for a little longer, like so:

This is not ideal. The redstone lamp should stay on for the exact same amount of time that it spends turned off.

According to the Minecraft Wiki:

A redstone lamp activates instantly, but takes 2 redstone ticks to turn off (4 game ticks, or 0.2 seconds barring lag).

This means that in my case, the redstone lamp has a 75% duty cycle. This makes the indicator look very sloppy and floppy to the end user. A 50% duty cycle will make the lamp indicator more clean and make the user interface seem more professional.

Core question

What is the most compact way to compensate for the redstone lamp deactivation delay in a fast redstone clock?

There is already a very good answer below, however this question is not closed. If you have a better method, feel free to pitch in!

Answers that will be accepted include:

• Different clock circuits that have built-in functions to mitigate the redstone lamp.
• Modular devices that connect to an existing redstone clock to compensate the delay.

Please note that I cannot accept answers that are:

• Suggestions to use a different clock circuit, but using a compensation method that has already been shown here.
• Answers that are just images without justification.

You'll need a clock with 'on' state that is shorter by 4 game ticks(gt) than its 'off' state.

First, the lamp activates immediately but takes 4gt to switch off. It's an interesting quirk used e.g. to double observer pulses (an observer triggers a lamp with the usual 2gt pulse, an observer watching the lamp will trigger twice - once on activation, and once on deactivation).

Next, the simple hopper clock is really quirky - it's a 15gt period clock with 7/15 and 8/15 duty-cycle respective of which hopper you take the output from (and which of the two is which is locational, directional and in general unpredictable). Since 15 is an odd number, and in the game everything is quantized to gameticks, it is impossible to make the lamp work exactly 50% duty cycle on this specific clock. The best one could do is approximate with 7/15 or 8/15 by generating the correct pulse length (5 or 6gt pulses every clock cycle)

But we can use other clocks.

If we don't want to jump through hoops of activating the lamp with a zero-tick or 1gt pulse (generating these tends to be tricky), powering the lamp with a 2gt signal (1 redstone tick) gives a 6gt activation time, so we need a 12gt (6rt) clock with a 2gt duty cycle.

The lower-left is the simplest approach - a 6-observer clock, 2gt on, 10gt off. The clock on the right is a classic repeater clock equivalent (with an observer-based on-off switch, but you can activate it with a very short flick of a lever too). The upper left is a slower clock - 16gt, with 4gt duty cycle. The extra 4gt of the lamp make it light up for 8gt, out of the clock's 16gt period.

So, generalizing this to any clock - your clock's duty cycle must be 4gt shorter than the perfect "50%" to compensate for the lamp's 4gt off delay.

Where it comes to "compact", the "trimmed" versions of the 6-observer clock probably come close to the smallest one can do. They aren't exactly easy to toggle on/off though so the extended version is preferred (just power a rail permanently). It may be possible to trim it even smaller but it will probably necessitate going outside "standard" redstone mechanics.

Now for a generalized solution for any clock of exactly 50% duty cycle regardless of period:

This is a pulse limiter, that delays the rising edge by 4 gameticks, but removes the output power immediately (within the same tick) as input is gone. This way the initial delay compensates for the lamp delay.

For any clock whatsoever - this would not be pretty. For clocks with odd period this is impossible, simple as that. Can't generate n-and-a-half gameticks pulse. For clocks with even periods, it would require dynamic pulse extenders that generate pulse half the length of the clock's (previously measured) period. It's doable for clocks with period of a multiple of 8gt using hoppers and droppers, albeit the delays coming from the somewhat complex circuitry will cause imprecision that will need to be accounted for, but for clocks with arbitrary period this would probably end up as a mountain of very tricky computational circuitry, especially if the period is not divisible by 4 (in which case the circuitry must measure to a gametick, while most of redstone acts in 2gt increments).

Edit: a silent version of the delayed activation circuit to adjust the timing for arbitrary period 50% duty cycle clocks. Unfortunately without instant-tech (which is only possible with noisy pistons), it's not capable of handling clocks with shorter than 14gt period.

Bonus: Circuitry to handle an arbitrary duty cycle clocks with periods matching 8n+4 gt (arbitrary/variable on the fly, up to 320 seconds period, lowest 20gt)

It's based on generating a pulse half the length of previous cycle, by filling droppers using hoppers during the cycle, and emptying using observer clocks (2x hopper speed) the next cycle; two such pulse generators operate alternating measurement (hopper filling dropper) and generation (dropper emptied) roles every cycle. Unfortunately periods other than 8n+4 gameticks don't match a 'whole item' period of the hoppers (plus toggle overhead) so the result won't be tick-accurate with these - the duty cycle of the redstone lamp will be up to 7 gameticks off (which may not matter that much with periods going into minutes).