Talk: Redstone circuits/Clock

Small vertical repeater clock

small vertical repeater clock

I just learned a small vertical repeater clock (I think it's a 2-clock) from this video. Output is to the left. I'm going to attach a picture -- can someone with MCSim skills to a diagram for it? --Mental Mouse 15:09, 15 December 2012 (UTC)

This circuit would be a good addition to the article -- it's smaller than the others and it's 1-wide (though not tileable) which makes it sufficiently interesting. : )

A schematic isn't necessary if a screenshot can illustrate the circuit sufficiently, so consider going ahead and adding the circuit to the article. However, this screenshot could be improved -- you might want to take a look at the style guide I used for creating screenshots for Redstone Circuits.

Your picture is a 2-clock, but the torch will burn out unless the repeater is set to at least 2 ticks, making it a 3-clock, so this clock is good for a range of 3 to 5 tick pulses (0.6 to 1.0 second periods). You can toggle this clock on and off with a lever (or other power signal) on any of the four required opaque blocks (you retain smallest circuit volume by attaching a lever underneath the central block, either to it or the block supporting the redstone), by powering the redstone, or by locking the repeater. Output really can be taken from any part of the circuit (except the repeater), not just the left. —Munin295 · · 18:29, 15 December 2012 (UTC)

Map flicker "normal" state

Map flicker "extra view" state

Hmm. I had one of these running for a couple minutes in my lair, with the repeater on default, and neither torch burned out, but I might not have waited long enough. I'll look at the style guide -- I already know I'd need to switch back to the default textures. PS: I wasn't sure if it was a 2- or 3-clock because it does have two torches along with the repeater. Thanks for confirming. --Mental Mouse 20:56, 15 December 2012 (UTC)

Got one running now, and I noticed something interesting -- two of the maps visible in the background are flickering, from their usual state to another that shows more (apparently valid) mapped area. (Uploading screenshots now.) Also, a redstone lamp next to it does not flicker quickly, it stays mostly lit with occasional flickers of darkness. --Mental Mouse 21:14, 15 December 2012 (UTC)

ETA: And now it's burning out within a few seconds... not only on minimum delay, but on the next delay setting as well. Also, the maps should be showing the larger amount of territory, it's the smaller amount that doesn't match the copy I'm carrying. --Mental Mouse 21:20, 15 December 2012 (UTC)

