Funny Looking Chocolate Not Actually Amusing

Look!  Exciting!

As a rule of thumb, chocolate that looks all fancified often isn’t very good.  (There are a number of exceptions to this rule.)

But this one looked too intriguing for me to pass up.  As you can see, it’s blueberries and lingonberries suspended in white chocolate.  I was wondering how they did that.

And the second picture shows how: They’ve freeze-dried the berries, giving them the approximate texture of crumbly styrofoam.  And the approximate taste of styrofoam, too.  All that remains is a hint of bitterness.

The white chocolate itself isn’t particularly good, either.

Coloured Styrofoam or Freeze-Dried Berries?

I’m now slightly nauseous, and am throwing away the rest of this awful product from Emil Gustavs Chocolates.

More Input Devices

Targus Wireless Presenter and Emacs Volume Control

Finding wireless input devices (for controlling the stereo) that are

1) not too ugly and
2) works reliably and
3) has a range over a few meters

isn’t trivial.  I’ve experimented with a few thingamabobs, and one device I’m pretty satisfied with is the Targus …  er…  I can’t find any model name here.  AMP02EU?  Anyway, it’s a “wireless presenter” (with a laser pointer, so I could entertain a cat if I had a cat, but I don’t *sob*), so, of course, it isn’t really geared towards music playing.  But since, these days, all input devices show up as input devices in Linux, you can use it for whatever you want, with a bit of configuration.

The first thing to do is to put the following in /etc/udev/rules.d/90-itron.rules. It has to be “late” in the udev chain so that other rules don’t overwrite the name we want.

KERNEL==”event*”, BUS==”usb”, SYSFS{idVendor}==”195d”, SYSFS{idProduct}==”7777″, MODE=”0666″, NAME=”input/itron%n”

I chose the name “itron” since that’s what lsusb claims that this device is:

rocket-sam:/etc# lsusb
Bus 002 Device 018: ID 195d:7777 Itron Technology iONE Scorpius wireless keyboard

Now that we know where the device will show up (i.e., /dev/input/itron*), we can route events to the commands we want to execute.  I googled around for a while before deciding to use evrouter, which gives us pretty simple access to all events.

“Itron Powerful Receiver” “” any rel/1/1  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-decrease-volume)'”
“Itron Powerful Receiver” “” any rel/1/-1  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-increase-volume)'”
“Itron Powerful Receiver” “” any key/272  “Shell/emacsclient –server-file=rocket-sam –eval ‘(jukebox-pause)'”
“Itron Powerful Receiver” “” any key/104  “Shell/lights 0”
“Itron Powerful Receiver” “” any key/109  “Shell/lights 1”

The first string is the name of the device (yes, that’s what it calls itself.  How masterful).  “rel” is the mouse.  “key” is, er, a key.

So this decreases volume when the mouse goes down, increases when the mouse goes up, pauses the music when I press the big button down, and switches the lights in the room off/on on two of the other buttons.

Which still leaves me with more unused buttons, but I haven’t found a use for them yet.

Then start the event routing in a startup script like so:

$ rm -f /tmp/.evrouter\:0.0
$ /usr/local/src/evrouter-0.4/src/evrouter -f /dev/input/itron*

(The first “rm” is needed because evrouter doesn’t seem to clean up after itself always…)

The only minor problem I now have is that although evrouter picks up the events, they still get passed on to X.  So when I increase the volume, the mouse cursor goes upwards.  I haven’t bothered trying to investigate how to make X ignore certain input units, but if anyone has a pointer to a conf example, please leave a note in the comments.

Live TV!

Still can’t get my camera to focus on the TV

I haven’t really missed having live TV for a decade, but it would be practical if guests wanted to watch the news or something.  So it just occurred to me that doing live TV would be trivial with the current infrastructure.

I have an Emacs (on a machine in the closet) doing the PVR thing, so I just had that one listen to an emacs-server socket, and then just say emacsclient –eval ‘(pvr-choose-channel “CNN”)’ to change the channel.  In addition,  I have an inetd entry to spew out the programme itself:

8040 stream tcp nowait larsi /bin/cat cat /dev/video0

Close-ups work fine, though.

And then some new commands in the Emacs-based movie browser running on my movie browsing machine, and Bob is a close relative.

Everything is on github, as usual.

Digital Audio Extraction from Emacs

Triple Threat
SATA Multilane Connector

So my CD ripping situation is that I put a CD into the CD reading thing there (more about that in a thrilling later blog article), hit a key in Emacs, slap a CD cover onto the scanner, hit another key in Emacs to say that the format is (usually RET), and then inspect the CDDB data that Emacs presents me with, and then I `C-c C-c’, and then I repeat. Since I have three CD players, I can do three CDs in parallel.  The time to process one CD is about two minutes, but with the parallelism going on, I can usually process about twenty CDs in ten minutes.  (Unless the CDDB info is missing and I have to type stuff in.)

I started on this journey in 1997, when mp3s first became viable.  So over the years, I’ve ripped CDs as I bought them.  The earliest mp3-encoded albums started sounding pretty crappy to me, since the early mp3 encoders were pretty crappy.  By 2007, disks had gotten so cheap that it was viable to store the music in a lossless format, so I decided to re-rip them all and store the music in flac.

Now, I have around 4K CDs.  Ripping them all in the traditional, sequential way would just take too long.  I don’t really deal well with repetetive, boring, manual tasks.  And since I had ripped all these CDs before, all the data was already in freedb, so it would be a totally mindless manual job.

So I bought the Addonics cabinet seen above, which has a SATA multilane connector, and put three DVD readers into it.  The only problem in getting it to work reliably was that since all the readers were identical (I mean totally), and the SATA cabinet would bring them up in random order, the poor Linux udev system would name them /dev/scdX at random.  So I would never know how to address the top one until after trying 0, 1, 2.

Until I came up with the brilliant idea of uploading different versions of the available Optiarc firmware on each DVD reader.  They worked just as well with any firmware, but the firmware versions allowed me to create udev rules to differentiate.

scsi 7:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.02 PQ: 0 ANSI: 5
scsi 5:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.00 PQ: 0 ANSI: 5
scsi 6:0:0:0: CD-ROM            Optiarc  DVD RW AD-7170S  1.03 PQ: 0 ANSI: 5

With the 3-way parallel ripping setup I think I did all 4K over four nights, if I remember correctly.  While listening to music very loudly, and watching some tv series on DVD (Smallville?), and being totally shit-faced drunk.

Ah, fun times.  At least I think it was fun.  I can’t really remember, for some reason or other.

Anyway, here’s the source code for the Emacs parallel DAE interface.

Useful Consumer Review

I got a new phone today.  The Nokia E7.  And look!  It’s perfect!  It runs Gnus under ssh! Look how pretty Gnus is on the phone!

(The only thing that would have been perfecter would be if it actually ran Emacs on the phone itself, but I guess that’ll have to wait until somebody produces a useful Meego phone.)

I think I’ve got the appliance review thing down now.  This blog will be the next Engadget.