The Luney Bin: H. Wade Minter

After saying for about a year I was going to do it, I’ve finally revamped the Mr. Voice website. It’s gone from a mostly-broken PHP system to a pretty fun Ruby on Rails-based application. While I’m sure there’s more that I can do with the site, it’s meeting or exceeding the capabilities of the old site, so I flipped the switch this afternoon.

A big win, at least from a mental standpoint, was redoing the database structure to match what Rails expects and, as a side effect, getting a database that was more logically named and laid out than the old one.

One fun thing was reimplementing the XML-RPC API for the client application in Rails. The Mr. Voice software can talk via XML-RPC to the website, so that people can query and share sound clips with other Mr. Voice users. The client software is in Perl, and the previous incarnation of the API was also in Perl, which was pretty forgiving. Moving that over to Rails’ ActionWebService format wasn’t too hard, but there were some small data format issues that I had to work around. Since all of the clients out in the world are still using the old API, though, I rewrote the Perl version to talk to the new database.

I split the information about the Troupes using Mr. Voice into its own table (vs. an XML file in the old system) and added latitude and longitude information. Thus, I was able to use the Cartographer plugin to generate the Users map on the fly from that data. Pretty slick.

Because Rails makes AJAX so easy, I was able to add a few AJAX calls to dynamically render parts of the page, such as the login box, song info box, and shopping cart stuff. I was also able to use RJS templates, so that when you add an item to the cart, a series of effects happen to let you know what’s going on. I also found out that you can drive yourself crazy if you set a global Content-Type header of “text/html”, and then try to figure out why your RJS templates are broken (hint: RJS reponses need to be sent as “text/javascript”).

I was even able to use ActionMailer to implement a “lost key” emailing system and new key request form. Also in the email front, I installed the exception_notification plugin to send me email when something in the app breaks (so I got a few emails when people hit it and tripped over some bugs I hadn’t caught).

So I’m pleased with it. Head on over and check it out!

• Leave a comment... (0)

Yes, it’s later than I had planned, but it’s finally done. And with it, a brand new website: MrVoice.net!

A quick look at the new features:

• A first attempt at an integrated Mr. Voice Online system, where you can browse, upload, and download songs from a shared online repository directly from the Mr. Voice application itself. See the Mr. Voice Online section in the manual for details. Natually, you need an internet connection at your Mr. Voice computer to use this, but my goal is that it will eventually be very easy to search for songs you don’t have during a show, add them, and use them before the audience knows what’s going on.
• Add “bundles” – a way to put songs into the holding tank, then export them in a .zip file that can then be imported into someone else’s Mr. Voice, keeping intact all information about the song.
• Add an option to perform an online check to see if a new version of Mr. Voice is available, once a week. Controlled in the Preferences menu, and you need an internet connection (of course) for it to work.
• Add a feature where if Windows or Linux users drag-and-drop a song file (or files) from the desktop onto the main search box, the add-new-song feature will be launched on those files.
• Add the ability, through an option in the Preferences, to password-protect functions in Mr. Voice that would modify the database. Useful if you have people running sound who might have . . . descructive tendancies.
• Several changes to make MacOS X more usable. The OS X release is packaged in an experimental “application bundle” much like “real” OS X applications. It also uses the free Audion audio player, instead of XMMS under X11.
• New hotkey menu item to clear the Holding Tank in one stroke.

Hopefully people find this one useful!

• Leave a comment... (0)

A post over at Boing Boing piqued my interest a couple of weeks ago. They posted about a company called “gotlogos.com“, who will do a logo design for you for $25. The trick is that you specify the domain name of the site you want a logo for, provide a general description, and they shoot you back a logo a week later. You don’t get any more say than that. So it’s cheap, but it’s a crapshoot.

I’d gotten a little tired of the current Mr. Voice logo, which I did several years ago. For reference sake, it looks like this:

As I’m finishing up a new release of Mr. Voice, this seemed like a good time to risk $25 and see what they could do. I got the logo back yesterday, and I have to say, I like what they did with it. The new Mr. Voice logo is:

I’ve already started incorporating it into the software. I may drop the extra money to get the logo in vector form, so I can resize it easily.

Good work, gotlogos.com!

• Leave a comment... (0)

