[sdiy] A book about analogue synthesizer circuits?

[Neil Johnson]

All,

Thought I'd throw a few ideas into the pool (although sadly at the moment
unable to contribute due to writing up).  I'll have a go at addressing
some of the issues already raised, and see where I go from there.


Hosting/Location/Delivery
----------------------------

Ok, one major point raised was that of where to host this book.  Several
generous people have offered websites, hosting, etc.  But, as already
raised, what happens if that person goes away?  Having a single hosting
point is a source of potential trouble (not saying it _will_, just that it
_could_...)

Perhaps then I could suggest we use SourceForge as the basis for
controlling the page files (TeX, HTML, PDF, GIF, PNG, whatever).  This is
a proven environment, with controllable access, used by thousands of
projects, proven, it works.  I don't mean to diss Jezz's suggestion of PHP
and MySQL hacking, but I think it would be better to use something already
working so we can concentrate on synth DIY!

I like the idea of print-on-demand, especially if we allow for this in the
structure of the book and the chosen file format: think like a book, print
like a book.


Files and Formats
-----------------------

Which brings me onto the next topic---file formats.  *shudder*  The choice
really depends on the output format.  I think there are two viable
contenders: HTML and PDF.  They both have the pros and cons.

With HTML the pages are directly viewable in most browsers, would be
easily accessable to blind readers (HTML->speech), and so on.  Downside is
that the page layout is dependent on the browser, and to be global we'd
need to restrict ourselves to a proven subset of HTML (not a bad thing in
my view).  I.e. no frames, no CSS, no layers, just tables, lists,
paragraphs and pictures.  Speaking of which, JPEG for photos
(lossy-compression fine) and GIF for diagrams (lossy-compresion BAD).
PNG would keep the Stallmanites happy, but not every browser supports PNG.

The other contender, PDF, is perhaps more viable (a modern version of
Postscript, to keep Magnus happy :-)  PDF viewers are free and available
for most desktop operating systems.  By using a precompiled format (rather
than HTML where the browser does the page layout at viewtime) we have
more control over page layout, so stand a better chance of acheiving a
degree of uniformity.

Then we get the issue of page size.  I propose we choose A4---it is an
international standard that most countries (*cough* USA *cough*) have
adopted, so when you print out pages on your printer then what is printed
should match what is on the screen.

Assuming we go the PDF route, the next question is _how_ we generate the
PDF.  Ok, so us lucky Mac owners can just do a print-to-file to generate
PDF, but not everyone has seen the light :-)

