Keyboard layouts


These days, my job finds me writing a lot of PHP code for a business-oriented web portal. This implies quite a few dollar signs, along with parenthesis and quotes. To make my life a little bit easier, realizing the number of times I’m forced to hold shift while typing one of these symbols, I decided to create a keyboard layout that doesn’t requiring shift-holding for the majority of activities.

Unshifted register


Shifted register


The at-sign and double-quote have been swapped so that I don’t have to hold shift for double-quote (which I type very often) but I do have to hold it for at-sign (which doesn’t come up so often).

Some international layouts employ a similar philosophy (see: Slovak layout), requiring the top row to be shifted in order to type a number. While it could get annoying having to hold shift to enter digits all the time, I have two other options for numeric entry. My first option is to engage caps-lock and use the top row as numerals. My second option is to use the numeric keypad.

Caps-lock register


The caps-lock register only applies when SHIFT is not held down. With additional work I could probably split the register in two so that SHIFT+CAPS-LOCK is distinct from the normal shifted register, but for now this will suffice. Notice – among other things – the angle-brackets replacing the square brackets. Clearly, this mode is also useful for entering HTML without shift gymnastics.

But what about muscle memory of all those crazy passwords? Simple: change back to standard layout. This new layout acts as sort of a caps-lock for the symbols I have to type when writing code, and will save my shift keys from grave peril.


MIDI on linux should always be this easy!


#include <stdio.h>
typedef unsigned char u8;

u8 state = 0;
u8 vel = 0;
u8 note = 0;

void read_midi(u8 c)
    if( c & 0x80 )
        state = c >> 4;
    switch( state )
        case 0x8:
        case 0x9:
            note = c;
            state = 0x91;
        case 0x91:
            vel = c;
            state = 0;
            printf("%x %x\n",note,vel);
        case 0xA:
        case 0xB:
        case 0xC:
        case 0xD:

int main(int args, char **argv)
    FILE *midi_in;
    u8 c;
    midi_in = fopen("/dev/midi", "r");
    while( 1 != 2 )
        c = fgetc(midi_in);

    return 0;

That’s how easy it should be to write a MIDI inspection program. And it is, if you’re running linux with the OSS drivers installed. I can’t speak for my other installations that run the 2.6.x kernel, but this Alix box running voyager doesn’t seem to have any trouble exporting a /dev/midi character device to the filesystem, enabling programmers easy access at the data generated by my Keystation, which is hooked up via USB.


Linux server maintenance


For a server that was put in place mid-2007 and remained in service with only three or four reboots until being taken offline near the end of 2010, it has performed quite well. I was asked to perform some maintenance tasks on it, with the expectation that it will be reactivated and placed back online within the next month or so. Here are a few retrospective thoughts that arose during the routine:

The hardware was a solid choice. I had already used the chosen motherboard and identical RAM sticks in my own desktop machine and verified their usability and reliability. When I upgraded my desktop’s RAM to 4 GB, I simply bought new sticks instead of maxing out the available slots, since by that point, the original sticks were no longer sold. This left me with a spare set which I installed in the server as a last step. The hard drives were also a good decision, even if they do tend to run hotter than my own comfort level (hence the heat-sinks and fans).

On to software. Arch Linux is still my OS of choice for servers, mainly because I find it quick and easy to deploy. Plus, if I use the same OS everywhere, I can share configuration files and even binaries more readily, as well as reduce my own administrative learning curve. However, there were a few things that I did differently with this system. I decided upon a custom kernel, which turned out to be a headache when it comes to upgrades. Arch Linux likes to be up-to-date before installing any new software, since it is a rolling distribution and two months down the line dependencies may differ. Since it was a system intended to have guaranteed access at all hours, and wanting to reduce maintenance costs, I had decided not to upgrade the software on the operating system. In practice, this was a good thing, but when it came time to do maintenance more recently, it was a bit of a headache.

Security is another area in which this server performed mightily. Although it may have not been intentional, any and all passwords that I had set on my account (and on the root account) had long since been forgotten. Only the .htpasswd and userland passwords were ones that anybody in the company could recall. This required me to reset the passwords. In the process, I learned that it’s important to reassemble the array before changing passwords; otherwise the /etc/shadow file gets jumbled. Changing the data on each drive individually is not a valid solution! After rebooting several times and performing more than one contiguity check using fsck, I finally managed to set the passwords to more familiar strings. Having a separate partition with a copy of the root filesystem’s /etc folder was also an important feature that was designed-in. It made configuration using the install CD (using mdassemble) much quicker.

The kernel remaining at version 2.6.23 became problematic after running a full system upgrade. Since I had GRUB configured to only boot my custom kernel, and since my custom kernel would not be recompiled by the automatic system update using pacman, I was left with no choice but to burn an installer CD to get the system back up and running. The process taught me how to reinstall all packages in the system (just in case glibc or some other major component got zapped), and revealed to me some of the nuances that took place over the years of Arch Linux’s evolution, such as the way RAID is handled at boot-time by an initrd. I also learned that the operating system itself can stripe swap data across several physical disks, reducing the need for RAID configuration on the swap partitions. This of course means that instead of one mirrored 0.5 GB partition, the OS can now stripe over 1.5 GB on three separate disks. In principle, it should be way more efficient.

