I am looking for an experienced programmer to help me improve upon an open source project for my own personal use, however, many others could find this useful in the future. The project can be found here...

http://projectgus.github.io/hairless-midiserial/

You can also find the source code at the above link. Here is some more info regarding the build:

Hairless Midiserial Bridge release 0.4 was built with Qt 4.7.3. It's also been built and run under Qt 4.7.4. Newer Qt versions 4.8 or 5.0 will probably require code changes in order to compile and/or run.

The Qt package should contain all dependencies, the graphical IDE "Qt Creator" or the program "qmake" can be used to compile the project hairless-midiserial.pro.

The libraries (RtMidi & qextserialport) used by Hairless Bridge are included directly in this source tree to be compiled in.

On Windows I recommend building with theMingGW compiler, Visual Studio has not been tested. Neither the MinGW site nor Qt's new owners Digia still distribute older MinGW builds, and MinGW 4.7 is too new for precompiled Qt 4.7.x, so it can be a bit hard to find a prebuilt combination that work. Recently I downloaded mingw-static-4.4.5-all.7z from this (https://code.google.com/p/qp-gcc/downloads/list) Google Code project, and can confirm that works.

Basically what I would like to do is simply add 3 more serial connection menus in one instance. Right now, as you can see on the site, is the ability to select One serial connection to MIDI In & Midi Out.
I would like to have 4 serial connection drop down menus with each its own Midi In and Out.

Thanks in advance. Please email scottykoopmann@gmail.com if you can help!!

Pay for this project will be negotiated.

Hello. I've taken a short review of your project. And I wonder what problems with FTDI latency does Arduino have? I've had a lot of experience with FTDI chips and we got built really high speed control system based on FTDI USB devices. There were realtime machinery working on FTDI connections. Delays were like 1ms (it was critical). At the same time. FTDI have two ways of usage - via VCP (emulation of COM port) which is slower by it's nature and direct interface d2xx, that's faster. I figure, using d2xx would be far better.

Then, Qt has its own latencies that may have impact. It's huge and quite monstrous library that is not designed for realtime, for sure. It may be useful for UI part, but barely for real-time communications.
As far as I know qtextserialport has some problems like sometimes losing bytes, lack of normal acynchronous interface. Here https://gitorious.org/qserialdevice guys develop the improved library like this, it implements normal async transfer and some more features. Maybe it would be interesting to you.

I've got a gross experience in cross-platform development. I might look at the code, but first I want to clearly understand the goals and architecture decisions.

Thanks Iron Bug for having a look at this project. I personally have no idea about a lot of the topics you have mentioned, which is why I am reaching out for some more knowledgeable people who have the skills to possibly assemble this type of program I am looking for. In my initial post I simply quoted what the original designer had to say regarding his Hairless<>Midi/Serial program.

I assume this program was intended for other purposes (Arduino) than my own, as I feel I am using it for a unique situation. Please let me go into detail about what my project requires exactly, and then maybe it will make sense why I'm interested in this program and giving it an upgrade/redesign.

I have 4 control surfaces (JL Cooper ES-8/100) that terminate to RS-232. Each of these are the same design. These surfaces are connected to the StarTech PEX8S592 PCI card, allowing for the controllers data to connect to my computer. I am using the Hairless Midi<>Serial program to convert the incoming serial data from my controllers to MIDI data that is being sent and used in an audio recording program, then sent back via Midi to the controller. 'Hairless', when opened allows for only one Serial (COM) port to be selected, and one Midi 'IN' and one Midi 'OUT' to be selected. Since I am using 4 separate control surfaces, I need to open 4 instances of the Hairless Midi<>Serial program. It works fine most of the time, but other times, one or more of the instances will crash. What I would like to do here is have a similar or identically functional program that will allow me to convert all 4 of my control surfaces in one program, 4 COM port drop down menus, and the accompanying MIDI I/O for each COM port selected.

Hairless Midi<>Serial is the only program I have found to work without much hassle, but I was hoping to consolidate it with my particular circumstances. I hope you would be willing to help. Thanks!

Ok, now I see what's your reason for using the software. It's really far from what it was designed for :)
Actually, the 'hairelessness' of the program is only useful for FTDI controller interfaces, where it sets the timeout to 1ms via controlling the chip, as I take it. And in your case all you need is just generic RS232<->MIDI translator, without any specific FTDI support. I believe there should be simplier solutions for such tasks.
Do you actually need it being cross-platform? The Hairless is. What operation system(s) do you use?

Yes, I figured it was a unique use of the software. When I select a COM port, it does say "no FTDI driver found", but still sends and receives data as it should. There is still very little to no latency, and I would guess a simple Serial<>midi translation would be sufficient. I am only needing this for Windows 7 64 bit. That is the OS I am using for this.

I will see if I can do anything about it. It does not seem a complicated software. It's very little and the code is neat.
The problem is that I don't have any Windows at home (except those looking out to the street, hehe). Ok, I think I will find some machine for testing, anyway. I developed cross-platform software for a long time, I don't think there could be a problem. I could try to cross-compile it, but cross-compiling Qt is quite big task, so it's easier to build it on native Windows system.

Thank you so much for helping. Please contact me at scottykoopmann@gmail.com with any other questions as to keep the details off of the forum! I am excited and looking forward to what you can offer!