I had an idea the other day for some new technology in Mr. Voice. I have a website set up for voices from other improv clubs to trade music. They can upload songs that they use, and download songs other people use. But the site doesn’t get much use at all. It’s probably pretty inconvenient to find the raw audio files, HTTP upload them one at a time, and repeat.

So my idea is to build some web services into that website, using XML-RPC or SOAP to hook some of the online functionality directly into Mr. Voice itself. The idea being that you could right-click a song in the search box, choose “Upload this song”, and send it to the website without any further interaction. There is even a possibility for browsing and/or playing songs that exist on the website from within Mr. Voice, just like they were local.

I’m doing some initial tests using XMLRPC::Lite, and the results are pretty promising. I’ve got a CGI XML-RPC server up, and have built a command-line client that can connect to the server and upload a song into the online database. It should be pretty trivial to move that functionality over into the Mr. Voice app itself.

Now the big question is whether to implement the service in XML-RPC or SOAP. The Perl modules for both seem pretty straightforward. XML-RPC appears to be a simpler protocol, which is good, but it’s also somewhat limiting, especially in terms of fault handling. SOAP is more complex, but seems to have a bigger future. If any of my readers have suggestions on which to use, I’m all ears.

Even if this doesn’t get widespread use, it should be fun to code.

• Leave a comment... (0)

Mr. Voice development has been on the back burner since I released 2.0.2 back in early November, mostly due to lack of new ideas on my part. I’ve taken a couple of things off my TODO list, such as adding a debug mode that will dump copious amounts of information into the logs. I’ve also just added a new piece of candy that will allow people to drag an audio file from their desktop and drop it onto the application, which will then bring up the “Add Song” box populated with the information from that file.

One thing I’m tossing around is whether it would be worth it or not to port the app from the Perl/Tk toolkit to the Tcl::Tk Perl module.

Perl/Tk has the advantages of being stable, well-documented, and well-supported by a sizable user community. It is, unfortunately, lacking some of the advances provided by the native Tcl/Tk codebase, such as native support under OS X and better native look-and-feel on platforms. The Perl/Tk codebase has diverged far enough from the Tcl/Tk one that it would take an effort on the part of the Perl/Tk maintainers to incorporate these new features, and they don’t seem very keen on it so far.

Tcl::Tk, on the other hand, has problems of its own. It’s not a self-contained unit, but instead relies on the underlying Tcl/Tk libraries and extensions. So if they’re not on the system, the Perl module can’t use them. That will probably prove problematic for bundling executables. There’s a Perl/Tk compatibility mode in the module that seems to work reasonably well, but still needs work. The biggest problem is that the module is aimed at someone coming from a Tcl background, which isn’t me. The documentation for a lot of the functionality is “Oh, this is the same as in Tcl, which you know.” I have a feeling the learning curve would be pretty steep.

So I don’t know if it’s worth porting or not. Guess I’ll think on that for a while.

• Leave a comment... (0)

I’ve had a weird bug pop up with Mr. Voice 2.x on Windows 98. Yes, apparently some people out there still use it. I develop, build, and test with Windows 2000 as my Windows system (I do most of my development on Linux or OS X, then run through tests on Win2k), so this one took me by surprise.

It seems to have something to do with the DBD::SQLite module not working properly when it has been built on a Win2k system and is running on Win98. Ok, not a big deal, I’ll just throw together a Win98 build system, build it there, problem solved.

However, when I try to do that, it seems to be breaking on the MySQL part of the upgrade utility, which needs to be working for the users. It’s like it’s not even finding the DBD driver, even though I know it’s there. I’ve been working this problem for like a month with no resolution.

Bah. I think I’ll just provide a free pointer to a “warez” Win2k ISO with each download. That would be easier than fixing Windows 98.

• Leave a comment... (0)

Mr. Voice 2.0 is out. Go download it an use it in your improv club. Especially since you don’t have to screw with MySQL any more.

• Leave a comment... (0)

I’m putting the finishing touches on the next release of Mr. Voice. This release will see a version number bump up to 2.0.

The big feature in the new release is a move away from MySQL as the database backend, in favor of SQLite. I’d felt from the beginning that MySQL was a bit of overkill for what I was doing, but it was a lot easier to use it via DBI than it would have been to use flat files. But a suggestion back in May by Derek Lane at the Raleigh Perl Mongers meeting got me looking at SQLite, and I was impressed.

