Image by kouellet of the libnifalcon project

I really like this image for some reason.

More information and a model will be available at the Falcon Simulation page of the libnifalcon Wiki

But first off, let's rewind to August of last year. Before Novint put out their own SDK, I was bound and determined to get my own out, just because it seemed like a fun challenge. I managed to document out the firmware download process, but not completely replicate it. My first program worked by starting up one of their test programs to load firmware, then using my own code after that to communicate with the falcon. The hack ended up being successful, if ridiculously unsafe to look at in a normal workplace. The video of the results are at http://www.youtube.com/watch?v=EfrMalBiXuY (NSFW), which is not autolinked because otherwise you'll click it at work, won't you? Yeah. Copy and paste.

Anyways, while doing this, I took some notes on the startup sequence for firmware loading. Here's a picture of those notes:

Now, fast forward back to last week. Time to make everything equally fast.

To start, how the falcon communicates. Using the test firmware that came with the disc in the falcon box (currently the only thing I have mapped, and I honestly don't even know if there's other firmware out there), it receives 16 bytes input, and upon receiving that, gives back 16 bytes as output (it's actually 18 bytes, due to ftdi modem status being tacked on the front, but those are negliable). That's it.

Let's look at the stats that test programs were putting out for each platform (thanks to people on the libnifalcon-devel list for helping out on this):

Linux:

Time between I/O Iterations: 0.015991s
Average Frequency: 62.534351 per second

Windows:

Time between I/O Iterations: 0.000942s
Average Frequency: 980.382853 per second

Yeah. Bit of a difference, eh? So something was causing I/O iterations on linux to take around 16ms each, while on windows, we were getting 1 iteration per millisecond, and achieving near the 1khz that's mentioned by Novint all the time. This is running on the EXACT same code, up to the point of the FTDI library being used. The Windows version was using the ftd2xx drivers, while linux was using libftdi. ftd2xx on linux seemed to run decently fast, though I don't have the number handy at the moment.

Now, I'd read a few things around the net about libftdi being ridiculously slow, mostly in terms of bitbanging though. Either way, I figured it was something in either libftdi or libusb that was causing the slowdown. Rebuilt everything with -gp and let gprof at it for a while, just to see that, nope, it was just sitting there waiting during the I/O loop, for 16ms at a time.

At this point, I start wondering if it's not the synchronousity of libusb-0.1 that's slowing me down. Luckily, libusb-1.0 is in development right now, which enable asynchronous transfers for usb. Pulled the dev branch of that, tried it out. Asynchronous sends, writes are superfast, reads... 16ms.

Damnit.

So, something in the read is taking 16ms. It's time to start playing with our read transfer and see what else we can change. First off, changing the read request size to 64 bytes, the maximum packet size for the endpoint.

Time between I/O Iterations: 0.000919s

Well, that made something happy. The problem there is, we're now sending 1000 input packets, and only getting back ~250 output packets. This means that there was something I was missing about sub-maximal packet sizes.

Much googling insues. No information found. Finally out of frustration, I just google "ftdi 64 bytes".

And I find the FTDI Addendum on Data Throughput, Latency, and Handshaking for the FT232 Series Chips (PDF)

There it is, clear as day. There's a latency timer on the chip that will send bytes to the host assuming one of three conditions:

• A serial status line (DTR, RTS, etc...) is flipped
• The buffer reaches maximum capacity (Thus our results with the 64 bytes
• The latency timer overflows

We're obviously not playing with the first one. The second one we've seen the effects of, but we don't want to have to wait for 62 user bytes at a time.

What's the default starting value of the latency timer?

16ms.

If you scroll back up and look at my notes again, you'll see there's a line there that says "0x9 (latency timer?) 0x1". This was a control message sent over by the Falcon test program. 0x9 is the control message index, and 0x1 is the value. They set the latency timer to 1ms during the initialization stage. I totally skipped over that when transcribing the code for the initialization sequence, and it meant I was sitting on slow code for many, many months.

I added that single line of code to the libusb-0.1.12/libftdi based libnifalcon libraries.

Time between I/O Iterations: 0.002019s

Yyyaaaaaayyyyyyyy!!waitaminute. 2 ms?

And thus, the synchronous call issue comes back to bite me in the ass, except this time, it's actually a correct diagnosis.

You see, when you send a USB message, it's packed into a USB frame. Each USB frame can carry multiple messages, but at a rate of 1 frame per millisecond (we're at USB 2.0 fullspeed here). libusb-0.1.12 only packs one request per frame, so we have 1ms input, 1ms output. 2ms overall, locking our I/O loop to 500hz. DAMNIT.

So, the solution to this is to either figure out a way to get both input and output in the same frame, which may be possible with libusb-1.0. That remains to be seen, and that code is still very, very alpha. I'll keep working with it, though.

Anyways, this still leaves a couple of questions. First off, when I was checking the ftd2xx drivers for linux, I decided to check their symbol table for the dynamic library...

...

         U time

         U tolower

         U toupper

00013673 T usb_bulk_read

0001357d T usb_bulk_write

00017d30 B usb_busses

000132ff T usb_claim_interface

00014309 T usb_clear_halt

000120e6 T usb_close

HEY! Those are libusb calls! So ftd2xx is at least partially based on libusb. How they're managing the superfast I/O, I'm not sure. Could be threading, could be they've got their own asynch thing going on.

Secondly, I obviously didn't have the latency timer set on the ftd2xx version of the drivers, either. Why did my drivers run so fast on windows without that? I'm guessing there could be a config file I was missing somewhere, or maybe their drivers just do it themselves on connection or something.

Anyways, the moral of the story: Read the god damn spec sheet. And all the addendums. And pay attention to your own notes.

I swear this makes more sense if you actually see it moving, but nonetheless, I now have a neat little DK simulator for the Novint Falcon, actually controlled by the Falcon itself. The buttons on the falcon can rotate/zoom the camera on the model. The triangle in back in the fixed frame (which I have NO idea on the size on, since the falcon is weirdly setup. That's partially why I created this simulation, so I could just change numbers until things seem right.), the three big white spheres are the knee positions, and the one out in front is the end effector origin.

Outside of the fact that the simulator can't reliably pick which solution it wants to use (meaning sometimes it thinks the end effector ends up behind the fixed frame, oops), and that it's not mirroring the exact wonky angles the Falcon axes come out at, it works! And all in under a day's work. Not bad for being a little rusty on my OGL.

Descriptive Geometric Kinematic Analysis of Clavel's Delta Robot, P.J. Zsombor-Murray, McGill University

I'll be doing a "unwind the retroencabulatoresque wording" post later, but for those of you used to reading engineering/math papers, check out the "Rationale" section. It contains a really awesome abstract algebraic version of "go fuck yourself".

Anyways, this paper has one problem. The pictures at the end are... engineery. Very, very engineery. Unreadably so. So, I decided to spend a little time working in that whole Second Life thing that I spend all of my day job time on, except actually doing something creative in it.

And thus, my reworking of the IK/DK derivation, which is a hell of a lot easier to understand visually (basically: Expand everything out to constraint spheres, find the meeting points of 2 of those spheres, logic out which is the correct point of the meeting of the 3 to save yourself the unnecessary processing). This can be seen at http://slurl.com/secondlife/Hyperborea/160/45/23/

Oh yeah. And actually, two problems with the paper, now that I think about it. Bricks of BASIC are not helpful as code. Ever. And this is literal brick, too. Whitespace is for bitches.

For anyone else wondering about the Falcon; the paper above expresses the direct kinematics in terms of hip angles. However, the falcon's a little different. It gives you back encoder values from the motors, so you're stuck with a single integer value that relates to the extension distance of the thigh. This is due to one of the nice features of the Falcon, though. The bent extension thigh (versus usual static rotation-only bar thingy, or at least, that's my made up mechanical engineering term for it) gives you a smaller footprint for the workspace than usual haptics deltas would give you, which is important since this was made to go on a gamer's desk. It's probably a bit more rugged too, since those nice rotational sensors in $30,000 equipment probably weren't made to take cheeto dust either. So, good for you on that one, Novint.

Anyways, what that means is the encoder values refer to some point on a 4" arc that the knee traces on the hip constraint sphere, instead of an angle. You can either translate between those to get your angle back and plug into his code, or wait for me to just post my finished code here. The encoder value is probably a faster way to do this, too, since I'm betting you can avoid floating point math at some point with it.

This, of course, will all happen as soon as I decide to stop spending time making pretty pictures and posting about how proud I am of said pretty pictures.

Yup, it took all of a month for my "no new speaking until I have something new to say" thing to fall apart. But, well, this is different! Really! Somehow. :)

So yeah, I'm now part of the BDSM and Web 2.0 panel at the 12th Annual Leather Leadership Conference. The panel takes place Sunday, April 13th, at 10:30am. The panel will include Thomas Roche (who I was also on a panel with at Arse Elektronika, now of kink.com), Richard Hunter (of Mr. S Leather), Steve Bower (Webmaster for the Society of Janus), and others. Should be fun!

Of course, I've also now run into the nasty fact that libftdi is around 4x slower than ftd2xx, meaning that what's a 1000hz update rate on windows ends up being 300hz max on Linux and OS X. Not happy about this at /all/, but there's really not much I can do outside of porting to a kernel driver probably. Which, yeah, I've thought about doing, because I hate myself.

Anyways, I've also finished Max and Pd patches for the falcon for all platforms, thus my first real released "application" for this. Only took me 9 months. Go me.

Now then, see if you can figure out which program is the free one, and which one is the expensive one:

Max/MSP:

PureData:

Is there such a thing as a pretty PD patch? I have yet to see one.

If you didn't understand my box article, read on anyways. I'm gonna try to make this as understandable to everyone as possible, so you'll all learn C and inverse kinematics and algebraic geometry and come romp with me down the happy streets of writing a driver for a badly marketed piece of hardware no one is buying.

Come on, what other relaxing hobbies do you have that involve Jacobian Matrices, hmmmmm?

Please note: I have not used Novint's SDK. I do not plan on using Novint's SDK (That would be cheating). I don't know what their developer support is like (though Tom seems nice enough on the forums. Hi Tom!). What you see here is what I've gained from lots of web searching, talking to people that know what they're doing (I'm not a haptics engineer, in fact, this is my project to learn haptics engineering and programming), and randomly trying things while hoping I don't break the falcon. I'll wikify all of this information in time, but it's honestly much faster for me to brain dump in conversational blog mode than it is into a wiki.

So what the God Damn Hell is the Falcon anyways?!?!

It's everyone's favorite time of class, video time! *wheels in the TV with bad color and hissing, blinking 12:00 VCR*

Seriously. I can't figure out how to explain it. Novint can't figure out how to explain it. So, watch this video, which tries to explain it.

If you don't understand what it is yet, well, I can't help you anymore. But enjoy this randomly technical description that follows anyways. I worked hard on it, and I did it JUST FOR YOU. Yes, you.

A Little Background on Parallel Robots and Haptic Controllers

Before we dig into the guts, let's start with what you can find out before you take the case off the thing. For reference, here's a picture of the Falcon:

A bit of background (this will contain much glossing as I'd like to focus on the falcon, but it's good to have a knowledge of what's out there otherwise). In the world of haptics, there are two major types of controllers. Serial (pen type controllers), and parallel. An overview of a bunch of the different hardware types is available in an article on bracina.com.

The NovInt Falcon is a parallel robot. Parallel robots are called such because they have multiple chains of joints working together to create the final position of the controller (or end effector, if you want to be technical about it). Not to mention, the math uses parallelograms to line up the positions.

If you watch a lot of How It Works (which, if you have cable with the Discovery Channel, you invariably end up doing no matter what. That show is video heroin.), you've seen these before.

They're real popular in pick and place operations. That's exactly what it sounds like. Pick something up, put it somewhere else. Repeat ad inifinitum. Puttin' things in or on other things. They're good at that.

Here's one in action.

So, you're probably like "But it's all pointing down"

Ok, look more familiar now? The NovInt Falcon is a parallel robot turned on its side. It's actually a Delta variant of the parallel manipulator (Here's a nice overview of the Delta Haptic Device, which is quite similar to the Falcon/Omega setup). If you want all sorts of interesting history about where it came from, check out this article on parallemics.org. But for now, we'll just say: France. It came from France.

There's lots of reasons why using parallel robots in haptics is important. However, I don't quite understand the math behind it all yet, so I'll just repeat what all the webpages say. "Good stiffness and accuracy in a small workspace". Having used some serial controllers before, I can see what they mean. Hard definitely feels... hard. I'm sure I'll be talking more about this in later articles on the development of libnifalcon.

To show a bit of what else is out there, here's the ForceDimension and their Omega series of controllers.

Once again, looks familiar, no?

Well, one major difference.

The Falcon is $249US.

The Omega starts at around $20,000US (the more degrees of freedom, the more expensive. The Omega 7 is around $50k.)

Ok, and the Omega comes with a PCI interface and all sorts of APIs and what not and FD is actually an offshoot of the subset of France that we mentioned above that created this whole thing in the first place, but still. That's some significant 0's worth of difference there.

There's rumors that ForceDimension helped out on the Falcon design. There's also rumors that it came from Sandia with Tom. Only Art Bell truly knows.

So why all this about parallel robots? Well, many future posts will be talking about research in this field, so I figured I'd at least introduce the term. There's also lots of reference and searchable material in here if you're interested in going your own direction with this information. Anyways, back to hackyness.

Internal Circuitry

Now that we've got that out of the way, what's inside it?

Click the image below to go to an annotated flickr picture of the insides.

Connectors:

• USB B Connector
• Power Connector - goes to 30V 1A wall wart of DOOM

Yes, the falcon is quite possibly cranking 30W through the motors when you max the torque on all the axes.

Chips (Links to Datasheets or Product Websites):

• FTDI FT232R USB to Serial Chip
• PIC 16F688 Microcontroller
• TI TMS320 R2811 DSP Processor

I don't have specific parts on the 3 motor blocks in the circuit (they're all exactly the same), but what you've basically got going on there is three really large old style mouse encoders. Each of the 3 large wheels attached to the motors have a disc attached to them, alternating little clear slots with opaque slots. There's a photoresistor that shines light through those slots. Whenever the light goes through (clear), you get a 1. Whenever the light is blocked (opaque), you get a zero. And that's how we know how far the motor has gone.