With my academic hat on I'd suggest LaTeX as the way forward :-)  It is
platform neutral, the software is freely downloadable (not everyone here
can afford the Microsoft Tax, or even wants to) and is *THE BEST* for
doing anything involving equations, tables, figures, etc.  Practically
_all_ academic papers are written in LaTeX (and you can always spot those
that aren't :-).  Again, as with HTML the idea is that the author
concentrates on the content, and the software concentrates on the page
layout.  The editorial team decides on the "style" (writes a document
style file) and the authors concentrate on the words.

True, there is a bit of a learning curve, but once you get your head round
it, its much better than Word for actually writing (rather than bashing
out three-page company memos).  It is industrial-strength: try putting a
1,000-page book through Word; LaTeX will just sit there munching away util
the job is done.

So. to summarise:
- document souce: LaTeX
- images: probably PS/EPS for reading into LaTeX
- output: PDF


Team structure
------------------

And it is a team effort.  This is going to be a long-term project, with
many, many people involved from many countries.  Therefore the structure
needs to be flexible, with no (or very few) single-point failure nodes.

Also, as already mentioned, this is a hobby, and people's degree of
commitment will vary over time (work, family, etc).  I don't mean this to
sound heavy-handed---quite the opposite: by working as a team we reduce
the burden on everyone, to a level where each member contributes what they
can, when they can, without feeling too much pressure from their peers.

Perhaps a structure something like this:

1. Top-level editorial
    - sets the overall "tone" of the book
    - defines the structure (and changes to it :-)
    - manages the infrastructure (hosting, interfaces, software)

2. Section Editors
    - responsible for individual sections
    - suggesting titles for chapters
    - finding suitable authors
    - maintaining consistency
    - interfacing with the top-level editors

3. Authors
    - responsible for writing one or more chapters
    - must adhere to the guidelines, unless special permission given by
       editorial team (otherwise consistency goes out the window)

4. Technical Reviewers
    - recognized experts in their field who can offer guidance to authors
       and editors on specific topics.  E.g. Harry on BBDs, Magnus on
       maths, Paul on wavetable synthesis, etc.

Oh, and none of this precludes, say, an editor wanting to write a chapter,
or an author being on an editorial team!


Consistency
----------------

Several times I have mentioned consistency.  I think this is vital to a
good book: I think there's nothing worse than a collection of chapters
where each one looks different, uses different fonts or page layouts,
different diagram numbering conventions, section numbering, layout, etc.
For one thing, makes writing the index and contents page a right pain!

Also, from the author's perspective, it makes life much easier if you
already know what you're getting into.  You don't have to worry about
layout styles, or anything like that, and can get on with the actual
writing (the important bit!).  And you know, from looking at past
chapters, what your chapter is going to look like.


Copyright
------------

Oooh, I guess someone has to say this.  Some of us work for companies that
put little bits in employment contracts about technical inventions,
writing, etc., and who owns the copyright in anything you do.  For a hobby
like this, they probably won't be too concerned with what you do, but if
this book takes off and becomes a success (you never know...) they might
want a piece of the action.  I'm not being paranoid, just offering a
heads-up based on previous experience.

As for each author, I think each author should retain copyright in their
own chapters.  Such that each chapter should include a copyright message
on the first page, perhaps a footnote with the relevant legal incantation
declaring the author's copyright, but also stating the freedom of
printing, copying, publishing, etc.  E.g. "Joe Bloggs identifies his
ownership of the copyright of this chapter, but expressly grants freedom
to translate, copy, print and publish this work provided this notice
remains intact."


Language
------------

I think the first version should use English as the default langauge.  Of
course, that should not stop any enthusiastic people from translating any
of the chapters into other languages (hence the "translate" in the above
copyright notice example).


Other Issues
----------------

Religion: I think we should cover both analogue and digital synthesis.
And the fun that can be had comnbining the two :-)  Perhaps we have three
main parts, and an appendix:

Part 1. Fundamentals
        Section 1. Passives for audio
                Chapter 1. Capacitors
                        2. Resistors, including temp.co's
                2. Earth, ground and EMC
                3. Connectors: the good, the bad, the downright awful
                4. Power supplies (good designs, safety, how _not_ to
                     blow your face off with electrolytics)
                5. ... etc ...

Part 2. Analogue
        Section 1. Exponential converters
                2. Oscillators
                3. Noise Generators
                4. Filters
                5. Amplifiers
                6. Envelope Generators
                7. ... etc ...

Part 3. Digital
        Section 1. Technologies (PLD, FPGA, etc, + languages)
                2. Waveform Generators (wavetable, numerical...)
                3. Filters
                4. Signal Conversion
                5. MIDI
                6. ... etc ...

Part 4. Appendix
        Section 1. Useful tables
                2. Popular DIY synth projects
                3. ... etc ...

And so on.  The above is meant as an illustration of a potential
structure.  I was trying to think along the lines of "If I were looking
for some information on X, where in the book would I go to find out
about X and similar topics?"

Anyway, enough from me, time for a cuppa.

And time I got packing for a conference trip to Poland (Warsaw).  I'll be
back next weekend.

Cheers,
Neil

--
Neil Johnson :: Computer Laboratory :: University of Cambridge ::
http://www.njohnson.co.uk          http://www.cl.cam.ac.uk/~nej22
----  IEE Cambridge Branch: http://www.iee-cambridge.org.uk  ----