How to talk to all that

Basically, you dont need any special driver in that sense. As the unit behaes as a hid (human interface device), any modern os already has a core driver to talk to the box.
Anyway, just making the system talk to the box isnt enough to really use it. What is needed now are user-space object/programs that talk to the hid driver on one side, and to the application on the other side. Since i only use linux for development (my windows is just and only to work on pic micros), others have to jump in here and provide that stuff. And even on linux it would be cool if some people make such "drivers" that go beyond what i can offer currently, and that is to use the already supplied event-device system of linux. For example, some deamon would be cool that dispatches the iobox's data into, lets say, the alsa midi driver. Same for mac-os and windows, of course. That way a great deal of applications can use the unit "out-of-the-box", so to say ....

But hold on ;-) if you just plug the box into your linux driven computer, and use the supplied event-device system to talk to it, you only get the box to function partially. You need to tweak the sources of the involved kernel modules to make it fully working. Furthermore, you need a fairly recent kernel, 2.6.2 for example works fine, 2.4.18 (which i had before) does not.
Here is a short how-to tweak the drivers, and i also explain why. You will find the already modified files in ther archive below, these are for the 2.6.2 kernel. But they should show what to change and how, so you should be able to apply that to other actual kernel sources as well. Its not that much of change anyway .....

Lets go:
Absolute prerequisite is to get a actual linux kernel. In 2.4.18 for example the hid driver does not include the one-byte report-id in the data packet that is sent to the unit. but that is needed, or the box could not tell what the data means. Recent kernels dont suffer from this bugs, only the limitations that we go to fix below. Maybe that bugfix is also backported to older kernels, so it may be enough to just get the actual archive of the kernel you are using. But i can not guarantee for that, of course.

First, you need to tweak input.h so that the driver (and applications using it) can handle that much i/o. The values for REL_MAX, ABS_MAX and LED_MAX should be set to 0xFF (we have plenty of them, remember ?). Near the end of the file duplicate the definition for the function "input_event(...)" and name it "output_event(...)" with just the same parameters.

Second, we need to add that output_event(...) to the file input.c. Look at the file in the archive, basically its a modified copy of input_event. this is done because originally it doesnt send absolute events to a device, it just receives them. Since i think its ugly to put stuff that output's data into a function called input_... (as it is done with some events originally), i just made a function called output_.... maybe if some of the people involved in the linux usb driver development will read that, and it will make its way into linux by default. who knows ....

Finally the file evdev.c must be modified to actually use output_event on a evdev_write(...) call. Go to that function and replace the call to input_event with one to output_event, and thats it.

Now recompile the modules (or the kernels, if you didnt made them modules), reload them (or reboot) and plug in the box. it should come up in you syslog that a new multi axis controller is connected to the bus. Now you are ready to use it with a event-device handling object/software like [linuxevent] for pd (made by H.C. Steiner) or [ev_dev] for older jmax versions (made by myself).

!!! ATTENTION !!!
You should be experienced in electronics if you whish to build this circuit !!
If you are not able to make your own pcb's and soldering them, ask a friend who knows how to do !