Reinstalling GRUB2

This has come up a million times (every time I reinstall Windows, in fact), and every time I have to search around online and try to remember how to do it. I figured this most recent time that I would just go ahead and write a blog post about it and be done with it, so here it is.

According to this handy page from the Ubuntu community documentation, there are a couple of ways to skin this particular cat. The one that worked best for me was to take an Alternate CD that I already had on-hand, boot into it, and choose 'Repair an Existing Installation' (or something like that) at the first splash screen (the one where you can check the CD integrity, run memtest, etc.).

Once it gets started, run through the options choosing the default keyboard layout, time zone, etc. When it asks you to choose a root, accompanied by a list of all of the HDD partitions, it appears you may choose any of them (I chose /dev/sda5 on this particular machine, which has Win7 in a primary partition and Ubuntu spread across 3 logical partitions). Then, once it kicks you to a command prompt, type:
sudo grub-install /dev/sda
That's it.

Other easy options that I didn't try include booting into a LiveCD session, then installing and running the boot-repair package (it didn't even show up in the apt-cache when I searched for it, so YMMV). In the program, choose the "First Repair" option and then reboot without the CD in the drive. A GRUB splash should show up proposing both Ubuntu and Windows.

Windows 8 Dev Preview on Lenovo X61 Tablet

I downloaded Microsoft's Windows 8 Developer Preview the other day and decided to try it out on my Lenovo X61 tablet PC. NOTE: This is an older X61, running the Centrino Pro chipset (an older Core2 series chipset). For newer models, you might need to run Windows Update after installing to enable pen/touch input (thanks to reader taytor head for the info).

The trackpoint/eraserhead/navigation nipple/whatever works fine from the get-go, but the middle-button mousewheel emulation does not. It's easily fixed, though, by downloading and installing the driver from Lenovo. After this easy fix, though, I started running into some problems.

First off, my Centrino Pro chipset (Intel Mobile GM965 Express) graphics driver wasn't recognized by default, and every time I tried to install it manually, it failed with an error claiming that the chipset wasn't valid for the driver.

Knowing this to be false, I went and downloaded another copy of the driver from CNET (looks to be a Dell driver, based on some files contained within the driver package). This driver's installation utility failed with an error about an unsupported operating system, which I dealt with by right-clicking on it and going to the 'Compatibility' tab and choosing Windows Vista (no Service Packs) as the compatibility target. After that, the installer ran just fine. Now I have Aero and transparency and everything.

Out of the box, the system recognizes my stylus and allows for pen input and screen calibration. However, I wanted a few features that are only available from the official Wacom driver, so I downloaded it and tried to install it. The installation went fine, but upon reboot, the system no longer recognized my stylus at all. When I went to the control panels and clicked on the Wacom driver panel, it choked and failed with an error about how there were no compatible interfaces found on the system.... Luckily, after uninstalling the driver from my Programs list and uninstalling the drivers from the device manager, all is well again, though I'm stuck with the generic, MS driver.

Other than those hiccups, everything seems to be working well. The system is overtly similar to Windows 7, only with sharp corners and a little less transparency everywhere. Window borders are more opaque now, and they no longer have the Vista-style reflection/glare effects.

The 'ribbon' menu style has been adopted throughout the system and, while I don't really like it, I suspect it will grow on me, much like it did when introduced to Office 2007.

Before my video driver was installed, the Metro UI was horribly slow and took several seconds to transition to and from the traditional desktop view. However, with the driver installed, everything is snappy and attractive.

At this point, the Metro UI is sort of useless and is just a glorified launcher, but MS intends to have the launcher squares configurable and with live updates (i.e., your buddies list will update with who is online, the weather application will show live weather, etc.). However, applications will have to be written especially for the Metro UI using a new API, and MS intends to charge developers 30% of revenue for Metro apps, just like Apple does with their App Store.

If you have any questions about Windows 8 in general or its use on this computer, specifically, drop me a comment.

CCSM Locale Not Supported Error

My HTPC's compizconfig-settings-manager (ccsm) started failing to launch whenever I clicked on the link, so I tried to run it from the terminal to see what was up. When I did, I saw that it was coughing up this error:

