I recently had a chance to work on a Cuban Music website – http://www.cuband.com – and hope that it ends up working out.  It has a pretty big catalog of Cuban Music in MP3 format and targets a small market – people that are interested in the classics from Cuba and the newest sound from a whole bunch of genres.

There don’t appear to be too many other sites like this, and certainly none that are as easy to use.  If Cuban Music is your thing, then check out cuband.com today!

(Yeah, this is a shameless plug!)

I was recently looking for an easy way to encrypt individual files and directories (recursively), and I ran across the linux command mcrypt. This nifty little utility does just what I want, but doesn’t do anything fancy – it just does encryption on a single file or standard input.

With a wee bitty script, however, you can encrypt anything you like quite easily. You have to have mcrypt installed (and also tar & bzip2, but you’ve likely got that already). Check this out:

#!/bin/bash
IFS=$’\n’
if [[ -z $3 ]]
then
echo “Use: encrypt [file/directory] [password] [outputname]“
exit
fi
echo “Encrypting $1 with password $2 into file $3″
tar -c $1 | mcrypt -p -q -k $2 > $3
echo “Done with encryption.”

Save it as “encrypt.sh” or whatever other name floats your boat, give it execute permissions, and you’re all set. It will tar, compress, and encrypt your file(s) and directories into whatever output file you specify. Just make sure you don’t forget the password you use to encrypt the file with: there isn’t any easy way to find out what it was if you lose it.

In order to decrypt your data, use this little script:

#!/bin/bash
IFS=$’\n’
if [[ -z $2 ]]
then
echo “Use: decrypt [file/directory] [password]“
exit
fi
echo “Decrypting $1 with password $2″
cat $1 | mdecrypt -q -p -k $2 | tar –x
echo “Done with decryption.”

Save it as “decrypt.sh” and give it execute permissions, and now you can easily decrypt your data as well. It can’t really get much easier than that!

First of all, this device does work fine in Linux. But unfortunately, this USB device won't be recognized by the Linux kernel and so you won't be able to watch all your Family Guy, Simpsons, or Aqua Teen Hunger Force episodes on your PC without adding one line of code to the kernel module driver (perhaps new kernels will eventually recognize it).

There are more than just one type of WinTV USB2 device: the one I have has "Model 42014 Rev D197 Lot # 4405" on the back of it. If you do a 'lsusb', you should see this somewhere in the output:

The device ID is the problem : the driver for this particular model is looking for "2040:4200", not "2040:4201". So, you simply need to edit the driver code and add the right number. To do this, you need to have your kernel source installed and you'll have to know how to configure your kernel for your other hardware. If you're up to the task, then take your favorite editor and open the file '/usr/src/linux/drivers/media/video/em28xx/em28xx-cards.c '. At about line 249 you'll see this:

You'll want to change it to look like this:

You're simply inserting this line:

Save the changes, then go back to your '/usr/src/linux' directory, and do a normal 'make' and make 'modules_install'. As long as you're running the same kernel as the one you are compiling the modules for, you can now do a "modprobe em28xx" and you should be in business! Of course, there are other modules you'll have to load (or compile into the kernel) to get video working in general (look at the 'Video For Linux' section); but this will at least get your hardware talking.

I ran into an interesting "feature" when using two FIFO's in Linux for bi-directional communication between two processes. Basically, I kept encountering a deadlock no matter what I did, and I couldn't figure out why.

Here's the scenario: You have two separate processes (not necessarily parent/child) and two separate FIFO's. Although a FIFO can be used for bi-directional communication, each one will be set up to be uni-directional: Process #1 will write to FIFO #1 and read from FIFO #2, while Process #2 will write to FIFO #2 and read from FIFO #1. Doing things this way allows Process #1 to pass data to Process #2 via FIFO #1, and Process #2 can pass a result back to Process #1 via FIFO #2. This provides an easy way to keep both processes synchronized, because each process will block when reading the FIFO streams.

Each process blocks when opening both FIFOs as well (during initialization, for example) until both a read and a writer are present (which is normal). Once they are opened, Process #1 writes some data (a number, for example) to FIFO #1. Process #2 should receive the data and return a value via FIFO #2. However, no matter what I tried, the data never reached Process #2, and both processes were in deadlock. But if only a single FIFO was used (where data was passed from Process #1 to Process #2 only), everything worked fine!

If you're now asking, "Just what the hell is a FIFO?", then stop reading here. If you want to know what the problem was and the solution, keep reading.

Read the rest of this entry »

I just added a project that I had recently been working on to my site. It's called "VisualODF". If you want the introduction, go here: VisualODF Introduction. If you'd like to see the documentation directly, click this link: VisualODF Documentation.What exactly is this thing? Without repeating the introduction, it is a framework (bunch of classes, really, but I like to throw that word in) written in C++ that form the basis of an application for detecting objects from video streams in the context of a UAV mounted camera. It does everything but the detection part: opening video streams, playing them, capturing frames, sending them to a video display and custom image processing algorithm, display of processed video frame, and display of obstacles on a TCAS-II type display as well as other custom widgets.

It uses QT4, ffmpeg, and SDL to accomplish this. Probably the most useful bits of the classes are the TCAS display itself, the widget plugins (TCAS widget, the so-called "pieDisplay" widget, and a video display widget), and the video-related classes. All of the classes use QT.

The idea behind this was that it would allow a student to actually work on the detection algorithm part of the application, rather than trying to figure out how to open a video stream and grab frames from it or how to convert YUV to RGB.

Hopefully a student somewhere will end up using this for something useful!

I didn't know this until just recently, but a version of Trolltech's QT for Windows exists without having to purchase a license. After doing programming with KDE and QT in a Linux environment and now switching back to working with Windows, I've often thought about how nice it would be to use QT under Windows - but I've always thought that you have to buy it. While buying it is not a bad idea, if you're doing something as a hobby or don't intend to sell your idea it's probably not an option. Using QT can enable you to easily write cross-platform applications that will work in at least Linux and Windows, and probably other Unices and OSX as well.

One place to find the GPL'd version of QT for Windows is at the Vienna University of Technology. There are probably other places that host it as well. The executable pretty much does everything automatically, and the "INSTALL" file will get you going in no-time. You'll be using Trolltech's "Designer" with your C++ IDE (I am using VC++ 6) for writing applications in minutes!

I also was able to easily get the QWT plotting widgets to compile and integrated with QT designer, which means that I should be able to compile code with QT depends in Linux and on my Windows install (in VMWare, that is). Neat!