If you're dependent on 3rd party C/C++ libraries for the signal processing, many schemes are pretty good for FFI, I've not used Clojure FFI or Common Lisp FFI so I can't comment much on them. Clojure seems like it would be as good or at least no worse than Java for interfacing with existing C/C++ libraries. Common Lisp FFI is going to be implementation dependent (like with scheme). I do know that Chicken Scheme's FFI is pretty easy. I made a wrapper for a subset of GLUT and OpenGL, and adding additional components as they became relevant to the project was straightforward.
Regarding performance, I won't comment on Common Lisp or Clojure, I never measured their performance for numeric tasks. Scheme, however, with something like Chicken Scheme has good performance, and again FFI is straightforward so making a C module to do some heavy lifting is not unreasonable.
And having to bridge everything over FFI really isn't very practical for a UI of this complexity either for performance and code overhead reasons. Being able to access your internal data structures directly without jumping through FFI/translation hoops is a big win for both efficiency and code maintenance.
So Lisp zealots can ding my comment all they want but it doesn't change the fact that intelligent, informed programmers all over the world continue to reject Lisp for very practical reasons that the true believers of the Lisp community will never understand.