Whether direction is measured using some sort of quadrature encoding or Back-EMF polarity is something I forgot to check (but will do so at the point where I can figure out how to write my own firmware for this thing).

Communications and Initialization/Bootloading Sequence

Now, for the part I kinda sorta know more about than the other parts.

The Falcon uses the FTDI chip as it's main communications link to the computer. Everything is filtered back and forth through the FTDI chip, converting from USB on the computer side to RS232 on the circuit side. This is because it's orders of magnitude easier to program your microcontrollers to talk RS232 than it is to talk USB.

Novint distributes and uses the stock FTDI driver with their software. The only change they've made is to the VID and PID. They've chosen to use FTDI's free "have a PID" program, which has them listed under FTDI (0x0403) as a vendor, but with their own special product ID (0xcb48, as opposed to the default PID for FTDI chips, 0x6001).

NOTE: I have not actually proven this next paragraph, it's more what I think is going on than anything. You might've noticed in the Internal Circuitry section that there are two microcontrollers on the board: the PIC and the TI. This is where the bootloader sequence comes in. The TI DSP uC is actually reconfigurable on connection to a PC. The PIC acts as a bootloader, maintaining the logic needed to run the FTDI communications to pick up firmware and program the TI with it. This allows a developer (currently just Novint, since I've had no luck analyzing the pins. Stupid tiny LQFP pins and my shaky hand.) to possibly speed up the control loop on the internal processor depending on application specific needs. Damn fine idea, even if it did crank the price of the hardware quite a bit, I'm sure.

When a program wants to connect to the falcon, the following sequence occurs (if you want to follow along, check out nifalcon_libftdi.c). Note that the bauds get funky, because baud rate actually turns into a clock subdivision on the board, so I just converted the rate to the lowest clock subdivision possible that would still make them work. See the How I Mapped The Test Firmware Protocol section for more info.

• Open connection to FTDI chip
• The "Are we at least connected" Step:
• Set to 9600 8N1, No Flow Control, DTR High
• Write a 3 byte check message, {0x0a, 0x43, 0x0d}
• Read, expect 5 bytes back
• The "Send the firmware over" Step:
• Set 140000 baud, DTR Low
• Write a single byte (Usually 0x41 "A")
• Read, expect same byte back
• Send firmware file in 128 byte chunks
• Read, expect exact chunk we sent back from the falcon as error check
• The "Ready To Go" Step:
• Set baud to 1456213 (Maximum for the chip?)

After we've gotten this far, we're ready to run an I/O loop to the falcon.

The Test Firmware

So far, the only firmware that's usable with code I've written is what I call the "test" firmware. This is the NOVINT.BIN file included with the drivers, that the utilities in "c:\Program Files\Novint\Falcon\TestUtilities\" in a normal windows nVent (I HATE NVENT but that's an article for another day) install will use.

Rather than repeat the info here, if you're interested in the packet layout of the test firmware, check out my wiki page on it.

Note, however, that there are a few things you might not be aware of. First off, when you set a motor torque, it's only for a very short period of time (Haven't scoped out the exact value). Basically, you're expected to be polling the falcon constantly and setting the torques as needed. The controlling program is closing the control loop to the falcon, as just keeping torques on until next update can cause lots of badness (motor wear, crunched fingers, etc...)

