On Fri, 25 Jun 2004 08:23:54 GMT, Steve Jorgensen
wrote:

Hi all,

I just realized I'm at that early stage in learning to wire a medium ambitious
home studio where I'm experienced enough to have some advice, but not so
experienced that I forgot one even needs to mention these things, so it's a
great time to share. If this makes anyone else think of good advice in a
simiar vein, please do share, or if anyone disagrees with any of this, I'd
love to know.

I have found that the following rules save so much time in understanding and
using the studio that it even ends up saving vast amounts of time just in the
rest of the wiring process itself because you don't have to repeatedly trace
things down to recall what you were doing or find out what didn't get done the
way you thought.


I thought of some more...

Sticky notes:
When doing the actual wiring, and prior to finalizing, put a sticky note at
every point saying where the signal comes from or goes to, via what other
points. If you change a routing, change the sticky note, and use the -via-
info to see what other sticky ntoes also need to be updated.

Labelling:
After the wiring is doner and finalized (nothing is ever final, but you know
what I mean) copy the info from sticky notes to strips of artist's tape. Make
sure the from/to information is in think black lines you can read in dim
light, and add "via" info in small print, possibly on a second strip next to
the first on a blank plate, or something along those lines.


Refactoring:
My day job is computer programming. There's a rather newish concept in
computer programming called refactoring. Refactoring is making changes that
improve the design, and should have no effect on the functionality. The idea
is that if a new requirement needs a different infrastructure, first get the
infrastructure changes done and tested without actually implementing any of
the new functionality (refactor), then implement the new functionality.
Refactoring is done in the smallest possible steps, and testing is done after
each step. Everything should be just as functional after each small
change/test as it was before.

As an example of "refactoring", I find that I want to group things
differently, and I now want to use patch point 5 for what point 1 was doing,
and point 19 for what point 5 was doing. So, I first move point 5 to 19, test
it, then update all the affected sticky notes. If I get interrupted now,
everything still works, and everything is still properly documented. Next, I
do the same moving point 1 to 5. Now, the refactoring is done, and point 1 is
available for the new functionality it needs to handle.

This may sound a bit arduous and excessive, but it ends up saving vastly more
time than it costs, because when something goes wrong, you know exactly what
the cause is - the cause is the very last thing you changed. Worst case,
change it back, and everything should be OK until you have time to look at it
again. Now, you can diagnose and fix the problem at the first time it occurs
before it becomes vastly more difficult to track down, and before there are
multiple problems masking each other.


Keep simplifying:
After wiring, look for things that are complex or deviate from the standards
and don't actually need to be that way. Fix those. After that, you'll see
some more, fix them. In all these changes, use the refactoring technique
described above.