- Click here for a list of all my projects.
- Click here for Touchlib info. Source code here.
- Click here for our multitouch community site.
Sunday, December 31, 2006
I'm just curious if anyone is using Touchlib yet and/or what you are planning to create with it. Post in the comments section. I've already helped a few people get the library compiled in #ftir on IRC. If anyone else is having trouble, they can feel free to drop me a mail or drop by the IRC channel.
Genome Progress 2

Having some days off from work has given me some good opportunities to work on Genome. I finished up a bunch of "under the hood" changes to the way Genome references parameters and modules. Now modules and their parameters can be referenced with an XPath type syntax (XML-like). This allows for selecting multiple modules with one path command. All of this will be useful when people want to build their own control surfaces or write scripts for generating notes or control data. I also started working on redoing the GUI with spiffier widgets. This will be my next big effort.
Tuesday, December 26, 2006
Paniq's Buzz Clone update
Paniq posted an update on his Buzz clone. He talks about his DSP scripting language based on the popular Lua and his plans to branch the project into two. Unfortunately it looks like he's ditching windows support in favor of linux.
UPDATE:
Here's the link to the Buzzchurch forum topic on the subject.
In other Buzz related news, it looks like www.buzzmachines.com (the central hub for all things Buzz) is down again for the moment. No doubt it will re-materialize again at some point. It's too bad they can't get a decent, permanent server for the site. Even with a few Google ads, it should make enough money to support itself, given the traffic it probably gets.
UPDATE:
Here's the link to the Buzzchurch forum topic on the subject.
In other Buzz related news, it looks like www.buzzmachines.com (the central hub for all things Buzz) is down again for the moment. No doubt it will re-materialize again at some point. It's too bad they can't get a decent, permanent server for the site. Even with a few Google ads, it should make enough money to support itself, given the traffic it probably gets.
Thursday, December 21, 2006
Genome Progress 1
Work continues on my multi-touch enabled music software, Genome. I've been using Freemind to make some diagrams of the interactions of the various classes which is working out very well. Being able to link multiple mindmaps together is a nice feature that I'm starting to get some mileage out of. I'm planning on making some large 'under-the-hood' changes. One is to change the way that parameters are referenced from the UI layer. Before I required each one to have a unique name - this required some naming hacks which I didn't like. Now, you'll be able to reference them by their place in the hierarchy using some XPath like statements. This way it'll be easy to say 'change the pitch of all the oscillators of all the voices in this synth'. It also makes it possible to reference specific parameters like 'just change the pitch of OSC1 in Voice1'. This will come in handy when I add the ability to make custom Control Surfaces. These control surfaces will add the ability to build custom synths, but they will also add the ability to build a simplified interface to your music tracks. This is something I have wanted to do in Buzz for a long time. Basically it would let you just put the controls you are interested in on the screen and also unify several modules into one interface. So, lets say I have a track which has an analog synth running through a tremolo effect. I can create a control surface that lets me put the analog synth's filter cutoff knob and the tremolo effect depth knob on one page - that way I can limit the view to just the parameters I'm interested in or that I want to tweak. Adding the controls would just be a matter of picking which parameters from the sub modules you are interested in. With the ability to attach scripting logic to the control surface and also record your knob tweaking, this could be a powerful feature.
I also did some brainstorming about the patch library situation. Patches are files of module settings which users save when they find some settings they like. In this case they can be settings for a single module or for a module that contains a hierarchy of modules (such as a song-track or an instrument). Instead of having patches all over your hard drive like now, patches will be added to a central database, similar to how iTunes works. The goal is to make it easier to manage and find patches. You'll be able to set meta-data on patches such as author, rating, category, sub-category which will make it easy to find what you are looking for. It will also be possible to publish your patches to a community website which will contain a master list of patches and to download other user-made patches (all from within the program). This is a big advantage over VST which leaves it up to the individual VST instruments to manage their patches or leaves it up to you to manage your directories. VST hosts typically don't offer much in the way of patch management.
I also did some brainstorming about the patch library situation. Patches are files of module settings which users save when they find some settings they like. In this case they can be settings for a single module or for a module that contains a hierarchy of modules (such as a song-track or an instrument). Instead of having patches all over your hard drive like now, patches will be added to a central database, similar to how iTunes works. The goal is to make it easier to manage and find patches. You'll be able to set meta-data on patches such as author, rating, category, sub-category which will make it easy to find what you are looking for. It will also be possible to publish your patches to a community website which will contain a master list of patches and to download other user-made patches (all from within the program). This is a big advantage over VST which leaves it up to the individual VST instruments to manage their patches or leaves it up to you to manage your directories. VST hosts typically don't offer much in the way of patch management.
NY Times article on Wii controllers
Just a little article on the technology in the Wii-mote. Read it here
Labels: Nintendo Wii, wiimote
Tuesday, December 19, 2006
Wii News
The forecast channel came online this morning, offering weather from around the world. Also, the beta version of the opera browser for the Wii hits this Friday. Yay!
Thursday, December 14, 2006
Genome, Collaborative music applications
Did a bit more work on Genome yesterday which hopefully means I've broken my spell of 'Programmers Block'. The problem is that genome is just a big application. Even though it's fairly cleanly written I still have trouble remembering where to look for things in it's 200+ source files. Some diagrams may be in order.. My next goal will be improving the GUI and making it a bit easier to use. Once I pretty things up, I'll post some pics.
I listened in on some interesting online discussions with Paniq, who is also working on a sequencer in the same vein as Buzz. Both of us would like to make a music program which encourages community via the sharing of song files. In the early days of computer based music, people could share songs rather easily, since each song contained all the patterns and audio samples necessary for the song. Sharing songs allows people to learn from each other, borrow things they like, remix other artists' work and also contribute to the community. These days we have plugin (.DLL) based instruments, some of which are commercial (not free). So we can no longer count on everyone having what it takes to play the song on their computer. Almost no one exchanges songs written in Cubase or Cakewalk. With Buzz, all the plugins are Free, however keeping up to date with the hundreds of plugins becomes a chore in itself. There are a couple solutions to this problem.
1. Plugins could be free or commercial. We would automate the process of purchasing / downloading the necessary components by having the program interface with a central website. This would allow a la carte purchasing/downloading of instruments, presets, etc all within the application. Think of it as i-tunes (or Steam) for music sequencers. This could also help with the software piracy situation since the server tracks your purchases. Free plugins could be automatically downloaded from the server if the song requires them or you could select them from a catalog. The application could check daily for new user-authored components and download them in the background.
2. Do away with traditional .DLL plugins. Plugins could be authored with a scripting language and included in the song. Paniq plans to use a system based on Faust which is a script language that is compiled into C++ code (which is then compiled again..). The method I plan to use is to allow users to build instruments similar to how the Nord Modular and Synthedit work - by visually connecting modules. It's true that this approach doesn't allow the fine control that you would get from scripting or coding an instrument - you can't write your own filters or oscillators, but I think it gets you 90% of the way there and it's more accessible to the average user. By offering a variety of modules you can make up for some of it's limitations. I already have source code written for everything from virtual analog oscillators, additive synthesis, FM and just about every type of effect. It will be very easy to turn this code into modules. Of course you won't be required to build your own instruments - Genome will ship with all the pre-requisites. This is just for the people who want to use it.
Scripting still has a place - it would be interesting to allow the creation of custom control surfaces which contain scripts. You could create surfaces that allow for algorithmic note generation, arpeggiation, unique note layouts, etc.. These surfaces could control multiple modules at the same time.
I listened in on some interesting online discussions with Paniq, who is also working on a sequencer in the same vein as Buzz. Both of us would like to make a music program which encourages community via the sharing of song files. In the early days of computer based music, people could share songs rather easily, since each song contained all the patterns and audio samples necessary for the song. Sharing songs allows people to learn from each other, borrow things they like, remix other artists' work and also contribute to the community. These days we have plugin (.DLL) based instruments, some of which are commercial (not free). So we can no longer count on everyone having what it takes to play the song on their computer. Almost no one exchanges songs written in Cubase or Cakewalk. With Buzz, all the plugins are Free, however keeping up to date with the hundreds of plugins becomes a chore in itself. There are a couple solutions to this problem.
1. Plugins could be free or commercial. We would automate the process of purchasing / downloading the necessary components by having the program interface with a central website. This would allow a la carte purchasing/downloading of instruments, presets, etc all within the application. Think of it as i-tunes (or Steam) for music sequencers. This could also help with the software piracy situation since the server tracks your purchases. Free plugins could be automatically downloaded from the server if the song requires them or you could select them from a catalog. The application could check daily for new user-authored components and download them in the background.
2. Do away with traditional .DLL plugins. Plugins could be authored with a scripting language and included in the song. Paniq plans to use a system based on Faust which is a script language that is compiled into C++ code (which is then compiled again..). The method I plan to use is to allow users to build instruments similar to how the Nord Modular and Synthedit work - by visually connecting modules. It's true that this approach doesn't allow the fine control that you would get from scripting or coding an instrument - you can't write your own filters or oscillators, but I think it gets you 90% of the way there and it's more accessible to the average user. By offering a variety of modules you can make up for some of it's limitations. I already have source code written for everything from virtual analog oscillators, additive synthesis, FM and just about every type of effect. It will be very easy to turn this code into modules. Of course you won't be required to build your own instruments - Genome will ship with all the pre-requisites. This is just for the people who want to use it.
Scripting still has a place - it would be interesting to allow the creation of custom control surfaces which contain scripts. You could create surfaces that allow for algorithmic note generation, arpeggiation, unique note layouts, etc.. These surfaces could control multiple modules at the same time.
Labels: Genome
Tuesday, December 12, 2006
Final Fantasy XII Critique