Goals of the libnifalcon Project

So, that's pretty much all I know about this thing right now. I'm working on learning the math behind the haptics and placement algorithms, and while I learn, you'll get to learn along with me, in the form of reading my ridiculously long blog posts!

All of this is going into code form in the libnifalcon project on Sourceforge. As of this writing, v0.2 is sitting in the repository waiting for me to finish a few cleanup things.

Here's a few applications I have planned for libnifalcon:

• Max/MSP and PureData Patch (already done, just needs to be cleaned, threaded, and released. It's in the repository if you absolutely can't wait)
• Mouse movement/simulation
• Basic open source haptics library integration
• Mapping the TMS320 pins and possibly starting on my own firmware

As you can see, right now I'm more interested in getting a code platform built and teaching myself haptics programming from the ground up than I am in implementing any specific application. However, I do spend a lot of time in Pd playing with the falcon at the moment, and will most likely be posting interesting projects out of that in between code geekouts.

Aside 1: How I Mapped the Test Firmware Protocol

Mapping the test firmware protocol was fairly easy. I used SniffUSB to record the packets going to/from the Falcon in the test programs, then compared the data in those with the protocol mapping for the FTDI available in the libftdi source code. The bootloader code is basically a handwritten replay of this sequence, except translated back into FTDI driver calls instead of pure USB comms, hence some of the weirdness in the explanation (the "send 3 get back 5" seqeuence, the odd baud rates, etc...).