(ccsm:8581): Gtk-WARNING **: Locale not supported by C library.
        Using the fallback 'C' locale.
Info: No sexy-python package found, don't worry it's optional.
Traceback (most recent call last):
  File "/usr/bin/ccsm", line 38, in 
    import ccm
  File "/usr/lib/python2.5/site-packages/ccm/__init__.py", line 1, in 
    from ccm.Conflicts import *
  File "/usr/lib/python2.5/site-packages/ccm/Conflicts.py", line 26, in 
    from ccm.Constants import *
  File "/usr/lib/python2.5/site-packages/ccm/Constants.py", line 72, in 
    locale.setlocale(locale.LC_ALL, "")
  File "/usr/lib/python2.5/locale.py", line 476, in setlocale
    return _setlocale(category, locale)
locale.Error: unsupported locale setting

Turns out the fix is pretty simple. Just open up a terminal and type:

LC_All=en_US.utf8
Lang=en_US.utf8
ccsm

one after another.

Unfortunately, this fix doesn't seem to stick, so you have to do it every time you want to launch.

Intermediate Guide to SF4 EMG (Model) Swapping

Sloth86 has cracked model manipulation in SF4 wide open. It's now possible to swap models from character to character and costume to costume in a fairly consistent manner, thanks to sloth86's research. Additionally, he was nice enough to write simple, straightforward graphical tools that extend this ability to almost anyone. Just to be clear, though: this procedure often produces strange results, especially with respect to animations. Sometimes these results can be fixed through model editing, sometimes not.

In this tutorial, we're going to use sloth86's methods to take an EMG model from one character and replace it with an EMG model from another character.

First things first, lets get all of the tools we'll need. This is a pretty advanced procedure, so we're going to need piecemontee's SF4Viewer (aka, Asset Explorer), Kensou's Tool(s) and Sloth's tools, specifically, EMGSwap and DDSREFEDIT. Once you have those tools downloaded and organized, we're ready to get started.

First, identify which model you want to move and where you want to put it. I'm planning to take Guy's head (donor model) and place it on Ryu's body (recipient model).

