The Win32 API for threading have been designed for C, therefore they don't fit very well the use inside classes. In highest-level languages (such as Java), threading is implementable simply extending the Thread class and overriding the run() method. In C++, things are slighly more complex, expecially because it is impossible to reach classes methods from an isolated static function.

So, it is necessary... once again... pull up socks and use the _beginthreadex API.

Thursday, 14 September 2006

Once upon a time, there was the parallel port: an easy and powerful alternative to the serial port, useful for interfacing with external devices.

The arrival multiprogramming brought the abstraction of the port; after that, for some reason, in the Windows environment the access became a taboo.

What about free parallel programming in 2006? Introducing the inpout32.dll!

Developed by Logix4u.net, it's a free library for free kernel mode access to the parallel port in Windows 98/ME/NT/2000/XP. This library give access to two basic functions: Inp32 and Out32, to get and put bits onto the port.

You can find several example codes around the internet; the DLL is very efficent and can be imported with pratically every language known!

For anyone interested into Powerglove hacking, here follow the hardware modifications required.The idea is to modify the 7-poles connector of the glove to became a standard parallel interface. You can achieve this by soldering the wires as described in the scheme on the right. As you can see, the glove's circuitry requires an external +5V alimentation that is NOT provided by the parallel port.

You can obtain it from the PS2 keyboard connector, or from the floppy drive power chord. The glove I bought on eBay was previously modified for PC use, so I restored the connections. The original owner did the soldering directly on the board of the glove itself, using the parallel port cables to bring the +5V directly on the circuit. Check out the picture!

Tuesday, 12 September 2006

The Powerglove periodically squeezes out its datas. One way to keep the informations up-to-date is to delegate the readings of its status to a separate thread, which stores data in a circular buffer. This can be achieved with the multithreading tecnique: one process but more than one separate, and virtually parallel, thread of execution. It's gonna be my "producer".

The "consumer" will be the main procedure, which will obtain the deglitched coordinates with specifically concurrent methods. I'm wondering if a separate thread for the MIDI could be useful.

void launcher(){ // you can pass useful parameters to the thread using this variable long * param;

// the "threadID" variable will contain the reference of the created thread DWORD threadID;

// the NULL and the zeros are additional features of the syscall // check out references for further info // they're not needed for a simple thread creation HANDLE ret = CreateThread(NULL, 0, (LPTHREAD_START_ROUTINE) threadFunc, param, 0, &threadID);}

Tuesday, 5 September 2006

I modified a Powerglove to use it on PC via parallel port; using C++ I programmed it for translating the detected spatial coordinates into MIDI messages. Now I'm gonna optimize the software in order to play synth with my band Simmetry.

As you can see from the footages, my software suffers latency. Maybe it's due to the low-level MIDI programming, instead using DirectX, and the error correction routines which waste several milliseconds.