Ursa Major documents available on-line

[C M]

Hello,

My name is Chris Moore. I founded Ursa Major and designed the Space
Station in 1978. I have scanned all the owner's and service manuals into
PDF files. These are for all Ursa Major products, not just the Space
Station. You can download them at the URL below.

I have also put information on the site about the new Space Station
SST-206, a handheld unit the size of a paperback book that emulates the
original Space Station, while also offering a knock-out contemporary
quality reverb program. I am manufacturing and selling these from my web
site.

You can also find a history of the Space Station, reviews,
advertiserments, photos of reverb pioneers, and the demonstration
cassettes (mp3.

Finally, there are a dozen articles ("Application Notes") that reflect
my experience and beliefs about new product development, audio products
in particular.

Sincerely,

Chris Moore


--

Seven Woods Audio, Inc. Christopher Moore
Concepts, Products, Circuits for Audio Analog/Digital

http://www.SevenWoodsAudio.com

[WillStG]

<< C M (Chris Moore wrote)>>
<< I have also put information on the site about the new Space Station SST-206,
a handheld unit the size of a paperback book that emulates the original Space
Station, while also offering a knock-out contemporary
quality reverb program. I am manufacturing and selling these from my web site.
>>

Is the reverb anything like the AKG ADR68k? Those were of the Ursa Major
lineage once removed, weren't they?



Will Miho
NY Music & TV Audio Guy
Fox And Friends/Fox News
"The large print giveth and the small print taketh away..." Tom Waits

[Mike Rivers]

C M > wrote in message >...

> Finally, there are a dozen articles ("Application Notes") that reflect
> my experience and beliefs about new product development, audio products
> in particular.

Very cool writings. I've always thought that there should be a closer
tie-in between the instruction manual and the product specification. I
have dreams of working in an environment where this can happen, but
sadly most development of contemporary mainstream audio products goes
like this:

1. Marketing publishes the ad copy.
2. Engineering develops the advertised features until the product
reaches the target price.
3. Production begins
4. The preliminary manual is written at least a week before shipping.

[Bill Thompson]

Hi Mike,

I think most folks who have been through any kind of product development
cycle would love to see a closer tie-in between the product and the
manuals... but this is one of those things that actually can be quite
tricky!

In the late 80s I went to work for a company that was supposed to tale
the telecom market by storm... long story short we developed a switch
that couldn't be built. Oh well.

One of the things that I thought was incredibly clever was that they
hired a technical writer at the onset. I think this guy was employee #4
after two hardware engineers and a software engineer.

At first glance you'd have to say "Wow... very smart!" Especially if
you've ever been exposed to the old Bell System Practices<G>!

Here's what really happened... sadly the writer spent a LOT of time
sitting around until he became quite disgruntled, bored, frustrated, and
probably a few other conditions. He ended up the first person to quit
the company. He had completed all the necessary practices, and he had a
really good start on the user documentation.

Part of the problem was that he was so desparate for information that he
started digging through peoples desks for notes and developer docs. When
we discovered this, the result of him writing about features that didn't
actually work, we locked our desks. He became paranoid, and the whole
environment became quite unpleasent.

He was a very good writer, and a very good guy. I'm not sure I'd have
lasted as long as he did, it must have been quite furstrating to come to
work each day and do very little.

My point, if I have one, is that the schedule you documented, while
probably true at some places, does exist in one slightly more rational
form or another at most companies simply because the marketplace demands it.

Yes, it really is our fault. As consumers we want the next cool thing
for half the cost of it's predecessor, and we want it today! That makes
it quite difficult for developers to develop, writers to write, and
testers to test. Remarkably, most companies have maintained their
commitment to testing, but writing seems to fall by the wayside.

I don't know how one handles the "conflicts" at the startup level, but
it seems to me that established companies ought to be able to manage it.

Bill

Mike Rivers wrote:
> Very cool writings. I've always thought that there should be a closer
> tie-in between the instruction manual and the product specification. I
> have dreams of working in an environment where this can happen, but
> sadly most development of contemporary mainstream audio products goes
> like this:
>
> 1. Marketing publishes the ad copy.
> 2. Engineering develops the advertised features until the product
> reaches the target price.
> 3. Production begins
> 4. The preliminary manual is written at least a week before shipping.

[Mike Rivers]

Bill Thompson > wrote in message >...

> I think most folks who have been through any kind of product development
> cycle would love to see a closer tie-in between the product and the
> manuals... but this is one of those things that actually can be quite
> tricky!

.. . . . .

> Here's what really happened... sadly the writer spent a LOT of time
> sitting around until he became quite disgruntled, bored, frustrated, and
> probably a few other conditions. He ended up the first person to quit
> the company. He had completed all the necessary practices, and he had a
> really good start on the user documentation.
>
> Part of the problem was that he was so desparate for information that he
> started digging through peoples desks for notes and developer docs. When
> we discovered this, the result of him writing about features that didn't
> actually work, we locked our desks. He became paranoid, and the whole
> environment became quite unpleasent.

Sounds like he started on the project too soon. Actually what I like
to do is to start writing the manual when the product specification is
frozen (at least until the ECOs start coming in). That way, you can
describe how the product is supposed to work, and the designers are
working from the same script to make it work that way. All too often,
though, the product spec never gets written until the design is
finished, and they write the spec based on what they designed.

> Yes, it really is our fault. As consumers we want the next cool thing
> for half the cost of it's predecessor, and we want it today! That makes
> it quite difficult for developers to develop, writers to write, and
> testers to test. Remarkably, most companies have maintained their
> commitment to testing, but writing seems to fall by the wayside.

Well, sort of. Sometimes the beta test program gets managed by the
sales department. <g>