AudioBanter.com - View Single Post - Studio wiring advice for newbies by newbies

On 27 Jun 2004 11:54:49 -0400, (Mike Rivers) wrote:

In article am writes:

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.

Good in theory, but unless you're a highly disciplined programmer
working in a shop that goes strictly according to process, almost
every design "improvement" has an effect on functionality. Hopefully
it's positive, but not always, and sometimes some of the goofs slip
through because nobody ever thought that a user would try whatever
doesn't work.

Actually, there are a lot of us programmers who have learned that strictly
following processes that divide up refactoring and improvement stages are well
worth doing, and we do it pretty rigorously.

Refactorings are, by definition, things that should not affect functionality
unless done wrong, such as finding 2 blocks of code that do the same thing,
changing the code so that they are literally identical (1 step), then moving
the block of duplicated code into its own procedure (another step). This can
be done in conjunction with Test Driven Development in which a test sequence
will have already existed to ensure everything that was completed worked, and
the test sequence can be re-run after each refactoring step to make sure
everything still works. If something broke, your last step was the problem,
so roll it back, and find out what's going on.

Unfortunately, fully automated, complete, repeatable testing is, AFAIK, not
possible with a studio wiring plan. it would be nice if it were.

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

Actually it makes good sense, but with something like a patchbay, you
don't really need to test the electrical continuity (which doesn't
change since you're using the same wires and the same jacks), you need
to test the user interface - do you REALLY want to have that patch
point in a different location all the time?

Ah, but it's not the same jack, and was the module properly normalled? Is it
the same wire, or did I use a different cord because it needed to be longer?

Last night, in fact, I spent a lot of time tracking down a problem that could
have been more easily caught if I'd done better tesing as I went. I had a
point that was supposed to be non-normalled, and I tested it only after
patching the top and bottom points together for both left and right
connections. I should have tested the normal case first (no sound), then the
left, then the right.

Later, when the points were unpatched, there was still sound coming to the
main mix on the right channel! I didn't think of checking the patch point for
a while, and of course, when I found it, I had to unhook all the wires from
the patch point, get behind the rack with a flashlight, and turn the module
around while the band waited for me.

Keep simplifying:
After wiring, look for things that are complex or deviate from the standards
and don't actually need to be that way.

If you set standards to begin with, nothing should deviate from them.
The problem with patchbays is that most of the ones we use in studios
is that they're constructed with two parallel rows of jacks, and
there's presumed to be a direct relationship between the two rows. If
you have, for instance, more outputs than inputs, you'll have jacks on
the top row that correspond to "not connected" jacks below them.
Because we're a frugal lot, we hate to waste those jacks so we connect
something to them that's unrealted to the jacks above them and there
goes the system. While you can remove the normalling in most patchbays
so you don't have a connection that you never want, it does make
things hard to find.

I should have been more clear. Yes, as I said in my previous post, there are
-rules- that should never be broken, but there are also lesser, target rules
and rules of simplicity that must often be broken because concerns conflict
with one another. This includes things like matching the numbers of the patch
points with the corresponding channel numbers (or offset by 10) conflicting
with a personal rule of having 1-12 and 19-24 1/2-norm, and 13-18 non-norm.
After wiring, it is usually possible to mitigate a couple of these problems,
and after those changes, something is usually freed up to mitigate some more.

Ideally, when all is said and done, the wiring plan looks, for the most part,
very simple and inuitive, though the process to arrive at it might have been
anything but.