On Fri, May 21, 2010 at 8:33 AM, torbenh <torbenh@gmx.de> wrote:

On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:
> I agree with the Qt option, as it clearly produces some nice & performant
> music applications. But you're still programming in C++ which is tedious
> because of memory management; also "hard realtime" often precludes the use
> of Garbage collectors. Of course Java has RT garbage collectors available:
> http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/ although

yeah...
Java RTS has an innovative pricing model that starts at $6500 per
socket/CPU for development or internal deployment.

well... thanks :S

Java is open source. There are people using embedded and sometimes RT java, to varying degrees of effectiveness, in all sorts of everyday devices, like your cable company-provided DVR and set top box (which I've worked on) and sometimes even your credit card verification devices (which i've also worked on).

There's also gcj, and OpenJDK, with a relatively up-to-date JIT available and distributed with major distros like Fedora.

java-1.6.0-openjdk.x86_64 1:1.6.0.0-38.b18.fc12 @updates

gcc-java-4.4.2-7.fc12.x86_64 : Java support for GCC

hmm... maybe this actually works.

still relies on some particular jvm.

effectivily throwing away the whole portability mumbojumbo.

No the JVM is open sourced, the language is a standard, there's a good chance someone has done it, either as product or open-source. Remember that embedded Java (sometimes realtime) and embedded Unix form the core of many handheld devices, set-top boxes and there's more of those than there are linux-using musicians and audio professionals.

i dont understand... are you seriously arguing that dynamic languages
are always better ?

No! Did I actually say that, no....

To elaborate: I'm glad all those libraries have strong-typed APIs, and that they were written with technology that'll self-check against major API mismatches, which is helpful to prevent unnoticed bit-rot in applications and their dependent libraries and APIs. However programming in those languages, prototyping UI's in those languages is really tedious. Changing and updating and adapting applications for new uses is very frustrating in those environments.

this certeinly isnt the case for number crunching.

Not true, hasn't been true for a long time -- some of the earliest common lisp compilation triumphs were showing that a few carefully declared typed variables

can make Lisp as fast as Fortran. Today: http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf "How to make Lisp go faster than C"

and i really find bigger programs pretty confusing in dynamic languages
where variables arent annotated with types.

That's just because the programmer wasn't fastidious enough in naming variables or structuring the program. You can program badly in any language.

Often dynamic language "programs" often started as a simple script that grew... Every program needs refactoring eventually.

i think that code is pretty hard to read.
and concision isnt always good.

To each his own...

there is a reason why people call perl a "write-only" language.

Did I even mention perl? Blech. I was suggesting Clojure and Groovy, for their readability/elegance/simplicity/ease-of-use and ability to reuse all of Java classes, JVM advances, portability, wide-adoption, security, etc.

i really dont see any advantage over faust here.
au contraire. a quick glance on the clojure stuff tell me that
you still need to manage concurrency in some way.

while faust is able to parallelize any valid faust code.

Actually, my thoughts during the faust presentation @LAC2010 indicates we seem to inhabit different islands each with it's own cargo-cult...

(07:59:14 AM) npm: Q: what's the difference or motivation for this Block diagram algebra and lambda calculus and y-combinators??

(07:59:58 AM) herman_mixer: Someone in the audience who can relay from IRC?

(08:01:38 AM) npm: well i guess that answers the q

(08:01:58 AM) npm: although i'd say 1950's not 1970's

(08:03:40 AM) npm: http://en.wikipedia.org/wiki/Lambda_calculus --> http://en.wikipedia.org/wiki/Rewriting#The_Church-Rosser_property_and_confluence

(08:03:58 AM) npm: 1936

Church's work was the inspiration for the development of Lisp as a language. The "able to parallelize any valid faust code" is a fundamental corollary to functional programming and forms the basis of numerous implementations: http://en.wikipedia.org/wiki/Concurrent_computing (somebody should add Faust as it's not there, clojure and scala are, and are also much more widely known).

Clojure, is the next step past that, as it directly integrates language structures enabling parallelism, along with the functional style needed to make it all work:

http://clojure.org/agents

overall when it comes to RT stuff.... either you use a language which
gives you control over heap allocation. or the language must be
specifically designed for RT operation.

so we end up with c/c++ again.
or faust.

And for the things that people do in C or Faust, that's exactly what they should continue doing.

However, it is simply bad architecture to muddle up RT code with arbitrary UI code. It's much better to setup a simple network protocol so that the RT code only need listen on a socket for any I/O related to changing it's state. Which sounds like exactly the path taken with OSC control of plugins, etc:

http://dssi.sourceforge.net/why-use.html "DSSI separates the plugin and user interface, using standard Open Sound Control (OSC) messages to communicate between them. This ensures that the plugin's controls are consistently externally available, provides a guarantee of automatability, and encourages clean plugin structure."

And then just write an external UI program that talks OSC and attempts to keep up as best possible with the realtime processing going on in a different process. Allowing that realtime process to determine scheduling and receipt of UI events.

Why muddle-up perfectly good realtime code w/ a bunch of GUI?