On Fri, May 21, 2010 at 8:33 AM, torbenh <torbenh@email-addr-hidden> 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?
and angelscript would be a valid interpreted language. because it gives the
> hosting app complete control over all allocations
> going on.
>
Interesting.
I was thinking, initially, more of a language to do what Cakewalk did with
"CAL" http://www.bikexprt.com/calfiles/index.htm
except you'd use modern implementation of their primitive lisp for MIDI
event processing.
> all this stuff you posted is nice... but i dont really have any hopes,
> that this stuff would become useable in the next 2 years.
>
2 years is like 10 in internet time.
> stop dreaming :)
But that's what I do!
Looks like I won't have to dream long:
http://github.com/rosejn/midi-clj
http://github.com/rosejn/osc-clj
http://bitbucket.org/amb/clojure-snippets/src/tip/audio.clj
http://github.com/amb/rezo
http://osdir.com/ml/clojure/2010-01/msg00900.html
(defn osc-recv
"Receive a single message on an osc path (node) with an optional
timeout."
[peer path & [timeout]]
(let [p (promise)]
(osc-handle peer path (fn [msg]
(deliver p msg)
(osc-remove-handler)))
(let [res (try
(if timeout
(.get (future @p) timeout TimeUnit/MILLISECONDS)
@p)
(catch TimeoutException t
nil))]
res)))
I bet the above would combine quite nicely with a
http://qtjambi.sourceforge.net/ GUI via Clojure....
-- Niels
http://nielsmayer.com
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sat May 22 00:15:02 2010
This archive was generated by hypermail 2.1.8 : Sat May 22 2010 - 00:15:02 EEST