For a rookie, you have done some good things in your VI. the fact that you used a single constant (4) and based everything off that is a good sign. Some folks would have plastered "4"s all over, then when it comes time to change it....
However, I will point out some flaws:
1... You write a local variable ("Samples(1)") and you read it in the same diagram, without any dependence between them. This is ALWAYS a bad idea.
A) No guarantee is made as to which occurs first: the READ or the WRITE. Even if you run it 4000 times with trace-lighting on and it works OK every time, that does NOT mean it's OK to do. If you run the code on a different platform, or change the code, or LabVIEW versions change, it might not work the same. By making them independent, you are telling LabVIEW that you don't care which happens first. But you do.
B) In this case, you don't need to. Use a wire. You gain nothing by using the local.
2... Part of your code is VERY misleading. I just realized that #1 above is not true, because of this. It certainly LOOKS like you are READing the NUMCOLs, adding one, and WRITING the SAMPLES control, because they are arranged that way, left to right. But if you check out the wires, you are actually READing the SAMPLES control (on the right), adding one (in the middle), and WRITing the NUMCOLS (on the left). This code works exactly correct, but LOOKs odd, because it's right - to left. The left-to-right convention is meaningless to LabVIEW itself, but we poor humans benefit from it.
3... You can change the SAMPLES control while your program is running. The inner loop will react to the change, because you read the control in every loop. Whether that's good or bad is up to you. However the part that sets the NUMCOLS to match is only executed once, and will not react again. I would suggest that you decide that you DO or you DON'T want to react to changes in the control while running, and change BOTH things accordingly. If you read the control OUTSIDE all the loops, you will read it only once.
4... There's a lot of code that is common between the TRUE and the FALSE cases in your inner loop. Consider pulling the common code outside, and putting only the things that are different inside.
5... You use a field width of 8 for your number-to-string conversion. That makes things line up if you use a monospaced font, but uses a lot of characters (it takes 8 characters to display a 0). Since you're putting it into a table anyway, do you need to do that?
6... The sheer number of matrix operations you are doing is suspicious to me. I didn't trace it all out, but the fact that you reshape the array, transpose it, extract portions, and re-transpose them, just screams at me for another look. I would bet you could do what needs doing in a simpler way. I don't mean that I think it's wrong, but I have a hunch it could be simpler. And simpler is almost always better.
I don't mean these as negative criticisms, just food for thought.