The higher torch in the video isn't part of the clock, per se (unless you've got it feeding back into the clock in some way), the video is using it to change the clock's usual 5 ticks on/5 ticks off output (the video's repeater is set to 4-tick delay) into a 1-tick off pulse every 10 ticks (the torch on the bottom turns off but the torch on the top doesn't turn on until a tick later: an incorporated falling edge detector) to make the piston retract and then instantly extend again. My builds only burn out when the repeater is set to 1 tick, in all four orientations (v1.4.5). I can't see any difference in the maps you posted. I think I remember someone else saying that maps in frames don't always update properly -- you may need to pop it out, look at it, wait for the updates to load, and then put it back in the frame (which doesn't explain what's happening, but might fix it). —Munin295 · · 00:51, 16 December 2012 (UTC)

On closer inspection, the flickering maps are changing to a (the same) different, less complete map (which is not map #0, map #0 is one of the flickering maps (and the copy in my hand didn't flicker). I tried popping a couple of them off the wall and putting them back, and saving and reloading, but that didn't help. It also continued happening after I turned off the clock, so it may or may not be related. Regarding the clock, that's interesting -- but the lamps I tried stayed mostly lit whichever end I put them at. --Mental Mouse 02:19, 16 December 2012 (UTC)

And... I just looked at it again, and it's behavior seems different (I hate when that happens). Both torches are definitely alternating at roughly 50:50, and lamps match that if the left lamp is a block up -- if it's on the ground, it does stay mostly on-- because it's being lit by two alternating torches! It is definitely not producing 9:1 pulses that I can see, though I could believe I'm missing them on that second lamp. Also, the maps are back to normal. --Mental Mouse 02:32, 16 December 2012 (UTC)

Redstone lamps take 0 ticks to turn on, but 2 ticks to turn off (even lamps moved by a piston) -- and if the signal turns back on within that time, the lamp won't turn off (try running redstone over a lamp from a short clock -- you'll see the redstone turn off, then the lamp). The two-torch falling edge detector produces a 1-tick off pulse, which isn't long enough to turn a lamp off (or some other redstone components -- you can extend a 1-tick off pulse with a sticky piston moving a block over a torch to power a repeater). But if you power a lamp from the 5-clock itself, not the falling edge detector, it will flash on a 7/3-tick cycle (5 ticks on, 2 more ticks on after the power turns off, then 3 ticks off before the power turns on again). Pistons are a better way to observe the behavior of a circuit since they react instantly to both rising and falling edges (or oscilloscopes can give precise read-outs for non-short pulses).

There's a lot of really unintuitive behavior like this in redstone components. Jeb said at Minecon that the Redstone Update will affect the timing of some components, and I'm hoping things like this get fixed (or at least made more predictable). —Munin295 · · 03:13, 16 December 2012 (UTC)

Amen on the fixups... on the other hand, adding a Nether ore sucks when I've already had to explore lots of it to find my fortress. But that's another discussion entirely.... --Mental Mouse 14:42, 17 December 2012 (UTC)

Just to note, I've confirmed that this clock still works in 1.5. Also, it can be turned off by a lever on the base block any of the blocks, or by pulling the upper block away with a piston. (It seems to start fairly reliably when the torch is placed.) --Mental Mouse 12:02, 16 March 2013 (UTC)

Boat Clock broken?

It appears that the Boat Clock in the video does not work anymore. I'm using 1.4.7 and it doesn't seem to work as shown in the video. Can anyone else confirm?

--Ioncupcake 08:09, 25 January 2013 (UTC)

Better Piston Clock

For anyone who wants to throw this in the article, here's a very simple and controlled piston clock. I actually created another one that requires less room as well, 3 x 5, and if anyone wants me to post it just reply on here. [1]

199.187.203.27 07:32, 4 February 2013 (UTC)

Hopper Clock

2 hoppers facing each other gives a 4clock, might be useful editing that in.

89.233.84.253 02:43, 27 April 2013 (UTC)

Whoops, my goof. You are right, though as it turns out, it's not quite a 4-clock -- I've got one running on an ocilloscope, and it's putting out 4 ticks high but only 3 ticks low. --Mental Mouse 21:17, 27 April 2013 (UTC)

IMO the page could be more clear about the timing of hopper clocks. I mean, 7.5 ticks?! How is that even possible. Trying to make a 375 tick clock here. 81.206.105.164 13:05, 22 February 2014 (UTC)

There are many examples of half-ticks in redstone circuits. A redstone tick is two game ticks, so a a "half-tick" is really one game tick. Hopper clocks are often used for long clock periods where you aren't going to notice a half-tick difference though.

For a hopper clock with a clock period that doesn't fit precisely into multiples of 8 ticks, try delaying one of the pistons with repeaters. A 4-tick repeater also seems to smooth out the half-ticks, so the clock on the right produces a 7-clock with a single item, plus 8 ticks for each additional item, so 93 items should give you a 375-clock (375 ticks on, 375 ticks off).

—munin · · 15:41, 22 February 2014 (UTC)

COMPACT Piston Rapid Pulsar

I just made a compact rapid pulsar using pistons and the new Redstone block. It's dimensions are (X x Y x Z) 1x2x1. Pretty compact!

I don't know how to work with the schematics, so I'll just post a screenie.

--Icrawler 03:01, 28 April 2013 (UTC)

This is slower than a rapid pulser: it produces a 1 tick on, 2 ticks off pulse. But it is more compact than the 1-wide rapid pulser in the article (the one that looks like a bridge of blocks), so it might find a use.

Ideally, images should only be uploaded for articles. If you just want to talk about a new circuit you made, the forums (or reddit) are a better place since you'll get a lot more responses.

—Munin295 · · 04:09, 28 April 2013 (UTC)

Efficient use of the clock multiplier.

I've been looking at the relative efficiencies of extending a repeater loop vs. adding a multiplier, and when to break a multiplier bank into two. The results are a little odd, especially for the latter, so I'm not ready to put them into the article without some feedback. What I've got so far:

• If you have a 5-repeater loop (20 ticks), it's slightly cheaper to double it with more repeaters than a 2-latch multiplier. If you want to triple it, or if the loop is any longer, the multiplier wins unambiguously.
• The odder part: Once you have a multiplier with N=3, doubling it by extending the bank is only slightly cheaper than adding a second bank with N=2, but if you want to go much past that, you're better off adding a second bank with N=3.

So it looks like the max-efficiency uber-clock would look like a 5-repeater loop (possibly 6?), followed by a series of three-latch multipliers.

This is just from some pencil-and-paper noodling, not rigorous analysis, I'd appreciate if anyone else would look at it and see if they come to the same conclusions.. --Mental Mouse 13:34, 8 June 2013 (UTC)

Looks right. Sequences of N=3 latches seem optimal.

—Munin295 · · 15:17, 8 June 2013 (UTC)

On closer examination, accounting for dust and space complicates matters:

• R is repeaters, D is dust (I'm counting the ED torch as dust), and TR is total redstone, that is 3×R+D . L is length, that is blocks used in the 5-wide corridor.
• I'm assuming the repeater loops are within the multiplier's 5-wide path. Note that repeaters always use 4 dust (the corners), with a possible fifth to match an odd repeater.

Circuit	R	D	TR	L
4-loop	4	4	16	2
5-loop	5	5	20	2
6-loop	6	4	22	2
7-loop	7	5	26	3
8-loop	8	4	28	3
9-loop	9	5	32	4
10-loop	10	4	34	4
12-loop	12	4	40	5
15-loop	15	5	50	7
16-loop	16	4	52	7
+2 loop	2	0	6	1
Multiplier, N=0	1	8	11	3
Multiplier, N+1	2	2	8	1
Toggle L3	3	4	13	3
Toggle L5	4	6	18	3
2-Multiplier	5	12	27	5
3-Multiplier	7	14	35	6
4-Multiplier	9	16	43	7
5-Multiplier	11	18	51	8
6-Multiplier	13	20	59	9
7-Multiplier	13	20	67	10
8-Multiplier	17	24	75	11
9-Multiplier	19	26	83	12
10-Multiplier	21	28	91	13
12-Multiplier	25	32	107	15
15-Multiplier	31	38	131	18
16-Multiplier	33	40	139	19

So, a a 12-loop beats 4×3, a 15-loop beats 5×3, and a 16-loop beats 4×4, both on total redstone and space. Also a 9-multiplier edges out ×3×3. Beyond this, the results seem less surprising. --Mental Mouse 22:13, 8 June 2013 (UTC)

Whoops, found major errors in my table. Serves me right for calculating in the edit buffer.... ;-( Most of the anomalies went away. --Mental Mouse 01:20, 9 June 2013 (UTC)

Oh my, it seems 2 toggles are much cheaper than a 4-multiplier. You might say, they clean its clock.  ;-) On the other hand, they might not be shorter after bringing the input and output into line. --Mental Mouse 13:02, 9 June 2013 (UTC)

However, it's just L5 in the ring here, L3 oscillates. --Mental Mouse 13:24, 9 June 2013 (UTC)

Spawner Clock

I had an idea about using spawners for clocks/timers and I just realized that it could be added to the wiki. The only problem is that I'm not quite sure how and in what way, so I'd rather leave the editing to someone more experienced. Now this is something that can only be made using mods or external tools, but the result is completely vanilla (so this is mainly usable for people making adventure maps), so I think it's worth a mention. Here is my video explaining the concept. What do you think? --Lord blex 18:45, 22 July 2013 (UTC)

I haven't listened through the whole video, but from the first part and your description here, I think this would be best placed as a tutorial, something like "Spawner Clocks For Adventure Maps". Right now I think it would do best in the "Technical" section, but it would be cool to collect enough similar tutorials to have a whole section on building maps and related engineering, not just that lonely tutorial on making "challenge maps". --Mental Mouse 23:31, 23 July 2013 (UTC)

Credit where due

I notice the citation style for first known publication has been altered. Fair enough. However, Sethbling's design does not include the additional output circuitry that I added when I independently invented the build. Put simply, the current citation implies that the entire design is down to Sethbling, which is not true. So I would like to ask how it would be best to reassert my contribution to the long period hopper clock design. Would something like this be okay?

''Earliest known publication of core design:''  22 January 2013<ref>"SethBling" (22 January 2013). [//www.youtube.com/watch?v=ThsaI0iOZGg "7.5 Minute Hopper Timer -- Minecraft Tutorial"] (Video). ''YouTube''.</ref>
''Augmented design independently published:''  8 June 2013<ref>"SorcerorNobody" (8 June 2013). [//www.youtube.com/watch?v=XCDEXtalF9Q "Long period adjustable hopper clock"] (Video). ''YouTube''.</ref>

-- Sorceror Nobody (talk) 15:30, 30 October 2013 (UTC)

EDIT: Same goes for the clock multiplier, too. Certainly, the original design is suitably cited, but Mental Mouse and I put a fair bit of work into streamlining and generalising the design on the wiki. The design as the wiki presents it is therefore not just the product of the original citation -- Sorceror Nobody (talk) 15:35, 30 October 2013 (UTC)

We do not have an official policy on how to credit designs. In fact, there are some admins who don't think credit should be mentioned, because it creates ego problems like this (you may have noticed that in the rest of the wiki, references are given as raw web addresses without mentioning usernames and the rest, due to frequent problems with people trying to promote their own youtube videos).

My feeling is that "earliest publication" is useful, not because it says who created it (we're not curing cancer here), but because (a) it provides an idea of how long the circuit has been around available for others to use and gives a sense of how circuits have evolved over time, and (b) it provides a way for the reader to get more info about the circuit which may be out of the scope of the article.

If you had published your circuit earlier than SethBling did, then that would be worth mentioning. However, your version is really a very minor variation of his design (you just added an edge detector to shorten the output pulse) and probably out-of-scope for a clock circuit article (changing the lengths of pulses belongs in Pulse circuit).

My preference would be to restore SethBling's design to show the original published concept (and which also is a more general version that people can more easily adapt to their own requirements), and just say "Use a pulse limiter to reduce the output pulse", since there are many pulse limiters to choose from, not just the one you used.

—munin · · 19:04, 30 October 2013 (UTC)

I do agree that really credit should be all or nothing as names go. I mean, I knew it would probably be interpreted as such, but this wasn't an exercise in ego stroking on my part, it was more about the separation of contributions. Still, fair points, all in all; I see no reason to debate further : ) -- Sorceror Nobody (talk) 17:11, 1 November 2013 (UTC)

It's tough to manage such credits on a public wiki. One idea that occurs to me, is to include an originator's name in the edit comment when adding their design, so it's at least visible in the history. However, some changes are significant; notably, adding a new functionality without sprawling the circuit way beyond the original limits is non-trivial. (When I was working on the automatic chicken farm it took me 3 tries to get the timer arranged so the works stayed comfortably under the chicken floor, which is way bigger than the final circuit.) --MentalMouse42 (talk) 19:53, 1 November 2013 (UTC)

Design E and NS-Quirk

What is NS-Quirk? Link's invalid. And I try to build (1.7.2) all 4 orientation (NS/SN/EW/WE) of E design and see no difference(all 5-clock) Is info about 4-clock here valid yet? If no, need add maximum version to the article. VpArth (talk) 17:17, 18 November 2013 (UTC)

It is entirely possible that design E is obsolete, I haven't had a chance to try and verify it recently. --MentalMouse42 (talk) 01:17, 21 November 2013 (UTC)

The North-south glitch was a vagary of redstone behavior, where in some circuits, torch timing depended on which direction they were pointing. Given the nature of the game, people natually started accounting for it in their circuits. I wouldn't be at all surprised if the devs have finally stamped it out. --MentalMouse42 (talk) 11:00, 22 November 2013 (UTC)

I recently designed (and yesterday constructed) a piston door for my base on my current world. The east-facing door worked fine. The west facing one, two pistons were firing fractionally too early during the opening sequence, causing them to not extend due to blocks that should have moved out of the way fractionally beforehand. Talk about timing being too perfect.

Anyway, since the entire build was done symmetrically between east and west, I concluded that it was down to orientation sensitivity. I mean, I could be wrong, but honestly I don't know what else might explain a difference in behaviour between two builds that are 100% identical apart from the direction they point in. So I'm inclined to believe it hasn't been stamped out -- Sorceror Nobody (talk) 17:01, 28 November 2013 (UTC)

Was it down to torch timings? If not, the original NS-glitch might well have been replaced by some subtler bug. --MentalMouse42 (talk) 21:09, 28 November 2013 (UTC)

Hard to say. Each door consists of two halves that are symmetrical apart from one added circuit that only exists on one half -- the one that connects the internal button to the door circuit (the external button is pretty much wired straight in). Since the west door had the same malfunction regardless of which button was pressed, I believe I can discount those two torches.

This brings me to the other four torches in each door, those that power the upper and lower pistons. In each half, both pistons are powered by torches facing in the same direction as the door. The upper piston is powered directly by its torch; the lower, the torch powers a short redstone wire leading into a block, which in turn powers the piston. The same redstone output leads into both torches, so they should trigger simultaneously.

I don't really know enough about the bug to tell whether it would explain this. I can whip up a schematic or something for you to look at if you want to analyse it -- Sorceror Nobody (talk) 17:40, 30 November 2013 (UTC)

EDIT: Hm, after having checked that everything is identical to the creative test version I built to start with, and then having pasted the actual door back into creative and testing it, I'm not getting the malfunction. Which I guess implies something to do with survival world lag? Though I'm not certain why there'd be more lag on the west door since the whole span of both doors and the space between them is only 30m side to side, and more to the point is in the spawn chunks, so nothing should be loaded on the west side that isn't loaded on the east. And even if it is just down to lag, I get the feeling that the lag should only amplify an existing timing oddity rather than creating one, since otherwise I'd still expect the top and bottom pistons to be simultaneous. Though perhaps that's down to a difference between piston directions?

I guess I can only leave working it out for someone who understands the subtle quirks of redstone better than I do -- Sorceror Nobody (talk) 18:21, 30 November 2013 (UTC)

You took your best shot, and I'm afraid timing on that level is way beyond my level. --MentalMouse42 (talk) 06:02, 2 December 2013 (UTC)

Despawn Clock

Munin, what advantage does that torch setup have over simply putting the dropper pointing down over the pressure plate? --MentalMouse42 (talk) 19:35, 7 December 2013 (UTC)

Do you mean like this? I think you'd still need blocks to keep the item from bouncing out, so it would be taller and uses more redstone… Did you mean something else?

—munin · · 22:00, 7 December 2013 (UTC)

Actually I was thinking of just running the redstone from the plate, like in the button for that chicken farm. But on consideration, that one is unreliable, and that's partly because of the opening for the redstone. --MentalMouse42 (talk) 05:10, 8 December 2013 (UTC)

Another thought: There aren't too many unattended sources of items around to feed the clock indefinitely, but one that would work would be a full-auto melon farm -- just one round of that stackable farm would do fine, (or a smaller version with only 2 fruit spaces) and the harvest could be triggered by the clock's own signal. --MentalMouse42 (talk) 05:24, 8 December 2013 (UTC)

Two chickens could keep a despawn clock supplied with eggs, no redstone needed just a hopper. —munin · · 05:51, 8 December 2013 (UTC)

Hey, what happened to the Torch/repeater loops?

I could have sworn we had some examples for the basic repeater-loop with one torch, but they've been reduced to a mention in the torch-loop section (despite the mention of repeater loops down in the multiplier). Munin, was that you? That's still a workhorse circuit for midrange loops with a 50/50 ON/OFF cycle. Especially when you don't have nether quartz.... --MentalMouse42 (talk) 13:41, 2 February 2014 (UTC)

They've got their own section now: Clock_circuit#Torch-repeater_clock. —munin · · 19:54, 2 February 2014 (UTC)

Which gives only the two vertical T/R clocks, with no example for the more general flat loop. --MentalMouse42 (talk) 01:42, 3 February 2014 (UTC)

It looks like all I did was rename the section from "Vertical Loops" to "Torch-repeater clock", to distinguish them from repeater loop clocks more (repeater loops suck, torch-repeater clocks for life!).

Adding flat versions is definitely on my "list", but who knows when I'll gather the will and time, so obviously feel free to add them yourself if you want. I've still got some stuff to finish up on Pulse circuit too.

—munin · · 02:16, 3 February 2014 (UTC)

I'll try to do it tomorrow, but mostly I'm wondering when/how they went away. I'll try looking through the histories tomorrow, too. It's 3AM here, I've been having way too much fun with Thaumcraft. Exploring a ravine with the Thaumostatic Harness (flying, much like C-mode's), not to mention harvesting resources with the game's special toolset.... Lucky I'm not working tomorrow. --MentalMouse42 (talk) 08:07, 3 February 2014 (UTC)

OK, done. The history wasn't terribly helpful, because the diffs run out fairly quickly. But I've got a circuit and commentary up. --MentalMouse42 (talk) 14:31, 3 February 2014 (UTC)

Piston clock cycle times

So I was doing some testing of a new fast clock I created (probably not the first person to do so but I couldn't find it mentioned elsewhere) and so was comparing it to all the examples I could find online, then using a command block clock for comparing the cycles and I noticed some of the clock timings are wrong on this page.

Design A actually has a cycle length of 3 ticks if run without a repeater; adding the repeater creates some weird behaviour because of the point in the cycle where it cuts the signal dust (cycle lengths of 3.5, 5, 7 or 9 redstone ticks depending on the setting). Design B is essentially the same just with a reset circuit to avoid jams and so again is a 3 tick cycle as is design F. Design G is effectively an inverted form of design A, you can even add a repeater if desired.

None of these are 1 tick clocks due to how pistons take 3 ticks to fully extend and retract and so are 1.5 tick clocks according to the nomenclature in the introduction. Potentially piston clocks should have a 'piston-tick' timing reference, but then that gets screwed up by legitimate 1-tick piston clocks.

FWIW: The version I created is a 'Double Dustcut' variant of A, running without repeaters and using the piston cycle to cut the output twice which results in a resource-light, very fast clock without being reliant on on nether materials. It has a cycle length of 1.5 redstone ticks which would be a 0.75 tick clock and I would guess is the only way to get a clock this fast using just a single sticky piston.

Also I don't really see much point in having the illustrations for clock C or D - pretty much any clock can be stopped by adding a lever somewhere to toggle a torch off or leave a signal permanently on. They just seem like messy examples combining parts of torch and repeater delays along with pistons. Likewise the shamrock clock is impressive, but can also be made faster, and more resource light without the repeaters by just replacing each one with a raised block with dust on top. In fact after doing this you can then remove upto 3 other bits of dust (for a clockwise block movement, only remove the North one for anticlockwise)) which turns it into a 1 or 2 tick design (take a South output and join with the North for a 1 tick) - also whilst thinking of circuit clocks like this there should be a mention of "ring memory" from the piston tutorial page, these can be used to make very slow clocks when combined with other timing methods (although are they're incredible wastes of space, they're also very cool.

And finally I think the 1 wide version of dustcut and redstone block clocks are more useful than the space wasting versions.

Show some love back to piston clocks <3

A

O

1-wide Redstone Block 1.5 tick

Dot of redstone dust underneath redstone block

A

O

1-wide Dustcut

1.5 tick

	O

Shamrock Redux 2 tick Must be aligned North and clockwise

4th torch underneath extended piston

	O	O

Chuckle Brothers 1 or 2 tick "to-me to-you"

For 2 tick variant take an output from either side

A
				O

Double Dustcut

0.75 tick

PhlOgistOn68631 (talk) 17:39, 3 September 2014 (UTC)

Are you asking for someone else to do the edits, or are you asking for confirmation before you do the edits, or what?

Just because a clock has a clock period of 2N ticks doesn't automatically make it an N-clock. An "N-clock" specifically means "N ticks on, N ticks off" and there's no such thing as a 0.75-tick pulse. I'm guessing yours is "1 tick on, 0.5 ticks off" or maybe even "1.5 ticks on, 0-tick off-pulse" (which is a thing). But it's an extremely unstable clock -- its too easy for the moving block to end up in the extended position when the clock is turned off, and then it needs to be reset by hand (or another piston?). —munin · · 19:21, 3 September 2014 (UTC)

I basically wanted confirmation that I wasn't derping before considering a rewrite of the piston section.

"The customary name x-clock is derived from half of the period length, which is also usually the pulse width" (First line of the page) - as stated all the piston based clocks which are referred to as 1 tick clocks, have a period of 3 and are therefore miscategorised by the wiki's own definition, likewise the clock I discovered has a period of 1.5 and so would be classified as a 0.75 clock by this wiki.

I'm not 100% sure on how to test the pulsewidth and it's entirely possible it's a 1.5 on, 0 off, which might explain why it only plays with noteblocks and command blocks but not dispensers; to be honest I'm not even sure if it's symmetrical, it might be something like 0.5 off, 1 on, 1 off, 0.5 on - which is what I'm trying to currently investigate as I'm unclear on which stage of each tick each section of dust gets cut and how the signal gets divided as a result. And yeah it's unstable if you unload the chunk or if you took it anywhere away from a local client, as are all the '1 tick' piston designs on the page to be fair :)

PhlOgistOn68631 (talk) 20:06, 3 September 2014 (UTC)

Compact silent hopper clock

I just came up with a silent hopper clock that looks more compact than others on the wiki. Never edited a wiki/made schematics before though so I'll just upload a screenshot. Sorry if this causes any inconveniences... I'm a utter noob. 140.112.249.243 17:08, 9 December 2014 (UTC)ShadowHunter

Okay, we'll take a look into it. But please notice that you need to sign up in order to be able to upload images. --Naista2002 ♦ 17:14, 9 December 2014 (UTC)

Looks promising. Unfortunately I don't have Minecraft nor a redstone simulator capable of supporting hoppers, so I can't that easily test it. One problem is that File:HopperClock.png is an ambiguous name. Munin? --Naista2002 ♦ 17:23, 9 December 2014 (UTC)

It works good. It would be easy to reproduce using the schematics too, as it only has a two block height. –KnightMiner ^(t·c) 17:43, 9 December 2014 (UTC)

I want to know how it works, as the screenshot shows it not filled with items. --Naista2002 ♦ 17:46, 9 December 2014 (UTC)

Basically you place any amount of items in either hopper, and it moves them back and forth. It only moves items from the second back into the first once the first is empty. Any of the torches can serve as an output it seems, with the top one pulsing every cycle, and the others alternating states during the cycles. –KnightMiner ^(t·c) 18:16, 9 December 2014 (UTC)

This is a variation on the other RS NOR Latch hopper clocks, so I would only support adding it if it had some distinguishing feature. Unfortunately, it really isn't compact -- it's 4×4×3 (48 block volume, 16 block footprint) which makes it larger than all the other silent hopper clocks in the article except the first RS NOR Latch hopper clock (Etho's original design, only documented for posterity since it's been bettered by other circuits since). Even if you change the bottom dust to a repeater to get rid of the dust on top of the block (dropping it to 4×4×2 = 32 blocks, 16 block footprint), it's still not the smallest silent hopper clock (the hopper-latch and the "amputated" sethbling are both 24 block volume, with 8 block and 12 block footprints).

There are endless possible variations on many of these clocks. The article can't and shouldn't try to show them all, only variations which are useful or distinctive in some way.

ShadowHunter/D15926: I'd recommend posting this to the Minecraft Forums or reddit and see if anyone else likes it or can improve it. —munin · · 19:46, 9 December 2014 (UTC)

Maybe this?

It fits into 3×3×4 = 36 block space, with a 9 block footprint. And that's without me having Minecraft :) --Naista2002 ♦ 18:31, 13 December 2014 (UTC)

Munin? --Naista2002 ♦ 13:37, 14 December 2014 (UTC)

Fine compaction, but I'm unexcited by it. I can't imagine anyone saying "Oh! That's exactly what I needed!" (hardly anyone uses RS NOR Latch hopper clocks anyway). But if someone wants to add it, it's not like I'll get into an edit war with them or something. —munin · · 19:05, 14 December 2014 (UTC)

I just wanted to try. Nevertheless, it is horizontally compact, so I think it is suitable for these 5-block-thick towers like these lighthouses :) And not everyone has much hoppers or quartz to do the hopper latch one :) --Naista2002 ♦ 12:36, 15 December 2014 (UTC)

To D15926: You can create these schematics using {{Schematic}}. --Naista2002 ♦ 12:38, 15 December 2014 (UTC)

As a connotation, I’d like to say that my variant of compaction didn’t actually work. Tested in 1.12. P.S. I’m former naista2002. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 10:07, 1 August 2017 (UTC)

Hopper clocks unreliable?

I find hopper clocks unreliable, with the duplication bug that's been around since at least 1.7. Put in 10 items.... go away and my clock now has two stacks of 64 items. Tried switching to a "cool" down system... but alas just checked it... started with 1 item.. now as a 38 items.

Any one found a way around this?

Problems with clock multiplier in 10.2?

So, I pulled out the trusty old clock multiplier for a new build, and have been having weird problems. With a N=5 build, I'm getting two of the latches lit (generally on startup), with an N=3 build it's advancing two latches at a time (usually from the last latch, to the second latch). --MentalMouse42 (talk) 16:22, 7 September 2016 (UTC)

ETA: Adding redstone dust between the latched repeaters seems to fix the problems. Perhaps connected with the new discussion of how redstone updates work? --MentalMouse42 (talk) 16:42, 7 September 2016 (UTC)

Even crankier in 1.12.2: The original inverted edge detector doesn't seem to do an off-pulse, and the trick of placing a powered torch is liable to light two of the repeaters or none. Replacing the startup circuit with another pulse generator does get a stable loop, but then a OR-gate off-pulse generator on the latches showed an off pulse, but the latches simply don't respond. This is after putting dust between the repeaters. :-( --MentalMouse42 (talk) 20:57, 20 January 2019 (UTC)

Augmented Observer 1-clock

I found a particular clock with some interesting properties:

Observer clock

At first glance, it looks like a substandard observer clock with a 1 on : 2 off pulse, but if you hook it up to a torch burnout clock briefly and then disconnect it, it becomes a 1-clock. It also runs continuously unless the leftmost dust is powered directly, in which case it would revert back to its normal clock cycle. This seems useless to me, but I'm sure someone could find something to do with it. Legitimateted2401 (talk) 01:36, 8 May 2017 (UTC)

I would not see a need for such a clock because you can make a less expensive clock that has the same signal pattern:

Simple clock

It also takes up less space. The Blobs 01:29, 9 May 2017 (UTC)

The torch will burn out very quickly, so it is not that reliable. After all, a comparator 1-clock is just as easy and requires way less resources. — BabylonAS (talk | ru.Wiki Admin) (fka NickTheRed37) 10:09, 1 August 2017 (UTC)

More minimal piston clock

I was surprised when I saw the illustration of the "minimal" piston clock, which way more complicated and space consuming than the one I've been using:

Minimal Piston Clock

The redstone block completes the circuit, extending the piston, which breaks the circuit, retracting the piston, etc. This ticks as fast as the piston can move. It can be slowed down by inserting repeaters in the loop. Break a redstone dust to stop the clock.

Is there a reason why blocks of redstone aren't used in these examples? Amatulic (talk) 15:09, 12 March 2018 (UTC)

Tutorial?

Should this page be a tutorial? 194.207.105.165 20:43, 26 March 2019 (UTC)

I would say it should probably be split, leaving this article as a general explanation and a tutorial for all the examples. ~ Amatulic (talk) 00:25, 27 March 2019 (UTC)

(untitled)

Why does the page say, "Ethonian Hopper Clock – Both pistons are sticky". I'm on Bedrock, admittedly, but can see no reason for these to be sticky pistons. The point is that both pistons are always pushing, until one hopper is empty, at which point that piston retracts and the other can move across. I've tested of course, just to be sure and no stickiness is required! Eggfur (talk) 08:29, 10 May 2020 (UTC)