SQLite implements a relational database completely within the Perl DBD driver, without the need to run a database as a separate process. This solves several concerns of mine:

1. Complexity: Mr. Voice uses a very simple database backend – only two tables, and no complex queries. Running an entire relational database engine to manage those two tables was overkill, bbut it was the best solution I had when I started the project. SQLite looks like a much simpler solution, while still being able to do what the software needs.
2. Ease of Installation: Over the years, MySQL was the biggest cause of problems for users. Getting the database installed, the processes running, and the usernames and passwords straight were indeed a pain. SQLite has one configuration option – the path to a single file. That’s it.
3. Resources: MySQL was a fairly heavyweight installation – several gigs of disk space, as well as needing to run an extra process to handle the database. On older or smaller systems, that could be a strain. SQLite doesn’t need any extra processes running, and on my 1300-song database, it takes up 125Kb of disk space.

So I’m hopeful and very interested to see how well SQLite does on the backend.

Other new features include marking, not hiding, invalid songs (songs that have an entry in the database but no corresponding file on disk), support for AAC/MP4/M4A files via the MP4::Info module, and some better logging on Windows.

So there’s not a ton of user-facing new features, but I’m hoping that the new database will make using the program simpler for more people. I’d like to get some beta testing done this coming week, and maybe push out the new release by the end of the month.

• Leave a comment... (0)

At the Raleigh Perl Mongers meeting last night, Derek Lane suggested that I look at SQLite as a database backend for Mr. Voice.

I’m currently using MySQL, which works fine, but it’s a fairly heavy piece of software for how I’m using it. I don’t really need a full-blown RDBMS to store two tables for single-user access. Plus, the end-users of Mr. Voice have to deal with installing and configuring MySQL as part of the Mr. Voice install process.

SQLite is a SQL database that lives in a single on-disk file. The guts of accessing the database are built right into the driver. Or, in other words, the database driver is the entire installation. So if I switched to that, I could cross “database” completely off the list of things for the user to install. The database software would be packaged in with the other perl modules. That’s a big win in my book.

I’ve been messing with it, and I think I’ve got a mostly-converted version of Mr. Voice that uses SQLite. There are a couple of weird things I have to work around. SQLite doesn’t provide a TIMESTAMP value like MySQL does, and I use that to automatically update whenever a row is added or modified. And, even more oddly, the $sth->numrows() function doesn’t actually return the number of rows affected by a statement. I’ve found workarounds for both problems, but they were somewhat surprising (the numrows more than the timestamp).

So I’ll probably play around with this for a bit, to see if it’s a good match for what Mr. Voice does. I want to check out backup and import functionality, speed, and robustness. But things are looking promising so far.

• Leave a comment... (0)

I got my The Perl Journal subscription this morning, so I was able to download the April 2004 issue and read my article.

I think it turned out pretty well – there are only a couple of glaring grammatical things that I should have caught, and somehow a link to the newsgroup comp.lang.perl.tk turned into a URL for http://comp.lang.perl.tk/ (which is a valid website, oddly enough), but on the whole the presentation is solid.

By curious coincidence, Perl guru Randal Schwartz had also written a Perl/Tk article for that issue. So there are Perl/Tk stories from both ends of the spectrum – revered Perl master and “guy who managed to get something to work.” Kind of a yin and yang thing going on. I guess it’s good they cut my Randal Schwartz joke out of my initial draft, then.

I was kinda hoping to get some sort of comment from a reader, either good (“Hey, that was a neat idea”) bad (“Your code sucks!”) or indifferent (“I am acknowledging your presence.”), but so far the ol’ INBOX is empty. I wonder if that means that the topic is so focused that it’s not relevant to most people? I’ll leave that question to the philosophers.

I did spend a good part of the day sending the article to friends and family, posting it on a couple of improv boards, etc. I can’t help it – I’m proud of Mr. Voice, and it’s really cool that I got to write about it in a journal like TPJ. Hopefully other people will be able to glean a little something out of it as well, if nothing more than “You can solve problems in strange ways sometimes.”

• Leave a comment... (0)