<div class="gmail_quote">On Fri, May 21, 2010 at 8:33 AM, torbenh <span dir="ltr"><<a href="mailto:torbenh@gmx.de">torbenh@gmx.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:<br>
> I agree with the Qt option, as it clearly produces some nice & performant<br>
> music applications. But you're still programming in C++ which is tedious<br>
> because of memory management; also "hard realtime" often precludes the use<br>
> of Garbage collectors. Of course Java has RT garbage collectors available:<br>
> <a href="http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/" target="_blank">http://java.sun.com/developer/technicalArticles/Programming/rt_pt2/</a> although<br>
<br>
</div>yeah...<br>
Java RTS has an innovative pricing model that starts at $6500 per<br>
socket/CPU for development or internal deployment.<br>
<br>
well... thanks :S</blockquote><div><br></div><div>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).</div>
<div><br></div><div>There's also gcj, and OpenJDK, with a relatively up-to-date JIT available and distributed with major distros like Fedora.</div><div><div>java-1.6.0-openjdk.x86_64 1:1.6.0.0-38.b18.fc12 @updates </div>
</div><div><div>gcc-java-4.4.2-7.fc12.x86_64 : Java support for GCC</div></div><div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
hmm... maybe this actually works.</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
still relies on some particular jvm.</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
effectivily throwing away the whole portability mumbojumbo.</blockquote><div><span class="Apple-style-span" style="font-family: arial, sans-serif; font-size: 13px; border-collapse: collapse; "><br></span></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">i dont understand... are you seriously arguing that dynamic languages<br>
are always better ?</blockquote><div><br></div><div>No! Did I actually say that, no.... </div><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
this certeinly isnt the case for number crunching.<br></blockquote><div><br></div><div>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</div>
<div>can make Lisp as fast as Fortran. Today: <a href="http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf">http://www.lrde.epita.fr/~didier/research/verna.06.imecs.pdf</a> "How to make Lisp go faster than C"</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
and i really find bigger programs pretty confusing in dynamic languages<br>
where variables arent annotated with types.<br></blockquote><div><br></div><div>That's just because the programmer wasn't fastidious enough in naming variables or structuring the program. You can program badly in any language.</div>
<div>Often dynamic language "programs" often started as a simple script that grew... Every program needs refactoring eventually.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">
</div>i think that code is pretty hard to read.<br>
and concision isnt always good.</blockquote><div><br></div><div>To each his own...</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
there is a reason why people call perl a "write-only" language.<br></blockquote><div><br></div><div>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.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">i really dont see any advantage over faust here.<br>
au contraire. a quick glance on the clojure stuff tell me that<br>
you still need to manage concurrency in some way.<br>
<br>
while faust is able to parallelize any valid faust code.<br></blockquote><div><br></div><div>Actually, my thoughts during the faust presentation @LAC2010 indicates we seem to inhabit different islands each with it's own cargo-cult...</div>
<div><br></div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
(07:59:14 AM) npm: Q: what's the difference or motivation for this Block diagram algebra and lambda calculus and y-combinators??</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
(07:59:58 AM) herman_mixer: Someone in the audience who can relay from IRC?</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
(08:01:38 AM) npm: well i guess that answers the q</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
(08:01:58 AM) npm: although i'd say 1950's not 1970's</blockquote><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
(08:03:40 AM) npm: <a href="http://en.wikipedia.org/wiki/Lambda_calculus">http://en.wikipedia.org/wiki/Lambda_calculus</a> --> <a href="http://en.wikipedia.org/wiki/Rewriting#The_Church-Rosser_property_and_confluence">http://en.wikipedia.org/wiki/Rewriting#The_Church-Rosser_property_and_confluence</a></blockquote>
<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">
(08:03:58 AM) npm: 1936</blockquote><div><br></div><div>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: <a href="http://en.wikipedia.org/wiki/Concurrent_computing">http://en.wikipedia.org/wiki/Concurrent_computing</a> (somebody should add Faust as it's not there, clojure and scala are, and are also much more widely known).</div>
<div><br></div><div>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:</div><div><a href="http://clojure.org/agents">http://clojure.org/agents</a></div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
overall when it comes to RT stuff.... either you use a language which<br>
gives you control over heap allocation. or the language must be<br>
specifically designed for RT operation.<br>
<br>
so we end up with c/c++ again.<br>
or faust.<br></blockquote><div><br></div><div>And for the things that people do in C or Faust, that's exactly what they should continue doing. </div><div><br></div><div>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:</div>
<div><a href="http://dssi.sourceforge.net/why-use.html">http://dssi.sourceforge.net/why-use.html</a> "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."</div>
<div><br></div><div>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.</div>
<div><br></div><div>Why muddle-up perfectly good realtime code w/ a bunch of GUI?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">and angelscript would be a valid interpreted language. because it gives the hosting app complete control over all allocations<br>
going on.<br></blockquote><div><br></div><div>Interesting. </div><div><br></div><div>I was thinking, initially, more of a language to do what Cakewalk did with "CAL" <a href="http://www.bikexprt.com/calfiles/index.htm">http://www.bikexprt.com/calfiles/index.htm</a></div>
<div>except you'd use modern implementation of their primitive lisp for MIDI event processing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
all this stuff you posted is nice... but i dont really have any hopes,<br>
that this stuff would become useable in the next 2 years.<br></blockquote><div><br></div><div>2 years is like 10 in internet time.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
stop dreaming :)</blockquote><div><br></div><div>But that's what I do! </div><div><br></div><div>Looks like I won't have to dream long:</div><div><a href="http://github.com/rosejn/midi-clj">http://github.com/rosejn/midi-clj</a></div>
<div><a href="http://github.com/rosejn/osc-clj">http://github.com/rosejn/osc-clj</a></div><div><a href="http://bitbucket.org/amb/clojure-snippets/src/tip/audio.clj">http://bitbucket.org/amb/clojure-snippets/src/tip/audio.clj</a></div>
<div><a href="http://github.com/amb/rezo">http://github.com/amb/rezo</a></div><div><a href="http://osdir.com/ml/clojure/2010-01/msg00900.html">http://osdir.com/ml/clojure/2010-01/msg00900.html</a></div><div><br></div><div>
<div>(defn osc-recv</div><div> "Receive a single message on an osc path (node) with an optional</div><div>timeout."</div><div> [peer path & [timeout]]</div><div> (let [p (promise)]</div><div> (osc-handle peer path (fn [msg]</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> (deliver p msg)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> (osc-remove-handler)))</div><div> (let [res (try</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> (if timeout</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> (.get (future @p) timeout TimeUnit/MILLISECONDS)</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> @p)</div>
<div><span class="Apple-tab-span" style="white-space:pre"> </span> (catch TimeoutException t</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> nil))]</div><div><span class="Apple-tab-span" style="white-space:pre"> </span> res)))</div>
</div><div><br></div><div>I bet the above would combine quite nicely with a <a href="http://qtjambi.sourceforge.net/">http://qtjambi.sourceforge.net/</a> GUI via Clojure....</div><div><font class="Apple-style-span" face="Verdana, Georgia, serif" size="4"><span class="Apple-style-span" style="font-size: 14px; "><br>
</span></font></div><div>-- Niels</div><div><a href="http://nielsmayer.com">http://nielsmayer.com</a> </div></div>