How I post these entries

There is a problem with all these web-based communication
tools (websites, webmail, twitter, facebook…) for people who
learned to use computers back in the good old days. The easiest
way to type information into a computer is to use emacs, and many
of the people who design these things don’t seem to understand
that.

Of course, the people who use emacs are very clever at getting
around this problem, and there are by now good solutions for the older
tools:

  • Gnus will read and
    write email with any mail technology that uses standard POP or
    IMAP interfaces.
  • Tramp will let you
    edit a file on any computer that you can get to via any normal
    protocol.
  • Psgml is pretty
    good for editing html pages.
  • SQL
    mode
    will let you manipulate a database on any machine you can
    get to.

Blogging isn’t as old a technology as the things above, and
while there’s been some work on packages that will let you open
a buffer and then post its contents directly from emacs, I
haven’t made them work successfully. I’m not alone — this
post
by a frequent contributor to the emacs newsgroups
suggests that he ended up with the same solution as I did, after
much the same problems with the packages.

Of course, there are lots of other ways to work posting besides
doing it directly from emacs. For a while, I was invoking an
emacs client from firefox via a program called mosex, which is
hard to find on google because the Museum of Sex in New York
uses mosex as a nickname. But I think mosex stopped working on
some firefox upgrade, and having emacs clients hanging around
was a bit of a nuisance.

So what I do now is just open an html file on my own computer,
edit it using psgml, and then mouse the results into the normal
WordPress admin page, trying to remember to set the category and
the keywords every time.

Following up

Logitech 550

I said in my first post about my
Logitech Universal Remote that there wasn’t an easy way to program it
under Linux. Further googling revealed that it might not be as
hard as I thought, since the actual interface is actually through
the Logitech web site
and you only need the command line to upload a file to the
remote. I have now tried this out.

I started with these ubuntuforums
instructions
for installing concordance and congruity. I haven’t had a lot
of luck getting udev to let me use devices as a user, so I also
used these
instructions
for running the programs as root.

The upshot is that it didn’t work. The web interface for telling Logitech what you want your
remote to do is the same as what you get running the program on
Windows, but on my system, running congruity on the file the web
program gives you to download doesn’t seem to change what the
remote does at all. YMMV.

But the good news is that the Logitech website does save
everything you did, and when you run their program on Windows, you
get the work you did on the website. So you can
do your programming at the logitech
site
, and then run the windows program to update the
remote.

So I have now fixed some of the problems I reported in my last
post
, about the volume control on the DVD and the aspect ratio
on the TV set.

Scores

The advantage of posting emails
to lists is that you do get comments on what you said. A couple
of people pointed out that you can get good scores out of
lilypond; it just takes some tweaking. I replied that I had
assumed that (and in fact I do it sometimes for non-renaissance
stuff), but that for me the badness of Lily’s scores is a feature,
since I don’t believe people should play from them.

You can read the whole thread (quite rambling) in the
lilypond-users archives for yesterday
, starting at the
contribution before mine in the thread titled “Re: Review of
Valentin’s opera”.

Transcription of Weelkes

I have uploaded the transcription I talked
about on Tuesday.

Taxes

I made a quick post yesterday on the
grounds that I had to go do my taxes. I spent about 4 hours, and got the essential work done. There
will be another session for filing when I get an answer to a
question from my financial advisor, but the fiddly stuff about
finding all the records and adding up all the little pieces is all
done.

The Amazon Download seemed complicated
compared to putting a CD into a drive, but maybe it’s because I’m
not really used to doing much on Windows. Once you got the tax
program downloaded (which required installing the Amazon download
program), you had to find the setup program, which they gave you
the filename of in a text document, so you couldn’t just follow
the link.

TaxCut made one fairly major blunder
which if I hadn’t caught it would have cost me several hundred
dollars in taxes and penalties. It didn’t ask me if the money I was withdrawing
from the Roth IRA was taxable or not, and just assumed it was.
I’m sure this is a bug. It took a bit of clicking to find the
place where I could enter the basis of the IRA, but I think I have
a reasonable number for the taxes now.

MLB TV

I implied a couple of weeks ago that I
didn’t think the MLB TV worked
very well. One of the things I had on while doing my taxes was
the Spring training game between the Red Sox and the Mets, and the
quality on my Mythbuntu box with the DVI
connection to the TV was quite acceptable.

Transcribing from facsimile

It’s Tuesday, which means I have to get ready for the Cantabile
Band rehearsal, and I just finished guessing where to add time in
the parts for the facsimile I’m transcribing.

I had planned a nice post about my marathon train ride through
Germany, but it’s going to take until well past lunch to write,
and I have other things to take care of.

So that one goes on the spindle, and I’ll just tell you how
much I marvel that they ever got any part books right before there
were computers to take the notes from the parts and combine them
into a score for them.

