With the discovery of 0-move CP, CP-first methods for OH solving have gotten further optimized and hopefully, more people will be interested in these methods. However, the main CP-first method, CEOR, is not the only one. As many may (and have) noticed, after solving CPFB we can finish the solve as roux, with SB->CMLL->LSE. Due to solving CP, we get improved ergonomics and easier recognition, while CMLL only becomes 7 cases.
As you might notice though, this can easily be utilized to further reduce movecount. For example, L5C/SL5C becomes only 104 algs, which together with the easier recognition becomes more viable for people to learn. Winter and summer variation at 27 algs each are also relevant. Remember here that orienting the corners is all we need to solve CMLL since CP is solved. These are all subsets of what's called OCLS/COLS, orient corners last slot (assuming we solve L7E through FR edge -> LSE), which has been proposed previously for roux with CP-first as a general technique (2x2 block in SB->OCLS). However this algset is quite large, at almost 1500 algs. Some optimizations can be done to lower the "effective" number of algs, as I believe many are optimally solved through pairing->WV/SV, SL5C->solve pair and so on.
As the title suggest, I propose a new idea that I believe could create an incredibly OH-optimal variant of roux: Sequential OCLS
In short, the idea is to use OCLS for both slots of SB (meaning, we solve DR first). When inserting the first slot, we influence CO to get a better OCLS case for the following pair. An analogy to this would be how every OCLL case can be solved with a maximum of 2 sune/anti-sune algs. With sequential OCLS, we would do the "equivalent" of sune/anti-sune for each of the two OCLS. This means CMLL would be solved in 3 steps, each of which are combined with another one.
Here is a (cherrypicked) example, consider the following case
Where we have two pre-formed pairs in the U-layer. Let's consider some ways to solve this.
The standard way would be to do back pair, cancel into front pair, then CMLL
R' U R2 U2 R' //back then front pair
U R U R' U R U2 R2 U' R U' R' U2 R //CO
19 STM in total
We can also do it with front pair -> back pair
R U' R2 U2 R //front then back pair
U R U R' U R U' R' U R U2 R' //CO
17 STM
We can also do it with the previously proposed idea of using OCLS for our last slot
R' U R //back pair
U' R U' R' U' R U R' U R U2 R' //OCLS
15 STM
Now, with sequential OCLS, the aim is to look at the case and recognize that one should do the following
R U' R' //OCLS #1 (front pair)
U R' U' R U R' U R //OCLS #2
11 STM
Overall, the shortest solution for the case is (U') R2 U R U' R U2 R2 U2 R' at 9 moves, which sequential OCLS would not "tell us".
This technique I believe should be the human method that gives us movecounts for SB+CMLL closest to 1-looking the entire thing given that the DR edge is solved (which we can influence when doing CPFB). It also builds upon standard roux, thus shouldn't completely throw out knowledge one has gained throughout the years on how to solve SB efficiently. We can also utilize the technique with L5C/SL5C/conjugated CMLL if one wants to end with L7E instead of LSE. At last, it makes use of the freedom we have when choosing the order of front vs back pair.
Now for the drawbacks: To begin with, I haven't managed to develop a system for actually recognizing the first OCLS one should do, I'm hoping this thread will attract others who are interested in exploring this idea with me and try to create something that works. Furthermore, recognition at this level would be near the human limit for what's reasonable to recognize mid-solve, but I think it should be doable since we only care about orientation for the LL corners. We might also need to learn a lot of OCLS algs, as we now need to learn mirror algs as well in order to make use of sequential OCLS. A counter-argument here is that sequential OCLS by itself lowers algcount and I hope/believe the total algcount (with mirrors) should be lower than the 1500 figure mentioned previously. As also mentioned, I believe many can be done through forming a pair and then applying WV/SV.
Unless a comprehensive system is developed and you'd instead learn all the relevant cases (ignoring edges, only considering the 6 corners), we would have 927 after using U as auf and accounting for mirrors (however mirror cases aren't necessarily "free"). Which is a bit much, though perhaps doable? Especially if we could find some rule that halves the number. This is also not an "all or nothing" situation, we can lower our movecount gradually as we learn the various cases and rules. For example, avoiding cases where the 2nd pair's corner is in the U layer and oriented is relatively simple yet would improve movecount. Even if we found a rule that might still give us a bad OCLS, lowering the risk of getting one is a positive by itself.
I'd love to hear people's opinions on this idea. I've also made a general discord server for CP-first methods and 0-move CP https://discord.gg/5UZJeyAjyb as to not clutter the CEOR discord too much with non CEOR-related discussions.
Edit:
I've made a spreadsheet on CPRoux algs and what not, plan is to keep it updated and have it contain everything relevant. I also need to sort out the algs and remove all the obviously poor ones. Link to spreadsheet
As you might notice though, this can easily be utilized to further reduce movecount. For example, L5C/SL5C becomes only 104 algs, which together with the easier recognition becomes more viable for people to learn. Winter and summer variation at 27 algs each are also relevant. Remember here that orienting the corners is all we need to solve CMLL since CP is solved. These are all subsets of what's called OCLS/COLS, orient corners last slot (assuming we solve L7E through FR edge -> LSE), which has been proposed previously for roux with CP-first as a general technique (2x2 block in SB->OCLS). However this algset is quite large, at almost 1500 algs. Some optimizations can be done to lower the "effective" number of algs, as I believe many are optimally solved through pairing->WV/SV, SL5C->solve pair and so on.
As the title suggest, I propose a new idea that I believe could create an incredibly OH-optimal variant of roux: Sequential OCLS
In short, the idea is to use OCLS for both slots of SB (meaning, we solve DR first). When inserting the first slot, we influence CO to get a better OCLS case for the following pair. An analogy to this would be how every OCLL case can be solved with a maximum of 2 sune/anti-sune algs. With sequential OCLS, we would do the "equivalent" of sune/anti-sune for each of the two OCLS. This means CMLL would be solved in 3 steps, each of which are combined with another one.
Here is a (cherrypicked) example, consider the following case
Where we have two pre-formed pairs in the U-layer. Let's consider some ways to solve this.
The standard way would be to do back pair, cancel into front pair, then CMLL
R' U R2 U2 R' //back then front pair
U R U R' U R U2 R2 U' R U' R' U2 R //CO
19 STM in total
We can also do it with front pair -> back pair
R U' R2 U2 R //front then back pair
U R U R' U R U' R' U R U2 R' //CO
17 STM
We can also do it with the previously proposed idea of using OCLS for our last slot
R' U R //back pair
U' R U' R' U' R U R' U R U2 R' //OCLS
15 STM
Now, with sequential OCLS, the aim is to look at the case and recognize that one should do the following
R U' R' //OCLS #1 (front pair)
U R' U' R U R' U R //OCLS #2
11 STM
Overall, the shortest solution for the case is (U') R2 U R U' R U2 R2 U2 R' at 9 moves, which sequential OCLS would not "tell us".
This technique I believe should be the human method that gives us movecounts for SB+CMLL closest to 1-looking the entire thing given that the DR edge is solved (which we can influence when doing CPFB). It also builds upon standard roux, thus shouldn't completely throw out knowledge one has gained throughout the years on how to solve SB efficiently. We can also utilize the technique with L5C/SL5C/conjugated CMLL if one wants to end with L7E instead of LSE. At last, it makes use of the freedom we have when choosing the order of front vs back pair.
Now for the drawbacks: To begin with, I haven't managed to develop a system for actually recognizing the first OCLS one should do, I'm hoping this thread will attract others who are interested in exploring this idea with me and try to create something that works. Furthermore, recognition at this level would be near the human limit for what's reasonable to recognize mid-solve, but I think it should be doable since we only care about orientation for the LL corners. We might also need to learn a lot of OCLS algs, as we now need to learn mirror algs as well in order to make use of sequential OCLS. A counter-argument here is that sequential OCLS by itself lowers algcount and I hope/believe the total algcount (with mirrors) should be lower than the 1500 figure mentioned previously. As also mentioned, I believe many can be done through forming a pair and then applying WV/SV.
Unless a comprehensive system is developed and you'd instead learn all the relevant cases (ignoring edges, only considering the 6 corners), we would have 927 after using U as auf and accounting for mirrors (however mirror cases aren't necessarily "free"). Which is a bit much, though perhaps doable? Especially if we could find some rule that halves the number. This is also not an "all or nothing" situation, we can lower our movecount gradually as we learn the various cases and rules. For example, avoiding cases where the 2nd pair's corner is in the U layer and oriented is relatively simple yet would improve movecount. Even if we found a rule that might still give us a bad OCLS, lowering the risk of getting one is a positive by itself.
I'd love to hear people's opinions on this idea. I've also made a general discord server for CP-first methods and 0-move CP https://discord.gg/5UZJeyAjyb as to not clutter the CEOR discord too much with non CEOR-related discussions.
Edit:
I've made a spreadsheet on CPRoux algs and what not, plan is to keep it updated and have it contain everything relevant. I also need to sort out the algs and remove all the obviously poor ones. Link to spreadsheet
Last edited:
will just take a few minutes to set things up
