[sdiy] Block based design was: Favourite VCO designs

[cheater cheater]

On Thu, Feb 25, 2010 at 13:33, Scott Nordlund <gsn10 at hotmail.com> wrote:
> Power supplies are regulated and decoupled, inputs and outputs are
> buffered, cabinets and cables are shielded.  Thus your synth patch
> will sound approximately the same regardless of the freshness of
> the milk in your refrigerator, and doesn't depend a great deal on
> the phases of Jupiter's moons.  These things, being a part of the
> same universe, are interacting, but not in any meaningful or
> measurable way.
>
> Well this doesn't always work out perfectly.

Yup!

> Older electronics
> with less "ideal" components (vacuum tubes, etc.) don't conform so
> well to this, sometimes with noticeable effects.  But I can assure
> you that these things weren't a part of the design process.  And
> it's a total crap shoot whether this makes a positive or negative
> contribution to the end result.

Oh but that even happens in the newest DACs and such other stuff. For
example if you use single-ended signaling you're bound to have some
problems in bigger (physically bigger) equipment because ground
reference isn't exactly the same everywhere. Whether they are really
problems or not just depends on how precise you want your gear to be.

> The solution?  Yes, absolutely think of things as completely
> separate blocks, and design them so that they will stay that way.
> Of course there is potential for unanticipated effects, and we
> must be prepared to deal with them, but with a decent design
> process there's no need to invoke that sort of thing on a
> regular basis.

I think it's a worthwhile matter to be aware of *all* the things that
can normally make your blocks interact in non-obvious ways. For
example:
- grounding scheme
- EMI (even if your stuff is shielded, there are better and worse shields..)
- supply voltage fluctuations
- heat
- above-zero-frequency content in voltages and currents that are
supposed to be ideal DC
- aging

Do work in blocks but when designing a block go through all such
issues (can someone identify more such things? I'd be interested).
Then check if they really are not a problem...

This sort of approach helps me work with computer programs. For
example last year I was working on optimizing a website framework. One
of the caching algorithms worked perfect in ideal conditions, but as
soon as all the parallel requests to the website were analyzed as a
whole parallel supercomputer, you could make out a race condition
which routinely stalled tens of thousands of pounds worth of hardware,
every half an hour, until the whole system was restarted.

D.