It’s also surprising that the sixteenth century singers didn’t
care more that there were all those mistakes. In the case of the
Weelkes, I think they weren’t really reading the music the way we
do at all — they just learned it to get the basic tune and then
put the parts together they way they had to go. They knew the
style, and so they didn’t need every ending note to be exactly the
right length to know where to start the next phrase.

You’ll be able to see what I’m talking about when I put the
piece I just transcribed up (maybe tomorrow), but there’s an A
section where the parts are supposed to all cadence together, and
a B section where they all end together. In both cases, once I’d
entered the notes as they were in the facsimile, one part was
short — in the A section the cantus was a half note short, and in
the B section the bassus was a quarter note short.

In both cases, if you knew the style and were really singing by
ear, it wouldn’t have thrown you — of course the Cantus goes back
and starts the A section the second time the way it did the first
time, and starts the B section the way it’s written, even if the
Cantus final note should be a half note longer. In the B
section, the Bassus part was clearly doing the obvious cadence,
even though it was written a quarter note short.

So I doubt that Weelke’s singers had any problem with his
mistakes, but the Cantabile Band would have if I hadn’t fixed them.

Website redesign (part one)

I have hitherto avoided inflicting my technical problems on the
readers of this blog, but this subject is what I really need to
think about, so it doesn’t really make sense to go finding other
things to write about the way I did yesterday. I’ll
try to keep the tech talk understandable to the lay user; let me
know if I fail.

This post is going to discuss only the basic functionality of
how the transcribed pieces are described, and how the user finds
them. The other parts of the site will be discussed in future posts.

Why a redesign?

Because the original design has gotten unwieldy both for
me and for the users.

The reason I didn’t add new pieces to the site for over a year
wasn’t that I wasn’t transcribing new pieces, it’s that the
procedure for adding things is quite clumsy. After I changed
computers and ISP’s in August it was clearly going to need an
unknown amount of debugging. The debugging turned out to be small
when I finally got around to it, but adding a piece that’s been
transcribed and proof-played should be just an easy couple of clicks.

For the users, the one-page By
Composers
listing is an increasingly unwieldy way to find what
they want, and doesn’t include all the information they need. For
instance, one of the most-requested things is a way to find pieces
by number of parts. It would also be good to have some idea of
the ranges of the parts.

The original site design did have both number and ranges of parts
when you got to the page for the piece,
but it happened by displaying short excerpts
from each of the parts, which
broke fairly early on, and wasn’t really the right answer for
doing searching anyway.

So here’s my picture of how the site should look:

  • The primary entry to the collection of transcribed works
    should be a search page that allows selection by composer,
    dates, number of parts, instrumentation, country, language, or
    any combination of those things. That is, if I’m looking for a
    trio for voices in German, I should be able to just say, “Show
    me all the three-part vocal pieces in German.” Or if I want to
    know what there is by Billings, I should be able to just request
    that.
  • The current static html pages which are generated from the
    database by a script I wrote, should be generated dynamically
    from the database. (If that doesn’t make sense, see below.) This will make adding a new piece much
    simpler. You don’t want to know what I do now; what I’ll do
    then is run one script which will add the piece to the database
    and upload the files.
  • I think it might make sense to leave both the current search
    pages (By
    Composers
    and By
    Date
    ) there, but of course have them dynamically generated.
    The idea is that for browsing, having a way to look at what’s
    been added or changed since the last time you browsed, or at
    what the distribution of stuff by composer is, is easier than
    just dealing with the search page. Possibly it would make sense
    to add other pages like that, such as “By Country” or “By number
    of parts”.

Static and dynamic

It looks like the major technical jargon I wasn’t able to edit
out of the above was the static/dynamic distinction. So here’s
an explanation.

In general, if you go to a page like www.laymusic.org/directions.html,
it’s static. HTML is a markup language, so the person who
authored the page just wrote text, and then put in some commands
to say things like, “Here’s a new paragraph,” or “Display this
image here.” Then they put that page on the site, and kept
track of where they put it so that they could refer to it from
other pages, or from emails.

If you have 500 pieces, or a couple of blog entries a day, this
might not be such a good idea. So the way most of those sites are
done is that the information you want to maintain about each
individual item is in a database, and
the text you see when you look on the web at that item is
generated by a program from what’s in that database. For
instance, each piece on my site has a title, a composer and a
list of files someone might want to download
in the database, and there could be a program that gets run on the
server every time someone says, “I want to look at that piece,”
that would display that information.

It was even at the time wierd, but when I designed the site, I
did put the information in the database, but instead of having the
program on the server to display it, I have a program that runs on
my own computer that writes an HTML file to display it. This
means I have to rerun that program every time the information
changes, and run the program that generates the “By Composer” and “By
Date” pages every time I add something. This was fine when there
were only a few pieces, but it’s getting tedious now that there
are more than 500, with another hundred or so that I haven’t yet
put up.