At first I was thinking "Yay computation!", because computation is fire.

Then I built a machine with quintessence like a fool.

Finally I remembered "Computation is fire", so I deleted that and used triplex.

Four pieces of state here:
1. The template element (if saltlike) - parks next to berlo
2. "Is it a saltlike?" - a wand that arm 15 uses to pull saltlikes off the ring.  Note that this is always fire.
3. The number of quicksilver needed to make the template metal (if metal) - on ring 2.  Note that this arm is the one that forces period 5 (and therefore tears).
4. "Is it a metal?" - a wand that arm 10 uses to pull lead off the ring.  This one also forces period 5.


Period 5 is forced because if you have an inconsistent number of elements on a wheel, you cannot wand off another wheel with period 4.  If you do, sometimes the wheel steals your wand.  This is a problem since I wanted to store the metal value in a hexarm.

Really glad to finally have rate in computation; I've always wanted that to be the metric instead of cycles.  I'm glad this puzzle was simple enough at its core to be manageable as rate.

A bit sad that the weighting on rate is not high enough to encourage really crazy fast machines.  This metric is more summy.

(Host, you don't need to read this aloud)
Interesting spots:
* Arms 3, 6, and 5 work together to load exactly 5 quicksilver onto arm 2 at period 5
* Arm 15 can both wand and travel because of period 5
* Arm 10 has an interesting pattern so it can wand at 1/6 P