You might go with just straight Processing (not necessarily processing.js) - the reason why is mainly because it will allow you to do what you want, but also because the Arduino kinda grew out of the Processing mold.
Originally (still is?), Processing was a combination of the software (that you coded), and a piece of hardware that you hooked up to your computer that the software could easily control, to allow you to interface in an easy manner hardware with your computer. These boards connected to the PC via a serial cable, and used a microcontroller (some other AVR variant) which had software on it to interpret instructions from the PC (Processing) and update/set the pins (digital/analog I/O) and return data back to the PC read from the pins.
The founders of the Arduino system saw this, saw how powerful it was and how people loved it and learned quickly with it, and packaged it into what we know as the Arduino - basically a much cheaper and easier to use form of the system (the Processing boards weren't inexpensive, though they were certainly cheaper than some similar options back then).
In fact, the Arduino IDE comes from the Processing IDE - it's a shared lineage; I do know that somewhere out there is a sketch you can load on your Arduino that essentially turns it into a "slave" board for use by Processing. There are also other sketches that allow you to easily send commands and such via serial to do similar things (bitlash, for instance - http://playground.arduino.cc/Code/Bitlash
...or, you can come up with your own protocol, etc and put more intelligence on the Arduino side, and just communicate with Processing via serial as you would with any other language.
The advantage of using Processing is that it is real similar in syntax and such as what you are used to on the Arduino; it's meant to be an easy way to learn to control the outside world from a computer. Also, like the Arduino software, it is fairly cross-platform (if this means much to you). One downside would likely be that it probably isn't as efficient as a more "standalone" programming language would be (just as the C code for the Arduino isn't either), but that's the tradeoff for portability and ease of use (and really, unless your application is extremely demanding, with today's hardware on a PC, this isn't really something you should worry about, unless you have a very good reason to).