We know the corners can be solved in 1.5 seconds by experts, and we know LSE can be done in around 1.3 to 1.7 seconds. So with LMCF the only 'unknown' area is the E2L phase in the middle, between the start (corners) and the end (LSE), as well as the 'transition' between the three phases. Giving conservatively 1.9 seconds for the corners and 1.9 seconds for LSE (=3.8 seconds), then to get a 6.8 average we need to solve E2L in 3.0 seconds. We have 6 edges to solve, either in three pairs (1 second each), or two triplets (1.5 seconds each). I'm not a super fast cuber (yet) and my TPS is pretty slow; still, despite non-optimized E2L mechanics I have routinely gotten 4.5 second E2L phases in real solves. So we are not too far from the goal of a 3 second E2L.

The problem with the initial LMCF versions (up to and including v4.xx), is the E2L phase was not very optimized. First, the E2L algorithms were not super speed optimized. Second, the E2L algorithms often required as many as three setup moves (L setup, R setup, M setup). That is way too many setup moves. In my original document, I only gave E2L cases from one of the four possible orientations/reflections, and I simply said to use the L/R or F/B reflections for the other cases. What that meant is that the ergonomics of some of the reflections were very poor.

The E2L phase has tremendous potential, and this is what I have been improving lately:

- For the very common E2L cases, I have been ignoring reflections and treating all 4 (reflected) cases as unique and generating customized highly ergonomic and fast algorithms for EACH reflection. Furthermore I have found that by relaxing the movecount, and allowing for an extra 1-2 moves, the algs are way faster (despite a move or two longer). In this fashion all 'B' moves are eliminated, and all awkward regrips are eliminated

- Also for the common cases, I have found that certain situations have awkward setup moves. In some cases doing an L2 move in order to setup up the E2L algorithm is pretty slow. To compensate for this, it is possible to execute a different algorithm that solves to the DL slot instead of the UL slot, eliminating the awkward set up move

Some people have commented by early experiments that solving one edge at a time gives almost the same move count as solving pairs or even triplets. While this is almost true, it is absolutely not true of the speed of the entire E2L phase.

When solving SINGLE edges by the old fashioned keyhole method, you have

(A) a look ahead challenge between each edge you solve

(B) setup moves between each edge you solve

(C) often you have rotations between edge solves

(D) awkward move combinations

The flow is usually broken, and the TPS low. Solving is all intuitive, and non-algorithmic. TPS is more of the intuitive class.

By executing pairs or triplets, you greatly reduce the number of 'looks', you increase the TPS a lot by using algorithmic execution, and you reduce or eliminate rotations. The algorithmic method, by using super ergonomic algs, ensure all moves are fast and ergonomic, versus SINGLE edge-by-edge solving that often uses awkward L/M/R combos that need regrips and are really slow.

I have also been developing two new classes of triplet algorithms. Currently the triplets only solve DF+UR+UL at the same time, and only the case where the target keyhole edge moves to the opposite layer it is on. These are pretty fast, but they only occur (randomly) in about 30-50% of solves. By expanding the class of triplets, you can get triplets in almost every solve. It would take too long to explain the new class of triplets and I will leave it for the next document revision, but the ultimate goal of LMCF is to solve E2L in two triplets each taking just over 1 second. Allowing 1.1 seconds for each triplet, and a more aggressive 1.7 seconds for corners and 1.6 seconds for LSE, yields an average of 1.7+2.2+1.6 = 5.50 seconds which is pretty on-par with the best CFOP and Roux solvers. Of course, lucky singles would be way faster.