This was, quite literally, all it took. No amazingness or code breaking or whatever. Figuring out the packet setup was just a matter of mapping the numbers from the test GUI to the changing bytes of the packets.

Aside 2: FTD2XX versus libftdi, Operating Systems, and You

libnifalcon comes in two flavors right now.

• FTD2XX
• This is the driver that FTDI distributes, and the one that the default Windows Falcon drivers use. It seems fine on windows, outside of the fact that I personally have issues connecting the Falcon through a hub. This may or may not be due to my machine. However, this drivers seem wildly unstable on Mac and Linux. Also, they have no versions available for 64-bit Linux
• libftdi
• This is the free, reverse engineered version of FTDI's drivers, that use libusb. They seem to be stable across all platforms, though I only recommend using them for anything non-windows (or non-publically distributed on windows. Don't make people switch drivers if you don't have to.). It's GPL'd, too, so if you want to use libnifalcon under libftdi, you're stuck with the GPL too. Meh.

I also decided to post some observations I had about their packaging. Reposting here to get people's opinions, since I know more than a few designers (both game and print/web) read this blog:

First off, the packaging in question:

So I was picking up some Falcons at a local CompUSA closing sale ($49!), and while giggling to myself that I was getting falcons for cheap (now I have 3!), a random person asked me what these large boxes I was carrying across the store awkwardly were.