Once you've got it all planned out, open both models (for me, GUY_01.obj.emo and RYU_01.obj.emo) in the Asset Explorer and find the desired objects--in my case Guy's 8th EMG (counting each model, starting from the top in the Asset Explorer's display)--and I'm going to replace Ryu's 12th EMG. The recipient's numbers are important, so write it/them down.

Now, select the donor object, right-click and choose 'Raw dump,' name it something informative (I chose face.emg) and click 'save.'

Next, armed with our model files and numbers, place both the donor *.emg file and recipient *.obj.emo file into the same directory as EMGSwap and double-click on EMGSwap to run it.

This window should pop up:

In the field labeled "Input EMO file," type the name of the recipient model, in my case RYU_01.obj.emo. Then, in the field labeled "EMG # to swap out," type the number of the recipient model you wish to replace, in my case 12 (for Ryu's 12th EMG model, the face). Next, in the field labeled "EMG file to swap in," type in the name of our raw-dumped donor model, in my case face.emg. Finally, in the field labeled "Output EMO file," we'll just leave the default 'new.emo' for now (we'll rename it to replace the old model later, but in the meantime, we don't want to mess anything up before we're sure it's cool).

Click 'Go' and cross your fingers. If all goes well, you should see a window like this pop up:

Looks good so far.

Now, lets check out our Frankenstein's monster by opening the 'new.emo' file in the Asset Explorer:

Yeesh, looks pretty freaky. Since Guy's head was sized and positioned significantly differently from Ryu's, we're going to have to change some things up to make it look normal again.

So, still in the Asset Explorer, lets select our newly imported model, right-click and choose 'Extract...' from the menu. Name it something informative--like face.obj--and click 'save.'

At this point, you might be asking yourself, "if I'm extracting and converting into an obj anyway, why didn't I just export from Guy's model and import straight into Ryu's model in the Asset Explorer, skipping all this EMGSwap bullshit?" Well, smarty-pants, most files in AE (including the *.obj.emo files we're messing with right now) include an index that includes the location and size of each and every file contained within. The Asset Explorer uses this index to determine what can and can't be extracted/injected safely.

However, sloth86's EMGSwap tool rewrites this index for us, so the Asset Explorer can safely extract/inject our borrowed models once EMGSwap has done its thing. Perhaps someday that same functionality will be integrated directly into the Asset Explorer (it's open source, after all), but that day is not today.

Anyway, so we've gotten our model swapped in, but it looks like crap and we'll need to use model editing to fix it. I'm not going to spend a lot of time on this part, since you should already know about model editing enough to fix things yourself. For me, Guy's head was the wrong size, so I needed to enlarge it and move it around a bit. I really should edit Ryu's neck to meet the head, too, but you get the idea...

Alright, with my edits in place, the model looks okay, but you'll notice that the skin looks all white and pasty. That's because it's looking to Ryu's first DDS texture, which corresponds to--you guessed it--his duffel bag. This is actually convenient for my purposes, since I can just replace the duffel texture with my donor texture. Thus, I won't need to edit a bunch of DDS references using sloth86's DDSREFEDIT tool, but you probably will (hence, why I included it in the tools you'd need to download).

I'm only going to use it a little, but I'll try to tell you more about it when the time comes.

In the meantime, we need to create some new texture and normal map containers to go with our new model. To do it, we'll use Kensou's sf4tool, just like in this earlier tutorial I made.

Open your donor's *.col.emb and *.nml.emb files in the Asset Explorer, find the textures that correspond to your donated model, right-click and choose to 'Extract...' them. Name them something informative (I used 'Guy.dds' and 'Guynmap.dds') and click 'save.'

Next, open your recipient's *.col.emb and *.nml.emb files in the Asset Explorer an extract *ALL* of his or her DDS textures. Be sure to name them something informative so you can remember which order they're stored (1.dds, 2.dds, etc. and 1nmap.dds, 2nmap.dds, etc. work well).

Now, as per the aforementioned tutorial, create new *.col.emb and *.nml.emb files with your donated textures in the first position. (I actually replaced my recipient's first textures, so the order for mine was Guy.dds, 2.dds, etc. and Guynmap.dds, 2nmap.dds, etc.) EDIT: I used the first position, but apparently the *last* position is more likely to work...?

At this point, you would run the DDSREFEDIT tool and input the number '0' into the 'new texture map' field and '1' into the 'new normal map' fields (assuming your recipient only had a single texture to begin with; this isn't the case with shoto original costumes, though, so count the textures if you need to, according to the instructions in the program; I had to use '5' for the normal map number), your modified *.obj.emo file in the 'Input EMO file' field, and the number of your recipient's replaced model in the EMG # field (in my case, it was '12'). You would then check the box for '+1 to every other normal map references' (this last bit was unnecessary for me because I replaced the duffel bag normal map with the donated normal map).

This was my result:

Anyway, if this last part seems confusing, don't worry about it. I'll be making another tutorial that goes over the texture reassignment tool using a more typical example in the future. In the meantime, try your best, share your work and ALWAYS MAKE BACKUPS.

Test Driving Oneiric Ocelot on ThinkPad X120e

It's that time again. With another Ubuntu release looming on the horizon, I decided to upgrade my netbook to the latest daily build (8/12/11) of Ubuntu 11.10 Oneiric Ocelot, which is still in alpha stage.

Installation

Installation was unchanged from 11.04, so much so, in fact, that it even says "Welcome to Natty Narwhal" :P

As with Natty, installation was quick and easy, with the option to download updates in the background as you go. As before, personalization questions were presented *after* installation had already begun, which saves even more time.

First Impressions

The login screen has changed a bit, and now looks really snazzy, with a stylish dot motif in the background. There's an option to select a Guest Account, along with the option to use the new 2D/non-accelerated Unity desktop, which I believe is powered by the Enlightenment libraries. This 2D desktop supports true transparency, which is nice.

Drivers

The jockey-powered "Additional Drivers" utility automatically found the binary driver for my wireless, which is the nonstandard Broadcom chipset option, so all I had to do is tell it to activate it. CORRECTION: My wireless driver was enabled, but not working. On returning to jockey, the driver was listed as not installed and if I tried to enable it, it would give me the error:

SystemError: E:Unable to correct problems, you have held broken packages.

This suggests that my packages were installed, but somehow got messed up. To fix it, I had to find out which packages for my chipset were installed, by typing:

dpkg -l | grep roadcom

(notice, I searched for 'roadcom,' which will catch packages with both 'broadcom' and 'Broadcom' in the title and/or description. This is important, as the bcmwl-kernel-source package will not show up if you search for 'broadcom' alone.) Then remove them entirely by typing

sudo apt-get purge [package names from the previous command]

Reboot, then try the 'Additional Drivers' utility again. It should successfully enable the driver, then you can reboot again and everything should be working properly.

If you got the standard chipset, it should use the open source driver by default. The default video driver is the Gallium-3D-driven open source driver, but I chose to install the proprietary fglrx driver from AMD via the driver utility.

Audio seems fine and my HDMI audio hardware and output were both recognized from the start. The headphone jack also properly mutes the internal speakers when headphones are plugged in, which is an improvement over my experience with Natty.

Waking from suspend seems fine, too, though hibernation still seems to be a no-go. :(

Applications

The default email client is now Thunderbird, which works well with Firefox, the default browser, and the default music client is now banshee (this may not have been a new change; I can't really remember...).

The built-in search tool for Unity is much improved, with little icons down at the bottom of the window for choosing whether to search everything, just files and folders, just applications, or just search your music collection.

Everything seems to be fine so far, a solid improvement over Natty on these machines. I'll post back if I run into any problems. If you have any questions or experience any problems, post a comment!

My DIY Backloaded Horn

Over the past 6 months or so, I've been researching and ultimately building a pair of backloaded horns. At the time of this writing, I've only actually finished one of them, but I decided to go ahead and make a post about it.

My Phase Technology Teatro 7.5s sound great, but they're pretty weak on the low-end. I've been supplementing with a shitty powered subwoofer scavenged from a boxed 5.1 surround system, but it just doesn't cut it, unfortunately, so I decided to build some speakers that would cover it a little better.

Since getting my upper-mid horns and hearing their clarity and definition, I wanted to go with another horn for the bass, if possible. I've seen a lot of really crazy, gigantic basshorns on the internet and wanted to avoid the size that would be required to reach below 100 Hz with a compression driver--not to mention the batshit crazy prices that large-scale compression drivers go for on eBay and Audiogon--so I decided to look into backloaded horns.

Ideally, a horn should be as long as the wavelength of the lowest frequency you wish to reproduce, with a mouth of approximately that same diameter, thus bass horns have to be gigantic to reach low frequencies. You can cheat a little, though, by placing the horn against the floor and/or wall of your room, which lets you cut the wavelength requirement by half for each surface, as it uses the walls/floor as if they were a part of the horn. Furthermore, backloaded horns are typically folded horns, which lets them squeeze a lot of length into a relatively small package. Finally, by starting with a large cone driver, your required horn length is reduced further still.

I used this 8" driver for the horns, based on their high sensitivity, though these would also be an excellent alternative. If you don't plan to supplement the horns with a tweeter like I intend to do, you might also consider using a full-range driver, like this one, though it is obviously more expensive. This driver is another good option if you want to play at high volumes, due to its high power handling and *huge* cone excursion.

I came up with my own design for the horn itself, based loosely on some designs I found around online. However, most of the designs I found have the mouth of the horn opening into the wall, which I was afraid would deaden the sound, based on how directive my upper mid horns are. So, I tweaked those designs a bit and ended up with something I could construct out of a single sheet of 4'x8' of wood (MDF [medium-density fiberboard] is the best for speakers, but it's heavy, expensive and rough on your tools; particleboard is a good compromise, IMO, insofar as it is very cheap, but with many of the same characteristics as the more expensive MDF; plywood works, too, but it's ugly).

I used 1/2" particleboard, though TBH, 3/4" would probably have been a better choice, both for rigidity and sound isolation. The sides are 2'x4', the back is 1'x4' and everything else is 1'x2' (i.e., the front, the top/bottom and the interior partitions; the last piece is cut in half and glued together at a right angle). I'm not going to go into much detail about the actual construction, since I'm a shitty carpenter and I'm sure you can find better instructions on box-making online than I could ever provide. Anyway...

Glue the pieces together using wood glue, and don't be afraid to really gob it on. You want it to seep into all of those little nooks and crannies in the wood and form a good seal. You can see the excess squeezing out from under the board in this pic:

To be sure that the junctions are all airtight and won't be leaking air into each adjacent chambers, you can follow behind with silicone caulk or "liquid nails" formulated for wood, which is what I used:

If you look closely, you can also see the right-angle brackets I used to reinforce the box structure.

After all of the interior structure is glued solidly into place, you can glue the other side panel to seal the cabinet shut. I used the liquid nails instead of wood glue to seal it, with a bunch of cinder blocks, books, records, etc. piled on top to get a good connection while the goo dries:

One thing to remember before sealing the cabinet: go ahead and thread some speaker wire through because it'll be much easier now than if you wait. If you do forget (like I did, actually), you can tie the wire around something (I used my dog's Kong toy), drop it into the speaker hole and then flip the whole thing around until it pops out the mouth of the horn. This is harder than it sounds, though, because these horns are gigantic and heavy as shit.

Another bit of advice, do your painting *after* your gluing (unlike me), so you don't have to worry about excess glue spilling over onto your fancy paint job.

Most of the projects I've seen online make a big deal about filling any cavities with sand or kitty litter so they don't turn into resonance chambers, but I don't really notice any problems and I did not do it. Of course, YMMV.

Anyway, here's the finished product:

You can see my small upper mid horn perched on top. You can also see the speaker wire dangling out of the mouth of the horn, since I haven't purchased proper binding posts yet (maybe never...).

As far as the sound, the bass response is considerably more potent than I expected. The driver works as a direct radiator (so better quality drivers will make a noticeable difference in sound quality), while the low frequencies bounce around inside and bellow out of the horn's mouth. The horn produces some of the clearest, most defined bass I've ever encountered, though it is definitely lacking above 1 kHz. That in mind, I intend to pair it with either this tweeter or this one.

One last picture of the finished horn, this time from the side:

The depth is really what makes these guys huge. Special thanks to my wife, who is gracious and long-suffering :-P

How to Create High-Resolution Textures in SSF4AE - PC

This tutorial covers how to create *.col.emb files from scratch using Kensou's Tools. These files can contain any number or variety of DDS textures of any size/resolution or compression type (DXT*). The most common usage for this is to create textures that are higher resolution than the default textures, but it can be used for other purposes, as well.

Sensibeat's tutorial for making high-resolution textures is much more informative, but requires a level of comfort working with hexadecimal code and calculations. This method is considerably easier but you should still try to understand sensibeat's instructions since the same techniques are helpful in other aspects of modding.

Anyway, lets get started. All you need are piecemontee's Asset Explorer and Kensou's sf4tool.

Step 1. Open a *.col.emb file in the Asset Explorer and extract the DDS textures. Name them something simple that reflects the order they're supposed to come in (I like to use 1.dds, 2.dds, etc.).

Step 2. Open the DDS textures in a paint/editing program, such as Photoshop or GIMP, and scale them to the desired resolution. In this case, I'm scaling a bunch of 512x512 textures up to 1024x1024.

Step 3. Save the textures as new DDS files with any compression you like. This is your opportunity to change, for example, DXT1 textures into DXT5 to allow for semi-tranparency.

Step 4. Now, open the directory for Kensou's sf4tool.exe (NOT sf4toolnew.exe). If you don't have a directory named 'emb' in there, create it now, and then put your enlarged DDS textures into it. Next, run sf4tool.exe by double-clicking it.

Step 5. In the big file-directory pane on the upper-right of the window, double-click on your emb directory and click on the left-hand button underneath the big pane. The smaller pane to the left should populate with your files. Put them in the proper order by changing the filenames in the smaller pane (you can just click in there and type) and then click on the right-hand button to bundle them all together.

Step 6. Back in your 'emb' directory, you should have a new file called 'newpack.emz.' Rename it to match the col file you're trying to create, in my case GKI_01_01.col.emb.

All set! The *.col.emb file you're left with is formatted a little strangely and contains some garbage hex in the index and at the end of the file, but AE doesn't seem to care, so neither do I. :P

You can now use the Asset Explorer to extract/inject textures from your new file using the new textures as a base for mods.