"are you going to write a book?"

At 03:29 PM 2001-10-17 -0400, The Danimal wrote:
>4. Sean, are you going to write a book on MIDI-Perl?

Short story:  No, but you should!
A little digging reveals that the story behind a lot of excellent books is
"I wanted this book, and no-one had written it, so I had to write it!".

Long story:

Definitely not.
Not because it shouldn't be written, but because I shouldn't write it.

If there is a theme emerging in my Perl Journal articles (www.tpj.com),
it's that you don't have to be an expert in a thing to write a module that
deals with it.  (You just need lots of testing.)  I don't really know
Braille, but I cowrote an article about turning "flat" text into Braille.
I don't have any firsthand experience with perl opcode trees, but I wrote
an article about them in relation to constant folding.  I can't read
Chinese or Japanese or any of the dozens of non-Roman writing systems in
Unicode, but that hasn't stopped me from writing Text::Unidecode, plus an
article about it (in the next TPJ).

And MIDI-Perl is an extreme case of that:

My musical education ended in primary school, leaving me with now-vanished
memories of fingerings on wind instruments, and lingering notions of how to
make basic kinds of chords on a piano keyboard.  I still don't /really/
understand (in a working or sensory way) the concept of keys, I could only
ever read the treble clef, and my classificatory concept of time-signatures
consists only of 3/4, 4/4, and Weird.  My unenthusiastic attempts at
learning a wee bit of music theory from books have been like trying to
learn architecture from cookbooks.  (Or cooking, from blueprints.)

Moreover, if one can say that an artifact is definitively "for" some
purpose, I think that MIDI::Simple is "for" composition, specifically
whatever kinds of composition you can do without improvising on a keyboard
and other instruments and saying "OK, /that/'s what I want!".  If playing
until it's right is what you want, there's no end of programs and devices
that can manipulate (and even transcribe) that.  I figured out that one
niche that MIDI::Simple could definitely fill is where you don't have a
tune in mind, but want to try algorithms that can generate tunes.
MIDI-Perl just sort of felt like it needed doing, and as it filled out, it
ended up looking like very format composition was what it could specialize
toward (at least via MIDI::Simple).

I mention this because:

1) I really haven't the faintest concept of composition.  I have never
wanted to compose music, any more than I've ever wanted to mix a perfume,
or mix a new color of paint.  I appreciate music at least as much as I
appreciate perfumes and colors of paint, but making it is just not
something that occurs to me.  And that means I have no /experience/ in
composition.

2) Moreover, I have even /less/ of an idea of algorithmic composition.


Now, if there's one skill I have learned to hone over the years, it is
intuition for detecting a few particular kinds of frustrating situations,
which come up a lot in academia as well as in open source, at times:

A) A situation where everyone has interesting stuff in their heads, and
talks a lot, but somehow the things they're talking about don't actually
express anything like a wide range of interesting thoughts, and so ideas
aren't really brought out and honed and rearranged.  (And new people can't
easily pick up the field either, which is a bad sign.)  Example: a lot of
bad art history, where people that know about thousands of years of art and
history, will write incomprehensible papers about the things no-one cares
about, expressing it in terms of things that no-one is familiar with.

B) A situation like A, but worse, where everyone has a lot of interesting
stuff in their heads, but no-one does /anything/ with it.  The ideas get
stale (and probably never develop right in the first place, since they're
never tested and added to in any mature way), and the people die.  This is
a lethal situation for a discipline, because the people who occupy the role
of "leaders in the field", by merely being there, keep others who would be
more productive out of that position.

C) Like A or B, except that it's not that people are derelict or
unexpressive, but because the field is just hard to say or think anything
about.  To an extent, that's what's /really/ going on in art history: it's
just hard to talk about art without saying very simplistic and subjective
and/or obvious-seeming things.  So people allay their fears of doing that
by being oblique and obscure.

