Archive for May 2008
Jot down that melody
Have you ever conjured up a simple tune in your head but felt like big hammers were a bit inappropriate to jot the melodic thought down? There exists a wonderful thing called LilyPond which takes a TeX-like syntax for music composition and not only renders a neat little PDF or postscript of the score, but can also create a MIDI file of the tune that you can play very easily with a program like Timidity (this program allows you to avoid the sometimes tedious configuring of hardware and software to do MIDI synthesis that comes second nature to more seasoned PC audio folks). Here’s a simple example of how easy it is:
Write a super-sophisticated melody to some file called test.ly:
score {
{ c’ e’ g’ e’ }
}
Now, just run:
$ lilypond test.ly
and it will produce a test.pdf (and postscript) file that looks something like:
Now to create a MIDI file simply add a directive to your file:
score {
{ c’ e’ g’ e’ }
midi {}
}
and rerun the command above. It will produce a MIDI file. If you’d like to hear it with software-synthesized goodness:
$ timidity test.midi
Timidity can, of course, output to WAV or OGG and whatnot for you.
High-level UI translation
With all the rave on generic higher-level interfaces looking more native to the host OS (as opposed the more free-form interface experimentation and design with generic low-level interfaces), I wonder if there has been much work done on actually translating the high-level widget description to OS (widget toolkit)-specific code with function-call bindings for events. This is clearly doable considering Firefox already defines these bindings for the three major OSes. OS-independent GUI code can then be translated into a native look and feel while not sacrificing efficiency because the interface description compiles to native OS widget code.
Not that I’m super-thrilled about the “widget-based” standards we’ve created for high level interfaces these days, but it’s a thought….
Update: WxWidgets seems to do the trick.
Systematic learning vs. motivated problem solving
Warning: what follows is a hand-wavy one-sided monologue, continue at your own risk!
It seems that the most appealing and productive way for someone like myself to learn and explore is via solving a somewhat concrete problem that motivates me (e.g. a sampling of the links on the sidebar of this log). Regardless of the fundamental and pure aspects of this motivation, I find that I learn a lot along the way and other interesting problems and doors open–natural extensions to continue doing more interesting work.
So it’s tempting to say, “this is ideally how I should learn: through some form of personally-motivated problem solving,” trusting that this approach will fan out more and more interesting work potentially even covering a lot of ground that I would come across in more artificial, in-order perusals of self-contained texts. Fueling this temptation: since more introductions, review papers, and articles are available online, we may not be as dependent on self-contained texts and can actually tackle a subject at hand (for instance, read the preface here).
While this may be a sensible approach in principle, its limit in scope intuitively ignores two important things which motivate the rest of the entry: (1) like any sport, a push or even nudge of systematic self-contained learning goes a long way in growing more rapidly and increasing competence and (2) in reality abstractions are built and reused in ways that are dependent on one another, so students must take classes on well-defined subjects, professors must teach them, and professionals often end up becoming specialists/experts naturally, or are forced to take “mandatory” training to learn their craft.
Thus, regardless of what’s ideal, simply working for the man may require a more systematic approach to learning material. How this is approached by students seems to be a problem. Most students, for example, may see tough, self-contained classes as a chore or measure of performance, even if aspects of the material interest them. A systematic introduction to a topic meant to fuel thought and cover some potentially very good concrete examples in a breadth of topics in reality just implants the existence of a few keywords, or better-yet, a concept or two. My hunch is this is what the modern teacher/prof settles for in the general student (understandably so, there are often a lot of students per professor).
If I were to have a point (hopefully you don’t assume I need one, especially in a web log entry), it would be something like, “some students either blame themselves too much or not enough; they are either too hard on themselves for not understanding something they find difficult or, equally as bad, assume that something is wrong with the way a class is being taught.” If the systematic learning is approached by the student in less of a pressured or stand-offish way and in more of a, “well, I’m somewhat interested in/required by the man to learn about this, let me be open to the concrete examples and approach them curiously,” then systematic learning may not only prove to be less of a chore and more interesting, but also be a healthy push in an interesting direction.
Keep in mind that I say this as a student benefiting from this attitude for some time, though not nearly long enough.
The Structure and Interpretation of *
For a while now I’ve been meaning to note a couple links that may be of interest. Some computer science undergrads are familiar with a happy-little purple book by Abelson and Sussman titled The Structure and Interpretation of Computer Programs (SICP, pronounced “sick-pea”) [1]. For those of you who don’t know, if you click on that last link, you’ll notice the entire text is available online, which is great because this book is a superb reference (at least it has been for me). SICP is known for its usage of a LISP-like variant: Scheme to introduce a precocious individual to computer science.