It's then that I realized: there were 5 falcons left at the store. This was the last day it was going to be open. They were $49. Not even the people picking stuff up cheap the rehawk in downtown were getting them. Not good.

After setting the boxes down and trying to explain why 3 DOF haptics is important for immersion (which boiled down to "stuff like, feels, and stuff"), I realized there's nothing on the boxes to explain to anyone without some training in haptics hardware (i.e. anyone without medical or industrial robotics experience) what a falcon /is/.

I realize this is a really, really hard problem. Everyone I know that's excited about the falcon falls into two groups:

(1) They have an advanced degree and knows how much this hardware costs when packaged as a research tool or
(2) They've actually used one.

The problem here is, neither of the groups can use word of mouth to convey the experience. It usually ends up in overly technical talk ("~1/800th inch encoder tick resolution per axis!"), or wild gesticulation and adjectives that don't quite fit the experience. Good for the user, bad for the uneducated customer. The choir can hardly preach to itself.

Not that I have any insight on this, but the box seems to be taken up by lots of pictures of the controller itself, with no informational diagrams about how it's used. In situations where you can't have one out (which is often, since it's awful big), this might help a lot.

First off, it's year 3 of GDC for me. Not speaking during the conference, though you can at least catch me at Brenda Braithwaite's Sex in Games Roundtables on Wednesday and Thursday, plus the various parties (Here's crossing my fingers for another World of Darkness party like last year. More game conferences need dominatrixes).

Wednesday, March 5th, it's off to O'Reillys Emerging Technologies Conference, where I'm giving a talk on the usual (teledildonics and intimate interfaces). Due to the fact that I'm poor and SD is expensive, I'm only in for the day of my talk, so look for me on Wednesday if you're around.

And then... Nothing. Yes, I have absolutely no planned speaking engagements after that, and I plan on keeping it that way for a while.

For instance, a sleeper:

And a trapeze:

Next step is getting all of this out of Max/MSP and into either PD or OpenFrameworks, as my Max demo license ran out and I'm not throwin' down the cash until they finally announce their pricing scheme for Max 5.

So, this year, I:

- Lived outside of Oklahoma for a full year for the first time, ever.
- Open sourced a dance accidently.
- Perverted a web service and then turned it into furniture
- Slapped together generative art
- And then slapped together some more generative art
- And some hand followy lights
- And hooked a yoyo to a wiimote
- Helped build knob boobs
- Went to my first SIGGRAPH
- Helped organize a conference after I explicitly said I'd never do that again
- Started my first open source projects (versus just helping on them) (libnifalcon, libtrancevibe, liblightstone
- Learned two new languages (Python, Max)
- A bunch of other stuff I'm not documenting here, like awesome new people I met and all that.

Well. It was no 2005, but it'll do.

For those of you that haven't known me a while, you might not be aware that I used to yoyo quite a bit. I still play every so often, but not nearly as much as I used to. I ended up building up quite the collection, though. Something I always wanted to be able to do was yoyo tracking. I played a little bit with blob tracking and LEDs, but didn't have the hardware or experience back then (2000-2001ish) to really do what I wanted.

After seeing the head tracking and finger tracking videos, the first thing I thought of was trying the yoyo project again. Without taking the time to actually look at my collection, I decided to drill up an old freehand pog and electric tape it to my Pyro with a CR2032 pack attached to the back of the pog for power.

This ended up being such a colossally bad idea that I'm not gonna spend much time talking about it. The yoyo was unusably unbalanced. So, digging through my yoyo box somemore, I realized I still had some Torch LED pogs.

I removed the Red LED off of these and replaced it with an IR LED and a smaller resistor. Since I didn't really have any Spintastics yoyos I wanted to throw the pog in, I ended up dismantling my already sort of broken Night Moves 2 (the plastic on the axle end had cracked on it a while ago for some reason), and hot gluing the pog in to hold it. Sure enough, the yoyo was slightly unbalanced, but completely usable for most any trick. After ninja starring the pog due to not having hot glued it well enough the first time, I made sure to do a better job, and now I have an IR yoyo!

So, with yoyo+wiimote setup finished, I fired up Max/MSP and used the aka.objects wiiremote and appleremote externals along with the LCD object to make a little drawing program. The Apple Remote works as a pen start/stop and clearing device, so I can clear the screen and start/stop drawing while standing far back from the computer. The Wiimote external is wired to draw lines depending on the first IR readout from the camera.

The above picture is a drawing from that program, of an almost-but-not-really version of the "skin the gerbil" trick by Doctor Popular.

The picture also shows a couple of the current problems with the system. First off, I've completely trashed my office getting this done, so I can't back up very far and don't have a good idea of what the Wiimote is seeing. This could be fixed by calibration, which is something I plan on figuring out. Secondly, there's some sampling issue with large swings. Either my swings are causing tilt, the LED doesn't have a wide enough angle, or some combination of the two. I've ordered 5 more kinds of LEDs to test this.

Finally, I hooked up a little sample looper in Max/MSP to the setup so that it would spit out some noise, too.

So, that was my weekend. The project still has a long way to go. I've got 2 more Torch boards to mod once the LEDs come in, and it'll be interesting to see which LEDs work best. I should have those later this week. I also plan on modding a spintastics top I have that has a torch board in it, so I can do Augmented Reality Battle Tops.

Have any interesting ideas for this project? Please leave comments! Seems like there's a million places this could go.

GENTLEMEN, BEHOLD:

Twitter Breakcore

I created this back in September, when I was taking my Max/MSP classes at RobotSpeak. I decided to try layering twitter public timeline messages run through text-to-speech over fairly simple looped break samples, because noise + noise = noise.

Unfortunately, either Py/Ext or flite~ is causing Max/MSP to crash about 20-30 minutes in, regularly, so having a full time stream running is a bit of an issue right now. However, I made a small 2.5 minute track.

"actively gnawing on some guy's head" (MP3, 2:20)

Lyrics:
systems over single channel, IP
Have fun and be safe. Happy New Year to you too. xx
Bob Sinclar Ft Steve Edwards - World Hold On (David Guetta And Joachim Garraud Remix)
Night Night everyone!!! xoxoxoxoxoxoxo
comiendo pizza con cerveza de tercio..... perfect
, do you ever get to see the wildlife?
the internet by design is a communications platform. the goal is to put old communications systems over single channel, IP
Back from dinner. Answering a few emails then watching Helvetica.
Christmas Cheer? MST3k Santa #521 on Google Video
mmmmm..... Ribs :). Lol
Back in Columbus. Found 5 dead roaches in my apartment. Bleh.
no run. GB Hogg to SC Ganguly, no run, fuller and on the off, driven hard but straight to cover
no run. MG Johnson to SR Tendulkar, no run, full and outside the off, left alone, this one doesn't bounce too much and scoots along to t ...
posteando
Spacetime Continuum - Kairo (Carl Craig Mix)
Helpful Tip: Don't let your brother-in-law take you to "I Am Legend."
Rosie - Another Rosie Christmas
Baby break dancing!
when am i coming by for pie again?
contestando mails de laburo :(
I love spark people ! Haha. Going to sleep soon.
Went to Kohl's tonight... I don't even know why I bother with that place.
Borre bastantes twiteros ke no twiteaban como hace 1 o 2 meses!...
congratulations on your laptop!
is it just me or does firefox seem to get less and less stable with every patch?
In San Jose, Ca
queda una no tan larga noche por delante.
“Arguments with furniture are rarely productive.”
To be fair, it was actively gnawing on some guy's head when they shot it.
i'm in ur eharmonies, communicatin' wif ur matches.