D) A situation where the central topic (whether it's algorithmic
composition, markup language design, or natural language processing) just
seems untreatable with one grand answer, but which you can attack with
different kinds of hacks.  What people want to do (or should want to do) in
this situation is to get up and say they came up with this system that
seems to work okay for what they wanted and might work for a few things
that others want too.
However, Western academic culture tells us we should be after The Truth,
and that is very frustrating to situations where people know they have only
partial solutions, because if you get up and talk about your partial
solution, you worry people will think you're saying that it's The Truth (or
The Answer) and will say "But that doesn't work for [laundry list of
things]", at which point you say "I know", and there's an awkward silence
and everyone is uncomfortable.
So everyone assumes that they're just some neophyte (so what?) AND that
somewhere else there's The Experts (but there aren't!); so everyone keeps
quiet, and without encouragement, everything that's learned is forgotten.

I think that instances of Situation D are rampant in open source
development in general, and in many parts of music too.  It's a very bad
situation.  The solution is to charge ahead anyway.  If you don't meet any
"experts", start assuming there aren't any.  If anyone points out that your
grand plan is only a partial solution, just say you know it's only a
partial solution, and you were just curious to see how far it would be
stretched.  If anyone says "Have you read...?" and lists off seven things
you've never heard of, instead of thinking that THEY CAUGHT YOU and exposed
you for a neophyte, just say "Nope, I've never read it/them.  What are the
relevent points?".  Then they tell you, probably saving you the work of
actually reading that stuff!  (Or giving you a toe-hold for skimming it.)


So back in the real world:  People should write about MIDI-Perl.  Write for
TPJ, write for Perl.com, write for music journals, write for anyone who'll
stand still for it.  If you've never written for a journal/etc. before,
cook up some notion of your target audience (musicians versus not,
programmers versus not), and settle on your article is expressed as "here's
how you can do it" versus "here's how I did it", and GO TO IT.

I don't know much about book publishing (even tho I'm working on a book
about LWP), and I don't know much about the field of music books, so I
don't know if there's a chance for a book about computer music with
MIDI-Perl or similar systems.  (Or analysis of music as read in thru
MIDI-Perl, or modification of music via MIDI-Perl.)  If so, I bet it would
best be done as one of those Wrox- or SAMS-style multi-author books, where
you just get a book on the shelves really quick by just having a dozen
people each write a chapter on some specific topic.  I wouldn't have much
to contribute to such a book, except possibly for my old TPJ article about
MIDI-Perl.
There's /lots/ of programmers who are musicians, so I think this idea has
legs, especially if someone could muster the slightest tie-in with
generating video game music -- something I know even less about, except to
note that the first aleatoric music I ever heard was video game music, as
generated by the old Electronic Arts game "Worms!".  Anyone remember that one?


So, over the next few weeks, I want everyone withing the sound of my pixels
to think of something kooky they've done, or can do, with MIDI-Perl or some
system like that.  Email the list, and we'll see what comes of it.  No idea
is too stupid, no code is too messy.  Four people all attacking the same
idea is officially okay.

Random trial idea:  interactive genetic-algorithm algorithmic music -- an
algorithm spits out several sets of parameters, and for each a bit of
music.  You say which you like, and it elaborates on those, discarding the
others.  Sort of like a genetic algorithm, except that it's a person
(occasionally?) culling the alternatives.  How long would it take for this
to go from random noise to interesting music?  Or vice versa?  There's any
number of parameters to play on here:  disonnant/not, 12tone/not, favorite
chords/intervals in order of preference, degree of syncopation.  It'd be
nice if someone got aleatoric percussive music going, too.


To paraphrase Eno (/Year with Swollen Appendices/, a must-read book about
the creative process), you're likely to get a better result if you don't
start out calling it truth/art/science.

To paraphrase Eno again:  everyone waits for a genius (one person with
amazing individual intelligence) to solve things, but many/most problems
get solved better/faster by "scenius" (a whole "scene" of people jabbing
away at a problem and collectively making headway).


--
Sean M. Burke  sburke@cpan.org  http://www.spinn.net/~sburke/

• Chord module? And some drum programming examples. by The Danimal
• Re: Chord module? And some drum programming examples. by Sean M. Burke
• "are you going to write a book?" by Sean M. Burke