All said and done, the server is ready to be redeployed; software has been fully upgraded, and it even has more memory than before.


Image aspect ratios


It’s 2011, and digital broadcast TV is now the norm. Not being the proud owner of a shiny new LCD HDTV, I still watch cable received through NTSC channels sent via coaxial cable from my ISP and cable provider. One thing that annoys me is the lack of attention to detail that often surfaces in broadcast media, specifically when the aspect ratio of a source image is discarded and rendered improperly on a screen.

Most people who owned TV sets before the digital transition watched their programs in the standard NTSC-prescribed 4:3 “almost square” format. Of course, most moves are shot with different aspect ratio, such as 16:9 and end up being reformatted to fit your screen. The proper way to go about this is either to letter-box it (“black bars”) or to crop off the sides (“zoom”). I’m more a fan of letter-boxing personally, but in either case, the aspect ratio was preserved so that peoples’ faces appear with the same roundness that they would in real life.

Most recently I’ve noticed some networks’ commercials have been distorted and stretched, as if the person who performed the editing and final rendering of the video didn’t bother to consider how it would appear on standard televisions. Of course, it could be something the cable company is doing wrong, but having worked in broadcast, it’s my opinion that the broadcaster should not be responsible for poorly formatted material – the buck stops at the producer who is ultimately responsible for transmitting the material to the broadcast site and making sure that it looks and sound correct on-air.

Stretching or compressing an image originally designed for 16:9 to fit into a 4:3 box literally makes people look like pin-heads. In audio terms, it’s the equivalent of playing playing a 33 RPM vinyl record in 45 RPM mode. Sure, it sounds “cool” but you’d hardly want to listen for pleasure and relaxation that way.

Another prime example of this lack of attention to detail is currently evidenced on the Musician’s Friend website. When clicking on an image to view the enlarged version, at first it comes up normally, but when clicking on a next or previous image, it comes up distorted. I’ve written to them about this in hopes of going back to my normal browsing habits when shopping for gear. I’ll post an update when I get a response.


Radio station across town


Recently, I’ve been heavily involved with the transition involved with moving the radio station out of its downtown office and into the new office known as Burnt Mill. Here are a few things I’ve done lately:

– Wrote a console peak meter.
It’s desirable to avoid running an X11 server, and imperative to never put any critical server processes on top of it. The GUI is a nice tool that has its place, but for a system to boot quickly, it must only perform the necessary tasks to revive critical services (in this case, audio streaming). On a similar note, my systems should probably migrate from ext2 to ext3, since journaling will mitigate time lost to running filesystem check (fsck) every twenty-third boot.

I first did a prototype using #!/bin/bash but was unsatisfied by the load placed on the processor. As it turns out, if you use C you don’t have to open and close the device four times every second. You can open it once at runtime and then just use ioclts to get info from the device. My approach was then to take the existing code base of OSS 4.x (Open Sound System — the acronym is ambiguous since it also refers to Open Source Software), modify ossmix.c in place and recompile. By trimming all methods related to write operations, and all unnecessary constants related to objects other than VUMETER, I was able to easily port the shell scrpit’s echo commands which were written using ANSI for colors and some box-drawing Unicode glyphs. I have yet to develop a method to detect whether the shell supports Unicode, but I have gotten some funky results using Putty’s default translation settings (ISO-8859-1). ASCII art using apostrophes, full stops, and hyphens should be sufficient for most.

– Increased latency on the Delta 1010 connected to the on-air system
We’re using a combination of FMPEG and VideoLAN Client to transmit audio from point to point and have had a lot of “audio output is starving” messages. At first, it was packets being dropped. After notifying our provider, they did some investigating, and I haven’t seen any UDP checksum errors since. However, the drivers must communicate effectively with the applications, and must be scheduled accordingly. By changing the /usr/lib/oss/conf/oss_envy24.conf to have envy24_nfrags to a lower number, I reduced the number of messages logged about starving by an order of magnitude.

– Found out that Shoutcast is now being heavily claimed by AOL
Apparently they want royalties for licensing the official Fraunhofer MP3 encoder in order to use their software, and they don’t want VideoLAN to have Shoutcast capability due to licensing conflicts. I could go ahead and use the old version of the software that has been running for over five years on an older machine, or I could move to Icecast which is open sourced.

OSS has its advantages, such as troubleshooting USB drivers. We have a Behringer UCA-202 that we’re trying to use as an audio input to the streaming server. Of course I’d be much happier if it just worked, but OSS has just recently gone open source [again], so I’m prepared to contribute when necessary. By taking the suggestion to modify the src/kernel/drv/oss_usb/ossudb_audio.c file’s write_control_value function to return 1; things started to work (somewhat). Unfortunately the sound card is locked to 48000 sample rate, and my version of Shoutcast expects 44100/16/2. There remains work to be done.


