Older blog entries for kevindumpscore (starting at number 10)

Updated the Alternative Csound Reference Manual to edition 4.19-5. You can download it or read it online. Here's the play-by-play from the news.txt file...

4.19-5 "Stockhausen meets Aphex Twin" Edition:

• Added examples for these opcodes: alpass, bexprnd, buzz, comb, event, expon, exprand, expsega, expsegr, flanger, gauss, gbuzz, line, linrand, linseg, linsegr, lowres, lowresx, mandol, mpulse, noise, pcauchy, pluck, poisson, rand, randi, streson, unirand, vlowres, and weibull.

• Updated the examples for these opcodes: betarand, butterbp, butterbr, butterhp, butterlp, cauchy, expseg, fold, gogobel, marimba, randh, repluck, resony, reverb, rnd31, tempest, trirand, vibes, waveset, wgbow, wgbrass, wgclar, wgflute, wgpluck, and wgpluck2.

• Pieced together the missing documentation for the event opcode. Thanks goes to Matt Ingalls for helping me fix my example.

• HTML edition: Gave every command synopsis a normal format instead of a verbatim one. Got rid of the shading on programlistings.

• Added the "marmstk1.wav" audio file to the examples sub-directory.

TeX is supposedly bug-free. IT IS NOT!

TeX is written with hard-coded memory limits. Last night, I changed some of the 16-bit limits in its source code. But when I typed a "make distclean", it erased my entire /usr/bin/ sub-directory! Now I no longer have a gcc proogram.

TeX Sucks!!!!!!!!

TeX sucks! No matter what I enter into my texmf.cnf, I keep getting: "TeX capacity exceeded, sorry [number of strings=51768]." I'll dance for joy the day I can switch from jadetex to a capable Open Source XSL-FO processor!

I saw that the FreeBSD Documentation Project published a 400 page users manual. How did they do it? Where is their texmf.cnf? Which DSSSL stylesheets did they use? Where's the source?

Is anyone working on an Open Source XSL-FO processor that conforms to the 15 October 2001 XSL spec? I'm maintaining a 500+ page manual and FOP doesn't work for me. FOP is written in Java and requires way more RAM than I have available. Add to the FOP's problems with table formatting and you have one frustrated dude.

Cactus decided to stick with his hacked-together guikachu-doc XML standard. He will use XSL to convert it to DocBook. XML makes this type of thing straight-forward. But I'm not really interested in helping him write a users manual with guikachu-doc.

NIH (Not Invented Here) syndrome is alive and well in the Open Source community.

I stayed up past midnight converting the guikachu documentation to DocBook. I used the <variablelist> tag but this looks horrible when rendered using pdfjadetex. I tried htmldoc instead and that looks much better.

I emailed the URLs for my work to Cactus but I've yet to hear back. Will my changes be incorporated? Will my efforts be ignored? Stay tuned.

Update! Cactus of the guikachu project just sent me an email. He said I could go forward and convert his documentation from his hacked-together guikachudoc format to DocBook.

I'll work on it tonight after work.

I have been a long-time user of the music synthesis program Csound. It is free-to- use and you can look at its source code but it's not Open Source. It uses an MIT license with a clause that restricts its use to academic and research purposes.

I have been secretly working on converting its 500+ reference manual to DocBook. But since it's not Open Source, it's hard for me to get motivated enough to finish. I keep reminding myself that I'm making it "more free".

Richard Dobson, maintainer of Csound's phase vocoder code, has been looking for loopholes so that they can steal GPL code. To me, this is plain wrong. They need to make Csound Open Source instead.

Of course, this will never happen. Not until some people at MIT pick up the clue phone. If you think going up against Microsoft is hard, try the insular world of academia.

Cactus posted a note on the gnome-doc mailing list asking for documentation help on his project. But instead of using DocBook (the Gnome standard) for his documentation, he is using some home-brewed standard he concocted by himself. Check out this XML document in the "guikachudoc" format (http://cvs.gnome.org/lxr/source/guikachu/doc/resources .xml)

Why are programmers/project leaders so afraid of DocBook?

What if every single Gnome program has its own ad-hoc documentation standard? That would be a maintenance nightmare. We need a standard for Open Source documentation! DocBook is what most of the major projects use.

His project, Guikachu , does seem cool though. It's a graphical editor that helps one design screens for Palm PDA programs. If you've ever typed PILRC resource files by hand, you'd realize that this program is a major time-saver.

Another project shot me down this past week. John Lazzaro of the sfront project wasn't interested in using DocBook. He wanted to keep his reference manual's horrendous HTML layout.

This layout is horrible (http:// www.cs.berkeley.edu/~lazzaro/sa/sfman/), it uses multiple tables with two separate running columns. The tables break in strange places. Sometimes the columns are only tenuously related to each other. It doesn't make any sense. Attempting to read it gives me a headache.

At least he keeps it up-to-date, uses FDL, and provides a way to look at it off-line. IMHO, that puts him light-years ahead of most Open Source projects as far as documentation goes.