[LAD] Looking for an introduction to rt programming with a gui

torbenh torbenh at gmx.de
Fri May 21 15:33:32 UTC 2010


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


> some may find "soft realtime" garbage collection as provided by the new G1
> garbage collector sufficient:
> http://research.sun.com/jtech/pubs/04-g1-paper-ismm.pdf ... see also:
> http://blog.headius.com/2009/01/my-favorite-hotspot-jvm-flags.html

hmm... maybe this actually works.
still relies on some particular jvm.
effectivily throwing away the whole portability mumbojumbo.


> 
> Lots of interesting Java-based music apps exist, with GUIs:
> http://jmusic.ci.qut.edu.au/applications.html
> http://www.softsynth.com/links/java_music.html
> 
> GUI application programming might be a little more forgiving in Java,
> although Java is a pain-in-the ass language, where you spend more time
> building and understanding scaffolding than you actually do programming...
> part of the scaffolding are the "design patterns" needed to work-around
> fundamental issues with primitive strongly typed languages like Java and C++
> (
> http://www.tiagoluchini.eu/2007/07/28/strategy-pattern-comparing-java-x-lisp/
>  ).

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

this certeinly isnt the case for number crunching.
and i really find bigger programs pretty confusing in dynamic languages
where variables arent annotated with types.


> 
> The good thing is you don't need to use Java anymore, but can take advantage
> of its portability, security, advanced garbage-collection options,  and
> just-in-time compiler advances that may give it a performance advantage,
> these days.... But you don't have to program in Java, you write in
> http://groovy.codehaus.org/ or http://clojure.org which means you can do
> really high-level things with just a few lines of groovy code (
> http://lists.xwiki.org/pipermail/users/2009-August/016937.html ).
> Fortunately, several million unfortunate souls have slogged through all the
> hard work and made a huge library of functionality for people to use, much
> of it open source.
> 
> http://curious-attempt-bunny.blogspot.com/2009/01/simple-clojure-graphics-api.html
> is
> a good example of the concision made possible by clojure...

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

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

> 
> Clojure may be of particular interest in realtime
> multiprocessor/multithreaded apps because of its high level., language-level
> support for concurrency and multithreaded programming (
> http://clojure.org/concurrent_programming  ) as well as potential support
> for Software Transactional Memory, which is analogous to garbage colleciton
> for threads ( http://www.stanford.edu/class/cs242/readings/TMvsGC.pdf
> http://java.ociweb.com/mark/stm/article.html ).

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.

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 angelscript would be a valid interpreted language.
because it gives the hosting app complete control over all allocations
going on.

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.

stop dreaming :)

-- 
torben Hohn



More information about the Linux-audio-dev mailing list