[lang]

Present Perfect

Personal
Projects
Packages
Patches
Presents
Linux

Picture Gallery
Present Perfect

Filed under: couchdb,Python,Releases,Twisted — Thomas @ 23:27

2010-11-24
23:27

I've been working on Paisley some more recently, finishing a first stab
at a document mapping API.

As discussed with Christopher Lenz a long time, I basically took his
mapping code and applied it to Paisley.

In my personal project I also added a caching version of the CouchDB
object, but I'm not yet convinced it is the right approach, so it's not
in Paisley yet. One of the things I think I will need to do to make
that useful is to have it listen to change notifications, so it can
change cached objects when they change in couchdb, and implement
notifications for these changes so that a program can be informed of
them too and react accordingly.

In any case, I'd like to work towards a release, so feel free to take a
look at
the branch I've made
to implement this on, give any feedback or
do any code review, and let me know.

Overy 0.1

Filed under: Hacking,morituri,Music — Thomas @ 23:41

2010-11-19
23:41

I' m finally making some progress on one of my 2010 goals - making a Lego robot that can take CD's and feed them to my computer to rip.

What am I trying to do ?

I'm making a computer-controlled robot out of LEGO that will allow me to rip multiple cd's onto my computer, using morituri.

The goal is:

  • to use Lego Mindstorms for the robot
  • only use regular lego pieces, like Technics, for everything else
  • work with my computer, but preferably with any
  • rip 50 cd's or more in batch

I've been asked a few times why I'm doing this. The main reason is because by now I own over a thousand CD's. I have most of them ripped by hand to Ogg Vorbis, but disks are big enough these days that I really want to rerip all of them just once to FLAC. I've spent quite some time writing an accurate CD ripper for Linux, and I want to have all my audio CD's in correct digital bytes on a computer, so I can use the files to transcode to whatever format is useful for whatever player I'll have.

This probably sounds strange, but a while ago I got to wondering what I would not like getting stolen from my apartment, and my CD's are pretty high on that list, if not number 1.

Some people ask 'why not just do it by hand? You'll probably get it done just as fast as it would take you to make the robot.' I guess people who ask that question don't understand the joy of making something. But there's another reason to do a robot - I'm planning to offer my friends a remote digital backup of their music. Ideally, I could drop this robot off at a friend's house with a Live CD and some instructions, and I would then transcode their music for their iPod or whatever they have. And keep an offline copy at my place purely for archival reasons, of course.

In any case, I am working on my first attempt at robot after building two of the sample ones from mindstorms.

