also a second query are you allowed to wear glasses under the blindfold in comp?just curious because i find it easier and some what comfortable. that being said i find it easier to concentrate when i wear y glasses

@tao yu I've done it twice with old pochan but have et to get a success with m2/op. all help is appreciated:D
 
So I just learned TuRBo from Zane's tutorial today and I've been practicing quite a bit. However, the tutorial didn't address pre-solved, unoriented edges. Is it the same as M2, where you just take note of them and solve them separately with the UF/UB orientation alg? Or am I being dumb and missing something important?
 
So I just learned TuRBo from Zane's tutorial today and I've been practicing quite a bit. However, the tutorial didn't address pre-solved, unoriented edges. Is it the same as M2, where you just take note of them and solve them separately with the UF/UB orientation alg? Or am I being dumb and missing something important?

Nope, you got it. Unless you wanted to make it far too complicated by taking the incorrect piece out at the end and inserting it correctly.
 
^ Okay cool. TuRBo is pretty fun to play around with after doing braindead M2 for so long. I'm also been experimenting with some commutators and floating buffers. It's hard for me right now to make better movesets/commutators in place of the hard TuRBo cases, but I guess I'll get better after I master BH corners/edges.
 
Yeah sure, hope it helps. Just keep in mind that using this strategy will mean more moves to solve centers than if you used floating buffers. I find this to be a reasonable trade-off for what I consider to be easier memorization.

This case is done exactly the same way as a corner "columns" case in BH. I don't want to just give you the alg for this specific case, because that is meaningless. It's much better to understand the "columns" commutator itself, then you will know how to apply it to any case, including your cycle: Ufl -> Ubr -> Dfl

My god Chris, you are light years ahead of me. I figured out the case. Your guidance is invaluable! Chris Hardwick = Yoda
 
How do you deal with parity in BH corners? I'm sure there's different approaches, but I don't even know one (or at least an efficient one anyway). Here's an elaboration:

In parity, after all the BH 3-cycles, you would have a 2-cycle remaining (with your buffer [UBR] and some arbitrary corner). Are any edges swapped, i.e., do I need to do anything before I go straight ahead to TuRBo edges? I know I will have to do a PLL case after the edges, but I'm wondering if I need to do anything in step X: BH Corners -> X -> TuRBo Edges -> PLL Case. And wouldn't the PLL case require the unsolved 2 corners to be oriented?

Sorry for the long-winded question, but I wanted to elaborate in case my solving method determines the correct/efficient approach to parity.
 
Last edited:
How do you deal with parity in BH corners?
If executing edges first:
One thing you could do, is solve all edges accept leave UB and UL swapped, so to fix parity all you have to do is solve one corner with Classic Pochmann (y-perm).

If executing corners first:
One thing you could do, is solve all corners accept leave UBR and UBL swapped. The last edge would be solved by setting it up into the U layer and using a PLL.

This is sometimes handy for solving the last edge if you don't already know it; x' R2 U' R' U x R' F' U' F R U R' U'

If there's a two swap, sometimes you will recognise an easy set up to position them both into the U-layer. - And fix parity more efficiently.

And wouldn't the PLL case require the unsolved 2 corners to be oriented?
Yes, it's easier to orient them before the parity alg.
 
Last edited:
If executing corners first:
One thing you could do, is solve all corners accept leave UBR and UBL swapped. The last edge would be solved by setting it up into the U layer and using a PLL.
This is sometimes handy for solving the last edge if you don't already know it; x' R2 U' R' U x R' F' U' F R U R' U'


Yes, it's easier to orient them before the parity alg.
Thanks for the reply Zane. I've been following your TuRBo tutorial. So in terms of parity when you have a 2-cycle remaining, you solve that 2-cycle using UBL as the third piece (assuming UBR as buffer), thus swapping UBL/UBR and solving that arbitrary corner. Then you orient them if needed, finishing with TuRBo and a PLL case (T, R1/R2, Jb, or T-Perm+Flip).
However, there are also cases when you can skip this step altogether, and after TuRBo, you toss both the arbitrary corner and edge into the U-layer, doing PLL.

Is this correct?


EDIT: It seems like parity for corners first is less efficient than parity for edges first. Is there a reason why corners first is still the preferred option (for 3x3 BLD)?
 
Last edited:
Thanks for the reply Zane. I've been following your TuRBo tutorial. So in terms of parity when you have a 2-cycle remaining, you solve that 2-cycle using UBL as the third piece (assuming UBR as buffer), thus swapping UBL/UBR and solving that arbitrary corner. Then you orient them if needed. Continue with TuRBo and then do a PLL case (T, R1/R2, Jb, or T-Perm+Flip).
That's right.
However, there are also cases when you can skip this step altogether, and after TuRBo, you toss both the arbitrary corner and edge into the U-layer, doing PLL.
I'm fairly sure Ville does this.
EDIT: It seems like parity for corners first is less efficient than parity for edges first. Is there a reason why corners first is still the preferred option (for 3x3 BLD)?
Hmm, a lot of people probably find it easier to memorise corners last and solve them first. I don't have a good answer for this.
 
Last edited:
That's right.
I'm fairly sure Ville does this.
Hmm, a lot of people probably find it easier to memorise corners last and solve them first. I don't have a good answer for this.
^ Thanks for the help!
Corners vs Edges First seems pretty interesting. I checked out pretty old threads debating it, and it seems that the problem is having 8 corners as opposed to 12 edges in your short-term memo. However, this doesn't imply that corners first is optimal.
This is because letter pairs for corners would result in a much faster long-term memo than letter pairs for edges (since you have 3-4 pairs as opposed to 4-6 pairs). So the long-term corner memo would make up for the short-term edge memo.
 
Alright all of you people who know blind. I NEED YOUR HELP. *WARNING BEGINNER BLIND CUBER IN DISTRESS* anyway I need help with the memorization. Say for example a cycle Buffer--->FU--->LD--->DR. How would you memorize this? Would you take like the first letter of each edge (FLD), or would you give give each edge a letter? This way it would become some random combination of letters? I honestly don't understand how to memorize the cube. :P If you could help shed some light, it would be greatly appreciated! Thanks~ Happy Cubing
 
I have a letter scheme from A to Y (skipping X) for the edges of the cube, and I memorize in letter pairs. So FU->LD->DR would be C-K-V which I would memo CocK V (and whatever the next letter was would pair with V to make a word or sound)
 
I have a letter scheme from A to Y (skipping X) for the edges of the cube, and I memorize in letter pairs. So FU->LD->DR would be C-K-V which I would memo CocK V (and whatever the next letter was would pair with V to make a word or sound)
Oh! I get it :P Thanks! Hey just curious why would you skip "X"?
 
Why not skip Q also then? Surely Z is easier to make words with than Q. Also, for optimality in letter cases, you should be able to skip lettering your buffer piece so you can take out two more unwanted letters, bringing a total of 22 stickers to letter.

EDIT: Just looked it up. The four least commonly used letters are J, Q, X, and Z. So a scheme of 22 letters without these 4 would be pretty optimal. However, it really doesn't matter as long as you can make some association with whatever system you currently have (or will have).
 
Last edited:
Back
Top