E-mail with Alpine and fdm


I set about changing the way I log into my email account at work today. I like to keep my email clients separate for the different jobs I take on, and one thing that started to annoy me was that every time I wanted to access my email account at the radio station, I had to launch Thunderbird on my extremely slow desktop. If working from home, this meant that I had to use VNC in order to browse my inbox. Being a console junkie who does most of his work via SSH, I decided to pursue a text-mode solution.

Pine is the email client with which I gained the most familiarity during my initial forays into the *NIX world via Super Dimensional Fortress. It later became Alpine for licensing reasons, but it functions almost identically. It is easy for beginners and still has most of what’s needed for advanced users. I’ve used Mutt, but I didn’t grow up with it, so it’s more foreign to me. There’s a difference between what Mutt expects and what Alpine expects in the way they handle mailbox storage. Alpine uses the traditional mbox format, whereas Mutt uses the newer IMAP-oriented Maildir format. This can get messy during configuration of the program that fetches mail, so I had a hard time deciding between fetchmail, which has been accused of security holes, and getmail, which seems to be the newer more flexible cousin. However, I decided to go with what seems like a more streamlined approach and utilize a program called fdm, which I learned about through the Arch Linux Wiki. I may later change my mind and use getmail, but this works.

One problem I had at first was getting the program to log onto the server. Turns out my server doesn’t like APOP commands, so I added the no-apop directive to the ~/.fdm.conf file and it logged in properly:

# Catch-all action (mbox):
action "inbox" mbox "%h/mail/INBOX"
# Account info
account "me" pop3 server "mail***.opentransfer.com" port 110
    user "me@*******.com" pass "*********" no-apop
# Match all mail and deliver using the 'inbox' action.
match all action "inbox"

To make it check automatically, run crontab -e and add the following line:
*/2 * * * * fdm -q fetch

At this point, all that was left was to point Alpine to the new mailbox data file. This is done either from within Alpine using Setup Config inbox-path or editing the .pinerc. It should be set to ~/mail/INBOX. To make sending work correctly, it’s important to fill in the user-domain and smtp-server fields.

Now here’s the cool part: making it obvious that there’s mail whether or not I’m using Alpine. I modded my .bashrc file so that my prompt displays the number of unread messages (if any) in blinking text color. I’m a big fan of writing functions into my .bashrc, so here it is:

	NUMUNRE=`grep -c '^Status: [^R][^R]\?' ~/mail/INBOX`
	NUMSTAT=`grep -c '^Status: ' ~/mail/INBOX `
	NUMFROM=`grep -c '^From ' ~/mail/INBOX`
	if [ "$NUMINBOX" != "0" ] ; then
		echo -ne "\e[5m$NUMINBOX\e[25m "
PS1='\[\e[32m\]$? \[$(numinbox)\]\[\e[4m\]\u@\h \W\[\e[1m\]\$\[\e[0m\] '

Arguments for using the yyyy-mm-dd format


The common way to write a date in the United States is to put the month first followed by a slash and the date e.g. 4/25. In some scenarios it is advisable to prefix the month with a leading zero e.g. 04/25 or in filenames as 04-25 since slashes are typically used as pathname delimiters. This is useful because the most common filename sorting algorithm is alphabetic string comparison, which does not pay attention to the semantically assigned numerical values of the expression, but merely compares the ASCII [or Unicode] value of each character. What can happen is that directories containing files of an entire year will sort improperly when transitioning from 9-31 to 10-01 (or even worse, 10-1). Observe:

If however, we use leading zeroes such that the number of characters used to describe the date remains constant, the files with sort themselves chronologically.

If we apply year to the expression, the American standard is to put it on the end, e.g. 4/25/10 or 04-25-10. For greater clarity, four digits are used: 04-25-2010. One can see that using this convention results in months being clustered with varying year rather than a chronological order:

I’d like to diverge for a moment and mention that the Russian standard is quite different. dd-mm-yyyy e.g. 25.04.2010, or 25.4 for short. This isn’t very useful for sorting filenames, but it does demonstrate the reasons behind the orderings that we use are typically because they reflect the syntax of spoken language, e.g. April the Twenty-fifth as opposed to Двадсать Пятого Апрелья or 4月25日.

Ah, the Japanese system. Much like our own, they put the month first – however it’s more common to see the numerals written in Japanese e.g. 四月二十五日 instead. Their system is different than ours, in that they put the year first, following the spoken tradition of starting with general and then following with more concrete terms. The date format yyyy-mm-dd is useful to us as programmers because filenames will sort in strict chronological order using this nomenclature.

In fact, it is common practice in Linux to specify dates in this format, going from broad to general, and time of day can be included e.g. 2010-04-25 01:55 EDT (GMT-4). Good night.