The base mindstorms set is a bit limited piecewise, so I started by getting a really big Technics set that has sawtooth pieces (because that's the mechanism I wanted to try to use for the CD loader)
71173

After looking at a few other approaches out there, I decided I wanted to try one of my own before trying to reproduce someone else's.

After lots of thinking and discussing with some friends, the following ideas fell into place:

  • If I want 50 cd's at once, grabbing one is going to be a problem. After considering pneumatic pumps, arms, some fingers going through the middle and opening, or a wheel at the top of a stack, I went for a simple approach using the sawtooth pieces to space the cd's, and a little axle going through the middle
  • Peter had a great idea to use a USB drive - this way the robot is self-contained and should work anywhere with any computer
  • I wanted to use the CD drive itself as much as possible, so I came up with the idea of rotating the CD drive, so that I can drop ripped CD's by ejecting the CD when it's 180 degrees rotated. I also want to insert the CD when the drive is either at 90 degrees (facing down) or some other angle, before loading it.
  • Mindstorms has 3 motors, so you can roughly (without weird tricks) create three kinds of movements. So I'm using one to pull in the CD rack, one to rotate the first CD 180 degrees into the drive, and one to rotate the drive after ripping.

Here's the CD loader I made; it doesn' t fit 100% but rubber bands finish the job for now. I'll need more sawtooth pieces if I want to load 50 cd's - anyone know where to get some ? The LEGO site doesn't sell those pieces individually.
71177
This was with 2 motors but without CD drive; it already has the mechanism to pull in the CD rack, and the axle (with wheel rim) to pick up the first CD in the rack. It's mounted on a touch sensor so I can stop pulling in the rack when the rim hits a CD. The motor will then rotate the disc 180 degrees around the axle of the sensor, and drop it into the CD drive.
71180
This is the first complete build that I finished tonight. The CD tray is mounted and opened so you can see where the CD is supposed to go. After loading, the CD drive would rotate back to horizontal, then eject the CD the other way around to get rid of it.

I thought I was ready to start trying it for real, but when I went through the process by hand, I noticed two pretty fundamental problems...
71183

First of all, the external drive I used is one of those where you have to firmly press down on the CD so that it fits tight around the round bit in the center. My robot cannot press down. It would be very wobbly anyway because at the point where it hits the tray the CD reader is floating at an angle.

Second, it seems this external USB CD reader has no way of triggering a load electronically, something I had not thought of. It turns out most external drives don't, and again, my robot cannot press on the tray to close it.

So, I guess tomorrow I'll try to shop around for external USB CD readers that can eject and load electronically, and that have a normal tray in which I can drop the discs, like my desktop PC's have.

Backup plans are:

  • Getting one of those hoover CD readers, that suck in and spit out CD's. There again I don't know if you can spit out electronically.
  • Getting one of those 3.5 inch carcasses and put in an internal CD drive. That will probably make it really heavy though, so that might give stability problems with the robot.

If any of you out there know about an external USB CD reader that has computer-driven eject and load, please let me know! For example, this LaCie Lightscribe drive looks like it might be one that would work - if you have it, let me know.

First GStreamer conference

Filed under: Conference,GStreamer — Thomas @ 16:55

2010-10-26
16:55

I'm in Cambridge (the UK one, not the US one) for the first ever GStreamer conference!

Years ago when I was in a cabin in the middle of the woods in Norway at four kilometers away from the closest main road and cut off by waistdeep snow, I never imagined that today I would be attending a conference dedicated to GStreamer with 150 people. 150 !

It seems the conference is a good mix between professionals and hobbyists. I've seen a few interesting applications built on top of GStreamer. Pretty cool stuff.

I took a quick look at the conference schedule and out of 19 talks, seven of them are from people that have been employed by the Fluendo group in the past, and for most of them it was their first full-time GStreamer job. It's great to see these people branched out to other companies and taking GStreamer with them and higher up!

All in all, looks like the GStreamer community is in good shape. Next year, we'll need two days...

While we're at it, we should be handing out '10 years of GStreamer badges' to the people that have stuck by us so long :)

python pystack gdb macro

Filed under: Python — Thomas @ 17:06

2010-10-17
17:06

As mentioned before, I ended up getting a working pystack macro again for use in gdb. Someone commented I should make it public so here it is:


# THOMAS: the test for between Py_Main and Py_GetArgcArgv is because
# code is in that order in the C file; see Modules/main.c and its comment
# print the entire Python call stack
# same for eval in Python/ceval.c

# in 2.6, PyEval_EvalFrame is only bw compatible, and code now calls
# PyEval_EvalFrameEx
define pystack
set $__lastpc = $pc
set $__same = -1

while 1 == 1
# select the highest frame with the same $pc
# this will automatically terminate if we reach the top
while $pc == $__lastpc
up-silently
end
down-silently

if $pc > PyEval_EvalFrameEx && $pc < PyEval_EvalCodeEx pyframe else # frame end up-silently 1 set $__lastpc = $pc end select-frame 0 end

I also posted it in the upstream bug but I doubt that's going to achieve much in this case...

Train shedding

Filed under: Conference,Flumotion,GStreamer,Hacking — Thomas @ 03:57

2010-10-04
03:57

Had a good time at the OpenVideo Conference in New York City, as well as today at (cut short for me) FOMS.

I took the Amtrak train from NYC to Boston and was looking forward to doing four hours of hacking, knocking up a quick prototype of doing chunked streaming of Ogg and WebM.

I didn't actually get to that point however because my test stream triggered the streamer going lost, meaning that its main loop is stuck. So attaching gdb I was reminded how the 'pystack' macro in gdb (which was incredibly useful - it prints a python stack) hasn't worked for me for the last couple of years.

And this time I set out to properly fix it. If only the docs on gdb were easy to understand. My knowledge of gdb doesn't go much beyond the standard 'thread apply all bt' stuff and doing simple inspection. I ended up understanding why the macro hangs (it compares the value of $pc to known function names, and goes up the stack until it finds PyMain. In most of my cases there is no PyMain however, and when you go 'up-silent' in gdb at the top of the stack, it just silently fails leaving you at the same frame forever).

I don't claim to understand exactly how gdb works; for example, there are cases where $pc stays the same going up a frame, seemingly because a function is wrapped into a macro which seems to get its own frame. So I ended up writing a loop that goes up until the $pc changes, and then go back down, leaving me at the frame that calls a python method with a code object.

So, now I have my pystack working again in the cases I tested, so that's good.

Incidentally, if anyone knows gdb well enough, here are some questions:

  • Is there a way I can detect in a script that 'up' didn't actually go up ?
  • Is there a programmatic way to know how many frames there are, and what frame number you're on ?

After fixing that, I was again bitten by a bug where - not always, but often - a flow with Vorbis and Theora has a timestamp/duraiton discontinuity of 1 nanosecond. I can't reproduce it on the command line with -launch, so I think it's related to a set_base_time call on the pipeline.

So I started writing a unit test, but for some reason make check in gst-plugins-base doesn't work for me because it can't find capsfilter and other core elements. So I get to dive into the test setup code again to figure out why a registry is getting generated that blacklists coreelements...

The train pulled into Boston as I was looking into how the new registry code works and why it blacklists coreelements, so I'll have to save this test for a later day...

Incidentally, I have a day off in Boston this week. I really want to finally go to MIT and follow a class there, in computer science or mathematics. Is that sort of thing open in the US ? Can you just sit in on a class ? Any tips ?

« Previous PageNext Page »
picture