There are many great things about FFXII. The graphics are great, voice acting great, the production is top notch, etc. However, there are some things I've been finding highly irritating about it lately. As an armchair game designer myself, here are my critiques:
- Dungeons are too long and boring. There are a couple reasons for this: They have you killing the same 2-3 enemies over and over. Plus many times the artists have recycled models and animations from previous monsters so they are not even that unique. Enemy AI is generally pretty dumb, but this is standard for FF games. Also, the save points are too few and far between. This forces you to play an extra 20 minutes in some cases just to save the friggin' game. This is 2006 people, why can't we save wherever we want? If companies really want to cater more towards casual game players, this is a good place to start. Though, I think most people would probably argue that this isn't a game for casual players.
- The towns are too spread out. It can take a minute or two just to walk to the store you want to go to. Why can't I just click on the map to go there?
- Combat is less strategic due to it's semi-realtime nature. Having a set turn order forced you to make interesting decisions. Now you can just set up some gambits and let your characters do what they want. This does save you from some tedium but also makes it feel like you're not really playing. We need to give the player something to do other than just watch health levels and heal at the right time. Like give damage bonuses for flanking your enemies, for using the environment to your advantage, for choosing the proper attack posture, etc.. Combat that is entirely based on stats and not on user skill/strategy is boring.
- Spell weaknesses aren't predictable. In FFX, you always knew that Fire based enemies were vulnerable to Ice, mechanical enemies are vulnerable to lightning, etc. It's rewarding to 'crack the code'. In FFXII you can't really guess, you have to use the Libra spell.
- Mostly random treasure chests sitting out in the open, with lame items. Getting 100 chests that each have 53 Gil in them is less satisfying than finding one hidden chest with 1000 gil or a nice item in it. The really good weapons are practically impossible to get without owning the strategy guide due to the complicated and illogical series of things you have to do to get them (for instance, you can only get certain items if you DON'T open certain treasure chests earlier in the game. WTF?). And:
- Almost everything can be bought in the stores (even most of the Bazaar items). Combined with the last bullet point, it kinda takes the fun out of exploration for me. In past FF games, you knew that exploring every dead end usually got you some kind of sweet item or some good money. Now you are lucky if you find a potion.
- The Bazaar, where you can unlock items by selling rare 'loot' is a nice idea in theory, but the thought of spending hours killing the same monsters, trying to find one really rare piece of loot, kinda churns my stomach.
- Too much walking around and travelling through areas you have already explored. Good level designs usually open up shortcuts so you don't have to walk as far if you are forced to backtrack. This rarely happens in FFXII. See Metroid Prime for an example of a game with huge environments that saves you from having to backtrack with good level design.
- The game is entirely non-linear in the sense that you can always revisit any locale. Also, it's up to you to choose when to pursue the side quests. This can be good and bad. Personally I always find it weird when a game lets you do menial side quests when there are urgent events happening elsewhere. It kills the suspension of disbelief for me.
- Thanks to the license board, you give all your characters the same skills. There's no reason why you wouldn't want to get all the spells for every character. This diminishes the sense of individuality of the characters and makes each one less strategically useful (since no one really excels at anything). The only differentiating factor is stats.
- Story starts out promising but gets a little bit hard to grasp and kind of 'Blah'. Ashe's motivation is difficult to understand. Yeah, she's supposed want revenge for her husband's death, but she never comes across as being very upset or angry about it. Van and Penelo are kind of just along for the ride - there's no real story reason why they should be there (though I think you could say the same for some of the other characters as well). Basch is pretty cool but he ends up being sidelined by the other characters. That said, all the characters are likeable which they deserve kudos for.
The bottom line: Maybe I'm just getting old, but I'd much rather have a 20 or 40 hour game that is consistently entertaining, rather than an 80 hour game that gets most of it's length from dungeon crawling (and re-crawling).
Labels: FinalFantasy, PS2
Monday, December 11, 2006
"Out of Stock" Page Checker

I just made a little utility for myself in Flash. Basically, it lets you check a number of web pages for a specific string, such as "not currently available". I made this for those of us who may be looking for out of stock items and want to know the moment they become available (*cough* Nintendo Wii Remote *cough*). You can find it here. Basically you just enter a URL to the item and the "out of stock" text (note: you could also enter the name of a gif if the out of stock notice is an image). It assumes that when this text goes away, the item is in stock. It re-checks the pages every minute and beeps if it finds something. Your list of sites is saved on your computer so it will be there next time you come back (I need to add a way to delete sites.. hmm). Enjoy!
Speaking of utilities: Have you ever wanted to save something from a website (like an .mp3) but Internet Explorer keeps opening the link instead of allowing you to save it? You can use this page to get yourself a link that you can right click on.
Speaking of utilities: Have you ever wanted to save something from a website (like an .mp3) but Internet Explorer keeps opening the link instead of allowing you to save it? You can use this page to get yourself a link that you can right click on.
UPDATE: I finally got an extra Wii-mote off amazon.com after several days of obsessive checking. I'm glad I didn't cave in and buy one off ebay - those scalpers don't deserve to make a profit by making these things hard to find for the rest of us. Now I need to find the nunchuck attachment...
Tuesday, December 05, 2006
Wiimote on PC update
A couple of my questions are answered - apparently it is using bluetooth. A bit disappointing though is the fact that this is solely using the Wiimote's motion sensors, not the sensor bar which would allow for more accurate pointing. It should still be possible to use the sensor bar input method someday - it's only a matter of time before the Wii hacking community figures it out. I'm surprised they've figured out this much already. Here's a little video:
Monday, December 04, 2006
Digg style site for game developers
DevBump is the name of the site. Nice to see a portal for this sort of thing finally. GameDev.net and Gamasutra.com are two other sites I check occasionally.
Use a Wiimote with your PC?
An application called GlovePIE claims to have added support for using the Wiimote as an input device for the PC. GlovePIE is a flexible, script based program that can allow you to use input devices like VR gloves to send/emulate a variety of outputs, such as MIDI, joystick, mouse, OSC and more. I haven't tried it yet and the website is a little short on specifics (like how it reads input from the wiimote.. Bluetooth I'm guessing). I think the Wiimote would make a pretty cool computer interface (better than a mouse) since it can produce extra information like distance from the screen (Z depth) and rotation (not to mention motion). Maybe I will try to build a wii-mote someday using a webcam... It shouldn't be too hard to adapt the core parts of Touchlib to work with it.
Interestingly, I've already known about GlovePIE for a while now. I first heard about it when I did a little work with the P5 Glove (made by Essential Reality) which is a very cheap VR glove made for gaming. I made a VST plugin which can be controlled by the glove called Memory.
Interestingly, I've already known about GlovePIE for a while now. I first heard about it when I did a little work with the P5 Glove (made by Essential Reality) which is a very cheap VR glove made for gaming. I made a VST plugin which can be controlled by the glove called Memory.
