•
•
•
•
I finished the promised K-20 meter. I imaginatively called it k20, and you can find it at http://hans.fugal.net/src/k20. Here's a screenshot:
From left to right, read average (VU), peak (instantaneous with 26 dB / 3 sec falloff), maximum peak, and overs.
This is pure unadulterated printf() abuse. No ncurses. Not that I have
anything against ncurses, just that I'm lazy. Of course you need an ANSI
capable terminal, but I'm sure you can find one lying around.
Few things about programming (in most languages) are less enjoyable than
writing option parsing code. On the other hand, few things are more irritating
to users than no -h and no options where options are needed (or
underdeveloped option parsers). In few languages is it more painful to do
option parsing than it is in C.
So I did what any sane lunatic would do. I wrote an option parser generator. I think it's quite nice. This input:
usage: foo [options] other stuff
-f --foo bool Short name, long name, type, help text.
-b --bar=name char* This has a required string argument.
-z --baz=decibels int? Optional integer argument
-q --quux=MACH float char*, int, and float are the recognized types
Any line not starting with a dash is copied into the help message verbatim.
becomes this output (a header and source file):
/* This file is automatically generated by opg */
#ifndef _OPG_H
#define _OPG_H
struct options {
int f; /* foo */
char* b; /* bar */
int z; /* baz */
float q; /* quux */
};
/* Print usage and exit(1) */
void usage(void);
/* Parse options, populate opts, adjust argc/argv */
void parse_options(int *argc, char * const *argv, struct options *opts);
#endif
/* This file is automatically generated by opg */
#include "opts.h"
...
void usage(void)
{
puts("usage: foo [options] other stuff");
puts(" -f --foo Short name, long name, type, help text.");
puts(" -b --bar=name This has a required string argument.");
puts(" -z --baz[=decibels] Optional integer argument");
puts(" -q --quux=MACH char*, int, and float are the recognized types");
puts("");
puts("Any line not starting with a dash is copied to the help message verbatim.");
exit(1);
}
void parse_options(int *argc, char * const *argv, struct options *opts)
{
...
}
http://hans.fugal.net/src/opg. Enjoy.
I spent the better part of two days fine tuning my linux audio setup on my MacBook, so maybe I can save anothe MacBook user some time with this post.
The sound card in this thing is an Intel HDA Controller, driven by the kernel module snd-hda-intel. Intel HDA cards (usually onboard cards) are looked down upon and generally derided, and I can testify with good reason. Like all sorry excuses for an audio card, it has only one subdevice which means only one application can use the card at a time. (If you want to know if your audio card is cheap, this is a good indicator—just look in /proc/asound/card0/pcm0p/info for subdevices_count)
Luckily in these modern times, the default ALSA device does software mixing
(dmix), so even on a cheap card you can usually hear more than one application
just fine. No, no, you do not need PulseAudio for this. In fact, PulseAudio
steals the audio card in its default configuration (at least on Ubuntu 8.04).
So if PulseAudio is running, applications that aren't PulseAudio aware (or ESD
aware) will simply not be able to make sound. There are other misbehaved kids
on the block, but they're fairly rare. The difference is that a well-behaved
application will grab the default ALSA device, instead of the first audio
card in the system explicitly, hw:0. PulseAudio in fact advises the use of
this trick, to set PulseAudio as the default ALSA device, which I suppose
explains why PulseAudio grabs hw:0 by default. Unfortunately Ubuntu is only
halfhearted here—it enables PulseAudio but does not set up the default
ALSA device to point to it. So in Ubuntu you need to either set up the default
ALSA device with an ~/.asoundrc that looks like this
pcm.!default {
type pulse
}
ctl.!default {
type pulse
}
or you need to configure PulseAudio to use the default device instead of hw:0. If you are going to be using JACK too (and you want to hear other applications outside the JACK pipeline when JACK is running), I recommend the latter, though if you're twisted enough you might try JACK as a PulseAudio client.
JACK also by default grabs hw:0, because JACK is all
about low latency and high performance and going through dmix adds a layer of
overhead. If you're using JACK, you may be enough of a snob that you're ok with
leaving those non-JACK applications out in the cold while JACK is running. In
fact you may not want to hear Pidgin sounds (for example) at all while you're
doing audio work. Semisnobs like myself, though, might want a compromise.
Setting up my studio just the way I want is enough of a pain, I really don't
want to quit all my JACK applications just so I can listen to Last.fm or watch
sb_email.
Now at this point I would be remiss if I didn't mention the very cool JACK
plugin for ALSA. It allows
you to make well-behaved ALSA applications (the ones that use the default
device or allow you to configure which device is used) go through JACK. I modified my .asoundrc in a manner slightly different from the example given:
pcm.jack {
type plug
slave {
pcm {
type jack
playback_ports {
0 alsa_pcm:playback_1
1 alsa_pcm:playback_2
}
capture_ports {
0 alsa_pcm:capture_1
1 alsa_pcm:capture_2
}
}
rate 48000
}
}
Then if you want to make the JACK plugin the default, you add
pcm.!default {
type plug
slave.pcm "jack"
}
I tried configuring PulseAudio to use the JACK plugin, but it would crash on startup. Last.fm's client also had issues—it will play fine for one song and then crash jackd when the second song starts. So unfortunately it doesn't look like the JACK plugin for ALSA is quite ready for prime time, but you can certainly use it from time to time in applications that let you choose the ALSA device.
Unfortunately, the JACK plugin isn't found in Ubuntu's libasound2-plugins package where it belongs. It's an easy remedy, however, just install libjack-dev and fakeroot, then build the package from source (you don't even have to patch it):
apt-get install libjack-dev fakeroot
apt-get build-dep libasound2-plugins
fakeroot apt-get source -b libasound2-plugins
sudo dpkg -i libasound2-plugins*.deb
Getting Ubuntu to not annoy you constantly about "upgrading" that package is another story.
Ok, so now to the meat of this post. JACK does not work well on this sound card
with its default settings. It either has an insane number of xruns, or it sounds terrible. For quite some time I chased the red herring of the
position_fix parameter to the snd-hda-intel module, and I can report with confidence that on this hardware you don't want to change it from the default (0, which is auto). However, if you are only concerned with JACK, you will want to change it to position_fix=3, which gives rock-solid JACK with the default settings on hw:0. However, although JACK or other direct-to-hw:0 applications sound fine, dmix sounds crackly using position_fix=3. So it's probably not a good all-around solution if you're interested in more than just JACK.
The first order of business in good JACK performance (on any system) is to enable realtime. Edit /etc/security/limits.conf and add something like this:
@audio - memlock unlimited
@audio - nice -10
@audio - rtprio 99
Now (after logging out and back in) you should be able to pass the -R option to jackd and get realtime.
If you do jackd -R -d alsa (unless you use position_fix=3) you will get lots of xruns. The best I have been able to do is jackd -R -d alsa -p 512 -n 4, as it seems that the trick is getting at least 3 periods (and to do that with hw:0 you have to reduce the period size). This works well but qjackctl reports lots of xruns still. Actually, they're mysterious messages like this
delay of 5152.000 usecs exceeds estimated spare time of 4071.000; restart ...
which don't actually cause an audio blip (but you will get an occasional real
xrun). I still need to try the realtime kernel (linux-image-rt package) to
see if that might help here. In my early tests (mostly playing with
position_fix) the realtime kernel was actually doing worse than the generic
kernel, but that was before I learned the number of periods should be at least
3, so I need to test again.
If you run jackd -R -d alsa -d default you will theoretically be able to use JACK and other applications at the same time via dmix/dsnoop. JACK will complain
You appear to be using the ALSA software "plug" layer, probably a result of using the "default" ALSA device. This is less efficient than it could be. Consider using a hardware device instead rather than using the plug layer. Usually the name of the hardware device that corresponds to the first soun
[sic] but pay it no heed, we're doing this on purpose, and actually are able to get
better performance than the hw:0 route (with position_fix=0). That command
will not actually work, though. It will crash within a minute even without any
clients. Again the fix seems to be the number of periods, but this time we can
avoid the excess delay by leaving the period size at 1024 (at the cost of some latency, of course). So, jackd -R -d
alsa -d default -n 4. This is rock solid. It went all night without a single
xrun. (But it wasn't doing much, though Ardour, Aeolus, and Hexter were
"running". I was able to play around with them for a half hour or so with no
xruns before I went to bed.) However, sometime down the road it will miss a
deadline and it will crash. This crashing seems to be specific to using dmix,
usually you'll just get an xrun. The workaround is to use softmode with the
-s switch. Now you can run JACK 24/7 with excellent performance and without
locking other applications out of the soundcard.
So in summary, if you don't care about dmix but only JACK (or any other application using hw:0, which can be all of them if you change your .asoundrc, but only one at a time), set position_fix=3 for snd-hda-intel
e.g. in a file in /etc/modprobe.d/ with a line like this: options
snd-hda-intel position_fix=3, and do update-initramfs -uk all. If you want a
more balanced setup, where you can have JACK running and other well-behaved ALSA applications can use the sound card, leave the module parameters alone and set up realtime and
use the following command to start JACK (or equivalent settings in QJackCtl):
/usr/bin/jackd -R -dalsa -ddefault -r48000 -p1024 -n4 -s
If you want to use PulseAudio in this situation, configure it to use the default ALSA device instead of hw:0.
If you like PulseAudio and JACK both, the ideal situation would be PulseAudio using JACK as a backend, JACK using hw:0 with position_fix=3, and the PulseAudio plugin as the default ALSA device. Unfortunately this is just a theoretical ideal, and doesn't work (yet) because of bugs.
And finally, if you have no or limited use for JACK, but want to use PulseAudio, just change your .asoundrc as above to make PulseAudio the default ALSA device, so that all applications, ESD aware or not, use PulseAudio.
Oh, and I almost forgot to mention the mixer. There's Master, PCM, Front, Surround, Center, LFE, Side, and various toggles. AFAICT the Front controls the internal speakers, and Surround controls the headphone volume. JACK on hw:0 has 8 system ports. The first two correspond to the front speakers and the second two to the headphone jack. When you run JACK on default, it's simply stereo output, and goes to the speakers or the headphones if they're plugged in.
Finally, I regret to report that JACK on default will crash on resume (on hw:0 it won't, at least with position_fix=3).
So now that I'm done with comps, it's time to start doing real research. In my case, that means playing with audio and MIDI.
Specifically, I'm going to be generating preliminary data by recording chromatic scales and musical works on Aeolus, an absolutely fantastic pipe organ synthesizer. I did get it ported to OS X (feel free to contact me about that, or just wait until the next release, he is integrating my patches), and Ardour works in OS X as well. But realizing that I wanted to record the same things with many different registrations (stop choices), I needed a MIDI sequencer, like Rosegarden. Frankly, there just doesn't seem to be anything even close available on OS X that doesn't cost an arm and a leg (at least from a student's perspective). Combined with the fact that the OS X driver for my Radium 61 seems to be buggy, I decided I need to go Linux.
OS X is supposedly the darling of multimedia types, but in my experience there is nothing like the wealth of interesting software available, for free, on the Linux Audio scene. And when it comes to audio stability and low-latency performance, there is nothing like a well-tuned Linux box. In short, I can't imagine doing serious audio work in anything but Linux.
So there are many guides out there for installing Linux on a MacBook, and I won't try to duplicate that information here. What I would like to do is detail what I had to do, and which choices I made.
The first choice is that of partitioning. In the end I decided to share the internal hard drive, giving 10G to linux. It looked like the easiest way to do that was with Boot Camp, although it appears possible without it. But Boot Camp Assistant just would not resize my OS X volume. It would either complain about files that couldn't be moved, or running out of disk space. I thought it might be running programs, so I shut them down. I thought it might be swap space so I rebooted. I thought it might work if I did it from the installation DVD. I thought maybe it needed more free space to do the shuffle. None of these fixed it. So I googled around and found that it might be possible for a file to be locked in position. So I needed to figure out what files were entrenched at the end of my HDD and see if I couldn't do something about that. I came across a not-free defragmenter, iDefrag and fired up the demo. It processed the disk and eventually showed me a map of the sectors of the drive, and mousing over them I was able to see the files using those sectors. Near the end of the drive there were a lot of red sectors that all belonged to Google Desktop. I assumed red sectors probably meant stuff that couldn't be moved, but I couldn't be bothered to look it up. Google Desktop seemed like a logical lead, though. So I uninstalled it and gave the repartitioning a try, and it worked like a charm. Incidentally I like Google Desktop, as also Quicksilver and Spotlight (I use all three, depending on what I want to do), so I'll probably reinstall it. Oh, and I didn't defragment with iDefrag since the demo only defragments drives smaller than 100M. But just try finding that information on their website or in the README.
I then installed rEFIt, which although not necessary is a nice way to bootload a dual-boot system.
I rebooted and chose to boot from CD in rEFIt. Odd, I just get a blank screen and no activity. I know this Ubuntu CD works on this very laptop because I had already tried it. So I rebooted and held down alt, which gave me the Apple boot chooser, and I chose the CD, and it worked fine.
I installed Ubuntu in the usual way. I manually partitioned, formatting the partition Boot Camp made for Windows as ext3 and not bothering with swap (I made a swapfile after installation). I told it to install the bootloader (GRUB) on the partition instead of the disk (the partition is sda3).
When I rebooted, I did the gptsync thing using the rEFIt "Partitioning Tool", which synchronized the legacy MBR with the newfangled GPT. Then I tried to boot into Linux, and again rEFIt gave me a blank screen. I booted into OS X and googled it, finally stumbling across something that said that happened once or twice and then stopped happening. So I rebooted and sure enough, it worked the second time. That's odd, and not the end of booting troubles. Sometimes when booting Linux you get a kernel panic talking about APIC. I remembered this from early experiments last year, so I didn't panic. You just try try again until it works.
I will adorn this blog with a flurry of posts on the rest of my adventures soon, but for now suffice it to say I had Linux installed, and it has come a long way. Ubuntu 8.04 had wireless, multi-finger trackpad tapping (though I prefer two fingers to be the right button not the middle button), basic sound, video acceleration, and even suspend working out of the box. It's beginning to look like I could not only do my research in Linux, but maybe even make it the primary OS on my laptop the rest of the time too.
I wish StuffIt would just die, already. I'm sick of running into .sit and .hqx files. Thankfully these are quite rare, and usually an indication that the project is ancient and unmaintained. If you ever find you do need to open one, though, head on over to The Unarchiver. Do not under any circumstances even visit the StuffIt website. Only you can prevent StuffIt fires!
I'm sick of Firefox asking me if I want to open archive files (zip, tar, etc.) with "StuffIt Expander (Default)". Earth to Firefox! StuffIt Expander hasn't been included with the OS for several versions now. It is not and never will be installed on my computer. Incidentally, it works just fine—opening files with the appropriate application. In other words, Firefox is a big fat liar. But we knew that.
I applaud Apple for finally dropping StuffIt a few years back. There has never, ever been a good reason (other than "I'm stuck in the 1990s OS 9 mac scene") to use StuffIt on OS X. Please join us in the 21st century. Use zip, tar+gzip, or tar+bzip2. Even better (for OS X recipients) use a .dmg. For the love of all that is green, do not do .dmg.sit! You won't get any more compression over a compressed disk image, and you will only make rational people foam at the mouth.
Die. Die. DIE.
I’m going to step away from my normal focus on Social Media because the inner-geek in me just couldn’t resist. Recently Chris Pirillo posted a challenge that I just couldn’t help taking on. In it, he criticizes a post by Preston Galla of ComputerWorld stating “5 Reasons Vista Beats OS X”, and he makes some very good points. I admire Chris a lot because he’s one of the most unbiased Geeks I know, except when it comes to the Mac. Chris and I would get along well.
I too am a Mac user, in fact, the post I am typing at the moment is on MarsEdit on a Macbook. I absolutely love my Mac, and thus far have not found a preferred Operating System for development and desktop environment to work on, at least as a software developer (I should note that actually, most of my software development is over Terminal on the Mac, over to a Linux Server, my preferred server OS).
I will be the first to admit however that the Mac does have its flaws, in particular Leopard. I do run a Vista Ultimate machine, and I love it too, but for different reasons. Let me give 5 real reasons, and Chris, if you’re reading I would love to hear your response to this, why Vista, at times can be better than a Mac, in particular Leopard. Here are 5 reasons in response to Chris’s challenge that I think really make sense:
So, those may or may not be big things to some, but that is my list, and you asked Chris. Of course I could always come up with 10 more things that Mac beats Vista in, but my point is, as they told us when I was a Sales person at Computer City as a teenager, there are strengths to each OS - it’s important to evaluate what works best for you and your situation, and choose accordingly. Now, I ask my readers, are there any reasons (supported by true, concrete facts) that you feel Vista beats Leopard or the Mac in general?
Share This
I finally got around to building QCad on OS X Leopard. There are two main hurdles: getting Qt3 to build and getting QCad to build.
At first I tried building Qt3 with macports, but building QCad was a royal pain with the X11 version of Qt3 on OS X, for whatever reason. So I tried to install the qt3-mac MacPorts package, but that failed. So I was on my own building Qt3.
This patch will allow Qt3 to build on Leopard, by following the instructions in the INSTALL file. Here's the diffstat:
config.tests/mac/mac_version.test | 2 +-
src/kernel/qcursor_mac.cpp | 4 ++++
src/kernel/qt_mac.h | 2 +-
src/tools/qglobal.h | 5 ++++-
4 files changed, 10 insertions(+), 3 deletions(-)
I put it in /Developer/qt3, and I wrote a script to source on demand rather
than setting QTDIR and friends in my .profile or .bashrc, since I more
often want Qt4 than Qt3. I configure with -static, so applications like QCad
are built with Qt3 statically, which just makes things work better.
QCad needs a patch as well:
Index: qcad-2.0.5.0-1-community.src/mkspecs/defs.pro
===================================================================
--- qcad-2.0.5.0-1-community.src.orig/mkspecs/defs.pro 2008-03-26 08:46:25.000000000 -0600
+++ qcad-2.0.5.0-1-community.src/mkspecs/defs.pro 2008-03-26 08:46:48.000000000 -0600
@@ -1,6 +1,6 @@
# $Id: defs.pro 606 2004-12-25 03:08:40Z andrew $
-QMAKE_CXXFLAGS_DEBUG += -pedantic
-QMAKE_CXXFLAGS += -pedantic
+#QMAKE_CXXFLAGS_DEBUG += -pedantic
+#QMAKE_CXXFLAGS += -pedantic
win32 {
QMAKE_CFLAGS_THREAD -= -mthreads
Index: qcad-2.0.5.0-1-community.src/scripts/build_qcad.sh
===================================================================
--- qcad-2.0.5.0-1-community.src.orig/scripts/build_qcad.sh 2008-03-26 08:46:06.000000000 -0600
+++ qcad-2.0.5.0-1-community.src/scripts/build_qcad.sh 2008-03-26 08:46:49.000000000 -0600
@@ -30,7 +30,7 @@ then
export MAKE=gmake
echo "Platform is Solaris"
platform=solaris
-elif [ "x$OSTYPE" == "xdarwin8.0" ]
+elif [ "x$OSTYPE" == "xdarwin8.0" -o "x$OSTYPE" == "xdarwin9.0" ]
then
export MAKE=make
echo "Platform is Mac OS X"
Then do
cd scripts
./build_qcad.sh notrans
It will complain about not finding qm/*.qm, but that's a nonfatal error.
QCad.app will be in the qcad directory, ready for your use.
I built this on an Intel MacBook running Leopard. If you think that matches your setup, you're free to download my QCad.app and avoid building both Qt3 and QCad.
If I had a nickel for every time I had to scour the web to figure out the right setting for QTDIR on {Debian,Ubuntu,OS X}…
On OS X, if you installed the qt3 package, then the proper setting is
QTDIR=/opt/local/lib/qt3. I wrote this little script to source before
commencing building a Qt3 project:
#QTDIR=/usr/local/Trolltech/qt-mac-free-3.3.7
#QTDIR=/Developer/qt
QTDIR=/opt/local/lib/qt3
PATH=$QTDIR/bin:$PATH
DYLD_LIBRARY_PATH=$QTDIR/lib:$DYLD_LIBRARY_PATH
export QTDIR PATH DYLD_LIBRARY_PATH
I'm porting Aeolus to OS X. In the process I'm learning how CoreMIDI works. Naturally you get to hear my opinion on the matter.
CoreMIDI seems like a decent framework, actually. It is callback-based, which is good. It has a pretty reasonable design; physical devices and virtual devices alike communicate with eachother in the same way. They each have endpoints—source endpoints and destination endpoints.
It all looks well and good on the surface, but there's some problems. The first problem is arguably a feature. You can create input/output ports and connect sources/destinations to those ports from within your application. This allows you to make a cute or complicated dialog box where the user can select the MIDI (virtual) device(s) she wants to use. Sounds reasonable right? And so it is, and I wouldn't argue against this ability.
The badness comes in when you consider that every application has to duplicate this functionality. It would be much better to have an external patchbay for connecting applications together. This would be more powerful and flexible and free up application developers to not worry about it. They just have to create the endpoints and then they're done.
Alas, OS X proper has no such patchbay. "Yes it does, silly. It's called Audio MIDI Setup" you say. That's the most infuriating thing—Audio MIDI Setup lets you route between devices in just the sort of way I'm talking about, but it only works for physical devices. Someone needs to be shot.
Luckily, some guy named Pete wrote a MIDI Patchbay. It's serviceable, if quirky and ugly. He also wrote a simple software synthesizer called SimpleSynth (also quirky and ugly) that does what something in OS X (e.g. QuickTime Player) should already be doing: accept MIDI input and use the QuickTime music synthesizer to render it. Kudos to Pete for filling in the gaps, and I'm sorry for calling your children ugly.
While I'm complaining about patchbays, I'm still dumbfounded that JACK doesn't seem to have a command-line application for patching things together. I'm thinking something akin to aconnect for ALSA MIDI, though of course for JACK it would be for audio and MIDI both. qjackctl is absolutely marvelous, and I wouldn't use anything else given the choice, but sometimes you don't have qjackctl handy and it might be quite difficult indeed to get it. This was the case for me the other day. I had the latest greatest JACK installed from source, but qjackctl (which I finally managed to figure out how to build using the QtMac binary, whose qmake refuses to output a real Makefile but instead an XCode project) was choking on it. So I had to downgrade to Jack OS X and rebuild qjackctl (it's still an immense improvement over JackPilot). This is depressing because the newer version of JACK is much more friendly to the CLI user on OS X. The version in Jack OS X 0.76 still requires some ugly workarounds (which JackPilot helps you to do). The latest version of JACK (0.109.2) Just Works™ when you type jackd -R -d coreaudio. So I'm still starting JACK with JackPilot, which I then summarily quit in favor of qjackctl.
For my musical notation needs, I use LilyPond.
LilyPond is to music as LaTeX is to writing. I prefer to edit LilyPond files in Vim and compile them with lilypond at the command line. However, on OS X LilyPond.app is a front end to the compiler. An IDE of sorts. Not a spectacular one, in my opinion, but it does have one thing going for it: when you click on a note in the PDF preview, it takes you that note in your LilyPond source file in the IDE.
On Leopard, LilyPond is severely broken. The IDE will "start", but there is no menu. Further, if you are on Intel, when you try to run it at the command line, it just keels over and does nothing. It so happens that the workaround to this problem and using LilyPond without the IDE are almost identical solutions, so I'll describe them as one and the same.
First, and this is the only difference between Leopard brokenness and just wanting to run on the command-line, you want the powerpc version of LilyPond.app, not the Intel version. So go over to the download page and get the ppc version (the one that says it's for G3, G4, G5 Macs).
lilypond and its friends are in Lilypond.app/Contents/Resources/bin. You could add this to your PATH, but some of the binaries in there are things that I have installed elsewhere (e.g. with MacPorts), and I don't want them overriding my PATH. Likewise, I want lilypond to be able to find the binaries it expects, and since they're taking up disk space anyway let's help it along. So I wrote a script. A LilyPond launcher if you will. I call it ly and put it in my path, and then I call e.g. ly lilypond foo.ly. Here's the code:
#! /bin/sh
APP=/Applications/LilyPond.app
PATH=$APP/Contents/Resources/bin:$PATH
exec "$@"
Customize APP to point wherever you want to keep LilyPond.app. This will load up the environment that will give lilypond the best chance of success. You can run any of the binaries in that directory with ly, but the most common case is to run lilypond. So I recommend putting this in your .bashrc:
alias lilypond='ly lilypond'
The first time you run the ppc version of LilyPond, or anything else, on an Intel machine, it will seem to take forever while Rosetta fires up. Be patient. Subsequent invocations are quick enough.
In the spirit of release early, rewrite often, I have released Crème Rappel version 2. Version 1 was a shell script that combined Growl and at. Then Apple released 10.5.2 not half a week later and broke at altogether. Sick of fighting with launchd and other Apple superiority complexes, I set about to nurture my own superiority complex and rewrite Crème Rappel to be completely independent of at.
Of course, that's getting too heavy for a shell script, so I moved to Ruby. One thing I didn't want was to require a daemon to be running. Daemons can fail or
forget to start up, and that means I couldn't really truly trust the tool. The recent at debacle is just another case in point. So, instead I wrote Crème to fork a process that sleeps until the moment of truth, then fires off the reminder. It turns out the obvious function for the job, sleep(), is a poor choice here. In fact, every timer I tried had the same problem, including one I thought would not: setitimer(). When you suspend the laptop, it appears you also suspend time. If you don't believe me, try this simple experiment:
date; sleep 30; date
Put the laptop to sleep during the sleep for a substantial time, then notice that when you resume you still have to wait for the full 30 seconds to tick by even though it has actually been a minute plus since you issued the command. So I sleep for one second intervals instead, checking the time every time.
This is not just a backpedaling rewrite, though. It also adds more flexible and easy-to-type timespecs, and a spiffy website. If you give it a try and it doesn't work, or you struggle with the documentation, please do drop me a line so I can fix it. I want it to be worth every bit of bandwidth that you paid for it.
Once upon a time I was on a quest to get Ogg Vorbis working on a Mac. I tried the QuickTime Components project and it worked for awhile. Then it broke with QuickTime 7. Truth be known, it never worked all that great before, though it did decode the music. Then I found VLC and never looked back.
Today I learned that somewhere in the interim Xiph.org filled the gap. Now you can download XiphQT, stick XiphQT.component in /Library/Components, and you're off and running. This is precisely how the issue should have been addressed in the first place, and I'm glad it finally was, whenever it was. I'm also happy to have been ignorant of the fact for so long, since I despise iTunes for other reasons, and this tells me I've lived without regular iTunes abuse for a long hapy time.
For my musical notation needs, I use LilyPond.
LilyPond is to music as LaTeX is to writing. I prefer to edit LilyPond files in Vim and compile them with lilypond at the command line. However, on OS X LilyPond.app is a front end to the compiler. An IDE of sorts. Not a spectacular one, in my opinion, but it does have one thing going for it: when you click on a note in the PDF preview, it takes you that note in your LilyPond source file in the IDE.
On Leopard, LilyPond is severely broken. The IDE will "start", but there is no menu. Further, if you are on Intel, when you try to run it at the command line, it just keels over and does nothing. It so happens that the workaround to this problem and using LilyPond without the IDE are almost identical solutions, so I'll describe them as one and the same.
First, and this is the only difference between Leopard brokenness and just wanting to run on the command-line, you want the powerpc version of LilyPond.app, not the Intel version. So go over to the download page and get the ppc version (the one that says it's for G3, G4, G5 Macs).
lilypond and its friends are in Lilypond.app/Contents/Resources/bin. You could add this to your PATH, but some of the binaries in there are things that I have installed elsewhere (e.g. with MacPorts), and I don't want them overriding my PATH. Likewise, I want lilypond to be able to find the binaries it expects, and since they're taking up disk space anyway let's help it along. So I wrote a script. A LilyPond launcher if you will. I call it ly and put it in my path, and then I call e.g. ly lilypond foo.ly. Here's the code:
#! /bin/sh
APP=/Applications/LilyPond.app
PATH=$APP/Contents/Resources/bin:$PATH
exec "$@"
Customize APP to point wherever you want to keep LilyPond.app. This will load up the environment that will give lilypond the best chance of success. You can run any of the binaries in that directory with ly, but the most common case is to run lilypond. So I recommend putting this in your .bashrc:
alias lilypond='ly lilypond'
The first time you run the ppc version of LilyPond, or anything else, on an Intel machine, it will seem to take forever while Rosetta fires up. Be patient. Subsequent invocations are quick enough.
Once upon a time I was on a quest to get Ogg Vorbis working on a Mac. I tried the QuickTime Components project and it worked for awhile. Then it broke with QuickTime 7. Truth be known, it never worked all that great before, though it did decode the music. Then I found VLC and never looked back.
Today I learned that somewhere in the interim Xiph.org filled the gap. Now you can download XiphQT, stick XiphQT.component in /Library/Components, and you're off and running. This is precisely how the issue should have been addressed in the first place, and I'm glad it finally was, whenever it was. I'm also happy to have been ignorant of the fact for so long, since I despise iTunes for other reasons, and this tells me I've lived without regular iTunes abuse for a long hapy time.
In the spirit of release early, rewrite often, I have released Crème Rappel version 2. Version 1 was a shell script that combined Growl and at. Then Apple released 10.5.2 not half a week later and broke at altogether. Sick of fighting with launchd and other Apple superiority complexes, I set about to nurture my own superiority complex and rewrite Crème Rappel to be completely independent of at.
Of course, that's getting too heavy for a shell script, so I moved to Ruby. One thing I didn't want was to require a daemon to be running. Daemons can fail or
forget to start up, and that means I couldn't really truly trust the tool. The recent at debacle is just another case in point. So, instead I wrote Crème to fork a process that sleeps until the moment of truth, then fires off the reminder. It turns out the obvious function for the job, sleep(), is a poor choice here. In fact, every timer I tried had the same problem, including one I thought would not: setitimer(). When you suspend the laptop, it appears you also suspend time. If you don't believe me, try this simple experiment:
date; sleep 30; date
Put the laptop to sleep during the sleep for a substantial time, then notice that when you resume you still have to wait for the full 30 seconds to tick by even though it has actually been a minute plus since you issued the command. So I sleep for one second intervals instead, checking the time every time.
This is not just a backpedaling rewrite, though. It also adds more flexible and easy-to-type timespecs, and a spiffy website. If you give it a try and it doesn't work, or you struggle with the documentation, please do drop me a line so I can fix it. I want it to be worth every bit of bandwidth that you paid for it.
OS X's Termina.app is the terminal I've been using since I switched to Leopard, because it has tabs now and it's beautiful. Oh, and iTerm gave me too much grief with odd, illogical and unpredictable bugs.
One of the drawbacks to Terminal.app is that it's broken. This is what Aptitude looks like with TERM=xterm (I think this is the default):
This is what it should look like:
How to get from there to here? The short answer is to choose dtterm as your terminal emulation (in Preferences, on the Advanced tab).
The long answer is that the problem here is that xterm supports this capability called back-color-erase (bce). If you tell programs that you are an xterm (with TERM=xterm), they will assume you support bce. The same goes for rxvt and xterm-color and even vt100 (even though that one doesn't seem to support color). bce isn't the only problem, either. There's also redraw problems that are difficult to show with a screenshot.
Setting TERM=dtterm seems to get rid of at least the major breakage. It would seem that the actual capabilities of Terminal.app are closest to dtterm, or at least closer to dtterm than to xterm or rxvt. It solves all the issues I've been having with aptitude, mutt, and screen locally and on remote linux boxes. But there's a caveat—not all remote systems will have the dtterm entry in their terminfo databases. Ubuntu 7.10 didn't by default, for example. The package you want on Debian-based systems (like Ubuntu) is ncurses-term.
Alternatively, you can install it in your home directory. To do this, on OS X type
infocmp > /tmp/dtterm
scp /tmp/dtterm username@example.com:/tmp
ssh example.com tic /tmp/dtterm
tic (terminfo compiler) will create a terminfo database entry in ~/.terminfo/d/dtterm, and you should be good to go.
For a couple years now, I've been learning and applying various tricks for developing and hosting multiple Python web sites on my development machines. During that time, I made a migration to Mac OS X. Most setup files for python applications and libraries work out of the box on the Linux distributions I've [...]
I discovered a very strange bug today with OS X's Bourne shell. If you have OS X, give this a try:
/bin/sh -c 'echo -n bug'
This is what you should see:
$ /bin/sh -c 'echo -n bug'
bug$
This is what I see:
$ /bin/sh -c 'echo -n bug'
-n bug
$
In other words, it's ignoring the -n option. It works fine in bash, it's only sh that's broken. It gets better though. If you're using iTerm instead of Terminal.app, it works fine. I have combed through the environment, the locale settings, the terminal emulation, and I can't account for it. I've tried ssh from a linux box which behaves the same as Terminal.app (broken). Who knows what black magic iTerm is invoking.
So I replaced my bash and sh with the ones from MacPorts:
sudo port install bash
sudo mv /bin/bash /bin/bash.old
sudo mv /bin/sh /bin/sh.old
sudo ln /opt/local/bin/bash /bin/bash
sudo ln /opt/local/bin/bash /bin/sh
While you're at it, feel free to
sudo port install coreutils +default_names
Problem solved. Very odd, though. abcde uses echo -n heavily, which breaks in all sorts of ugly ways before this fix. This patch causes abcde to use /bin/bash instead of /bin/sh:
Index: abcde-2.3.3/abcde
===================================================================
--- abcde-2.3.3.orig/abcde 2007-12-07 18:46:36.000000000 -0700
+++ abcde-2.3.3/abcde 2007-12-07 20:57:17.000000000 -0700
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# Copyright (c) 1998-2001 Robert Woodcock <rcw@debian.org>
# Copyright (c) 2003-2005 Jesus Climent <jesus.climent@hispalinux.es>
# This code is hereby licensed for public consumption under either the
Index: abcde-2.3.3/cddb-tool
===================================================================
--- abcde-2.3.3.orig/cddb-tool 2007-12-07 20:56:49.000000000 -0700
+++ abcde-2.3.3/cddb-tool 2007-12-07 20:57:19.000000000 -0700
@@ -1,4 +1,4 @@
-#!/bin/sh
+#!/bin/bash
# Copyright (C) 1999 Nathaniel Smith <njs@uclink4.berkeley.edu>
# Copyright (C) 1999, 2000, 2001 Robert Woodcock <rcw@debian.org>
Speaking of abcde, here's a patch to get rid of an unrelated bug in 2.3.3:
Index: abcde-2.3.3/abcde
===================================================================
--- abcde-2.3.3.orig/abcde 2005-08-25 16:43:27.000000000 -0600
+++ abcde-2.3.3/abcde 2007-12-07 18:46:36.000000000 -0700
@@ -1946,7 +1946,7 @@
FILEPATH=$(find "$FILEPATH" | grep "/$REALTRACKNUM ");
# If the file exists, copy it
if [ -e "$FILEPATH" ] ; then
- nice $READNICE $CDROMREADER "$FILEPATH" "$FILEARG" $REDIR
+ nice $READNICE $CDROMREADER "$FILEPATH" "$FILEARG"
else
false
fi ;;
Finally I have abcde at my fingertips again. There's no replacement for abcde when it comes to ripping CDs.
In the immortal words of sontek, “Tonight was amazing!”
The Multi-Distro Release Party was a grand success. Around 30+ people, plenty of drinks, food and oh yeah, three Linux distros were discussed along with one proprietary-ish OS. Fun was had by all and even a new Linux user came and got Ubuntu installed, Christer must be proud.
Heartsbane brought his apocalypse box to install Fedora. It was quite the sight!
Shauna Theobald from the OSTC provided the pizza and decided also that it would be fun to surprise yours truly with an early *surprise* birthday party. All I can say is that I was “blown away”, and “thank you”. That was a pretty nice thing to do…
And while we were all having fun, the kids were getting into it too!
As it stands, the Fedora, Ubuntu, OpenSUSE, OpenBSD and Mac OS X Release Party was a grand success. Here’s all of the pics from my camera.
Cheers,
Clint
One of the more drool-inducing features of Leopard (for geeks, anyway) is Spaces, Apple's virtual desktop implementation. I'm a big virtual desktop fan, and I'm glad to see it working its way into the mainstream. And all things considered, Spaces is a decent (and beautiful) implementation.
But there are some bugs. I hope that we will see them worked out. Some of the bugs are in Spaces itself, some are probably with 3rd party applications. The most notable, and annoying, problem is buggy application switching. When you cmd-tab to switch applications, you are taken to the space with that application. This is good, but it must have given the Apple developers heartburn because in some ways it flies in the face of the "Apple Way", which thinks of an application as a whole not as independent windows. That's why the menu bar is at the top, and it's behind the design of the dock. But what happens when there's a Terminal window on this Space, and on that Space? The natural thing should be, switch to the terminal window in this Space. If that's not what the user wanted, well you can't be expected to read minds. But when I cmd-tab to Terminal, I am always taken to what Leopard apparently thinks is the master Terminal Space, regardless of whether I have a Terminal window in this space, which Terminal window I last used, etc. Bad news. As a workaround, I just put Terminal on all spaces and thank my lucky stars it has tabs now. This affects most multi-window applications to some degree, but it's most annoying with Terminal and Adium.
On a related note, I'd expect cmd-` to switch between windows of the same app on different Spaces, but it only switches between windows on the current space.
Some applications, especially Firefox and to a lesser extent Thunderbird, have focus bugs that may be related to spaces. Sometimes when I switch to Firefox (with cmd-tab), the window is not in focus and is not brought to the foreground. The menu bar reflects that I'm in Firefox, and I may have moved spaces to get there, but it's in the background. I have to switch to it with cmd-` (or, horror of horrors, with the mouse). I imagine this is the sort of thing that Apple and/or Mozilla will hammer out soon. There are other Firefox irritations but they're for another post—if they haven't been fixed by then.
So far, nothing too surprising. Virtual desktops is hard to get perfect, and various Linux window managers have been floundering for years or even decades. Overall, I'd say they're off to a smashing start. I have two other more minor irritations. First, I'd like the current application to stay the current application when I switch spaces with the keyboard, instead of switching to the topmost application in the new space. This is because I often want to choose an application (by cmd-tabbing to it), then navigate to another space where I want to open a new window (e.g. Terminal). This is a design decision, of course, and one that people tend to fall on either side with about 50% probability. The second is keybindings. I'd like to switch spaces with cmd-ctrl-hjkl (Vim keybindings). Maybe we'll find a way. I'd also like to have more keyboard operations, especially "move me and this window to the {left,right,up,down} space".
I recently had need to put a .bst file in my LaTeX search path. This turned out to be difficult to search for. I found a lot of pages and style files telling users to put such and such file in their LaTeX search path. I began to wonder if I was the only LaTeX user on earth who had no idea what the LaTeX search path was.
With some effort I found that the global path's root is usually something like /usr/share/texmf. I'm not interested in putting it in the global path though. We have home directories for a reason here.
Finally I found the answer, with some creative googling. The answer depends on your distribution/OS. Apparently on Debian it's ~/.texmf-config (untested). The MacTeX distribution (which I have installed) looks in ~/Library/texmf. The macports build (don't ask) looks in ~/texmf, which I learned only by trial and error. My guess is that latter answer is the answer if you build by yourself, and so might be a good initial guess no matter what the distribution.
So, I did this:
mkdir -p ~/Library/texmf/bibtex/bst
ln -s ~/Library/texmf ~/texmf
mv acm-annotated.bst ~/texmf/bibtex/bst
The OS X Leopard Calculator has one very nice change. A picture is worth a thousand words and I'll let this one speak for itself:
Once upon a time, bash (or some other shell) introduced color in the shell prompt. The syntax was funky and all but illegible, so manpages and HOWTOs were written. The technical elite (i.e. high school kids and sysadmins with nothing better to do than configure their bash prompts) rejoiced.
Once upon a more recent time, I crafted this bash prompt:
PS1='$(r=$?; [ 0 == $r ] || echo "\[\e[33m\]$r\[\e[0m\] ")\u@\h:\w\n\[\e[32m\]\$\[\e[0m\] '
Actually, its history is more of an evolution than a crafting, but nonetheless I like it.
Then, out of the blue, someone broke bash. The \[ and \] non-printing character delimiters stopped working (or stopped working properly). Their purpose is to tell bash that the stuff inside is non-printing so don't count it when you're counting the number of characters in the prompt. This is vital for proper wrapping and tab completion in the presence of color escape sequences. I don't know who broke it or why, but removing \[ and \] seemed to fix the symptom.
Fast forward far too long, and someone fixed the problem. Once again you needed \[ and \].
Fast forward again, and it's broken. Or maybe we're just going around in circles on which version of bash is being used in various distributions and OS's. In this case, Ubuntu is still (or again) broken and OS X is broken in a different way. They're both running 3.2.x. The bug is probably the same and the manifestation is simply different.
The current manifestation of this bug is that neither with nor without the delimiters works. I'm forced to go back to a noncolored prompt, and I'm not happy about it. This bug has been around for at least a year. I've reported it several times to various distros. Why is it not yet fixed? If they fixed it today, we'd still be battling the bug for years to come because of the many distros and OS's that have assumed buggy versions of bash.
I now have Leopard, so expect a flurry of posts as I discover neat things and annoyances.
The biggest reason why I got Leopard, apart from that my fellowship paid for it and you never turn down free gadgets or software, is for Terminal.app redux, aka Terminal 2 (think Schwarzenegger). When working on a laptop, I must have a tabbed terminal. This forced me to use iTerm, which worked well most of the time. However, iTerm hates me. It has an impossible-to-track-down bug that will occasionally render every curses program (including vim) useless for an indeterminate amount of time, and not even restarting iTerm will fix it. In general I've found iTerm to be somewhat shoddy, and Terminal is beautiful and, well, Mac-ish. So I'm excited for the switch to Terminal 2.
I had a right to be, too. It is a beautiful piece of software. I have a few qualms, though. First, and most annoyingly, the keybindings for next/previous tab aren't configurable, and they're set to the ridiculous default of ⌘-{ and ⌘-}. Yes, that means you have to press shift too. However, there is hope! Go to the Keyboard & Mouse preference pane, in the Keyboard Shortcuts tab. Scroll down to Application Keyboard Shortcuts, and add shortcuts for Terminal.app. Now I can switch tabs with ⌘-→ and ⌘-←, as it should be. Naturally, you can use this trick to change any unfavorable keyboard shortcut in any native OS X application.
I'm having some emulation issues, but this is not new to Terminal 2. When I ssh to my linux box and run irssi the screen doesn't update properly. It works ok if I run irssi in screen though.
I like the unlimited scrollback, though I hope it's not all going into RAM. Sometimes I'll do the odd copious command that spews on forever. I don't mind if it's going to a temporary disk buffer, but I don't want it all in RAM. I'm sure they figured that out though.
The built-in themes are nice. The configuration is well layed out, with one exception. I wish there was a place to set default preferences, common to all of the themes that don't override them. But since I and most other people who would care will stick to one theme, I guess it's not a big deal.
I haven't noticed any of the rumored problems of Terminal resizing without permission. I think Gary must have been expecting terminal to read his mind about where and how big new terminal windows would be. I'm glad it doesn't, because if I closed a terminal that I had resized temporarily, and then all my terminals started opening at that odd size, I'd be quite grumpy indeed. Size is one of the preferences you can set, and it works almost perfectly. I like mine as tall as I can get them, and I set it to 53 lines (with Anonymous 10pt). For some reason terminal would end up not quite at the top of the screen and sized only at 50. I opened a few tabs, sized it the way I wanted it (oops, with tabs I only get 51), and then went to the menu and chose Shell, Use Settings as Default. Now it behaves itself. My only unresolved annoyance is that I can't tell it to always have tabs, even when there's only one tab open. I don't like the shifting and resizing during the transition from 1 to 2 tabs (or vice versa). Oh well.
I had a chance to try out Leopard over the weekend, and there's quite a bit to like. In the end, though, I restored my backup (which was a lot more difficult than it usually is, but that's another story), and I'll be sticking with Tiger for at least the next few weeks.
I should probably start off by mentioning the good parts. I didn't get to use the system for long, but already I like the ability to use tabs in Terminal, and I can see that Spaces and Time Machine are going to be great. The new dock looks nice, and I'm sure I'm going to like stacks.
I had a few annoyances, too, though, and one complete show-stopper (which I'll save for last).
I'm not sure exactly why, but I had to recompile the MySQL server. Not a problem, I do that often enough with new upgrades that I've got my configure arguments saved in a script so it's fairly automatic, but unexpected. The real annoyance here was that MySQL Pref Pane stopped working, and claimed that it wasn't compatible with a PowerPC-based Mac. Odd, I had just been running it on a PPC Mac in Tiger and it worked fine.
That's not a show stopper, since I can still run MySQL from StartupItems and it works fine, but it's a bother not to have it work in System Preferences.
A long time ago, I switched from the built-in Apache 1.3 in Tiger to my own build of Apache 2.0, and more recently from Apache 2 to lighttpd. I never have had any success with the lighttpd launchd script that shows up all over, but that doesn't matter: anyone who's switched out Apache will have learned that you can replace Apple's default /usr/sbin/apachectl with a symbolic link to your own apachectl script, and your new Apache will magically Just Work with the Personal Web Sharing control in System Preferences. Turns out, that works just fine if your "apachectl" script happens to run lighttpd instead of Apache, too.
Not so in Leopard, unfortunately. I was able to get lighttpd to run from StartupItems, and with a few more days to play with it, I'd probably have had it working in System Preferences too, but not yet. (On the good side, though, Apple has finally switched to Apache 2, so if I were to give up on playing with lighttpd, it would be fairly simple to drop in my Apache 2 httpd.conf and run with the software that comes built in in Leopard.)
I had to recompile my FastCGI build of PHP. Again, I'm not sure why it stopped working, since it wasn't installed in the same place as Apple's default PHP. Not a serious problem, but a bother.
I mentioned before that I really like tabs in Terminal. They don't even begin to make up for Terminal's new window sizing behavior, though.
In Tiger, I can set the size and position of my Terminal window, and once I do, it stays how I set it. That seems fairly obvious. Leopard, unfortunately, missed that obvious behavior. Every time I open a new terminal window or switch between two terminal windows, Leopard's Terminal decides that It Knows Better and moves and resizes my window. That's completely unacceptable, and I was almost ready to go back to Tiger just for that.
Apple has generally done a good job of picking sane defaults for window sizes and locations, but when I put a window somewhere and size it how I want it, I had a reason for doing it, and the system had better respect that. If I weren't already bald, this one would have had me pulling all my hair out within the first five minutes. When (if?) I do switch to Leopard again, I'll be looking for a different Terminal program. Suggestions, anyone?
And finally,
I really should have checked before trying Leopard, but it never occurred to me. Verizon won't be releasing updated software for my EVDO card until sometime in November, and the old software doesn't work in Leopard. That means, of course, that Leopard is dead in the water until November as far as I'm concerned. Game over.
I'll probably upgrade after the new EVDO software comes out. I'll probably decide I really like Leopard (I already do, in fact, despite the foregoing). I'm thinking I'll do a clean system build rather than try to upgrade, because I've been wanting to re-do the way I've got PHP and a few other utilities installed anyway, and this will be a good chance to start from scratch. But I'm not touching this again without two full backups, and probably not without already finding a good replacement for Terminal.
annoyances, apple, Leopard, macIn two days Apple will release a new version of its Mac operating system, so last Saturday I watched the guided tour and read about all of the 300 new features of “Leopard.”
I thought my strong interest in the new operating system was justified since I’m going to take the opportunity to replace my 4½ year old Titanium Powerbook with a new Leopard-powered notebook. But then I got thinking, it’s just a tool. Using a Mac isn’t my goal per se. I might as well get exciting about all the tools at Home Depot — and I do — but if I don’t build anything with them, they’re useless.
Jon Udell refers to himself as a “toolsmith” — someone who loves the tools of his trade — and I think I have a bit of that in me. Being a toolsmith means knowing the ins and outs of one’s tools, with the potential to be very productive with them. But Merlin Mann warns against continual “fiddling” with tools and systems and methods at the expense of just Getting Things Done.
Use whatever tools work best for you, but use tools to build something.
At work I’m the “producer” of a podcast, and here are the tools we use:
1. Apple Garageband — Found on every Mac, this free app makes it easy to record and combine tracks, add effects and art, and create podcasts.
2. Logitech USB Headset — This isn’t a professional mike, but it works fine for us and it’s comfortable to wear and use.
3. WordPress — The best open source blogging platform. You’ll need web hosting and your own domain to install this.
4. PodPress — A powerful WordPress plugin that turns your blog into a podcasting platform. This plugin takes care of all the nitty gritty (podcast enclosures), offers an embedded Flash player for easy listening, and provides stats.
5. Mime Config — If you plan to publish “enhanced” podcasts for iTunes, chances are your server isn’t configured to recognize the “m4a” format. Install this WordPress plugin and add the mime type “m4a = audio/mpeg”.
What other tools are you using for creating podcasts?