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

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
To: torbenh <torbenh@...>
Cc: <linux-audio-dev@...>
Date: Friday, May 21, 2010 - 6:42 pm

--001636b2b641b6739504871f0c4c
Content-Type: text/plain; charset=UTF-8

On Fri, May 21, 2010 at 8:33 AM, torbenh wrote:

> On Thu, May 20, 2010 at 10:37:30AM -0700, Niels Mayer wrote:

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

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

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.

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.

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

(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 -->

(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

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

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,

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

--001636b2b641b6739504871f0c4c
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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 wro=
te:

formant
edious
cludes the use
ble:
/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 :SJava is open source. Ther=
e are people using embedded and sometimes RT java, to varying degrees of ef=
fectiveness, in all sorts of everyday devices, like your cable company-prov=
ided DVR and set top box (which I've worked on) and sometimes =C2=A0eve=
n 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 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A01:1.6.0.0-38.b18.fc12 =C2=A0 =C2=A0 =C2=A0 =C2=A0 @updates=
=C2=A0
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 embed=
ded Java (sometimes realtime) and embedded Unix form the core of many handh=
eld devices, set-top boxes and there's more of those than there are lin=
ux-using musicians and audio professionals.
=C2=A0i dont understand... are y=
ou seriously arguing that dynamic languages
are always better ?No! Did I actually say =
that, no....=C2=A0To elaborate: I'm glad all =
those libraries have strong-typed APIs, and that they were written with tec=
hnology that'll self-check against major API mismatches, which is helpf=
ul to prevent unnoticed bit-rot in applications and their dependent librari=
es and APIs. However programming in those languages, prototyping UI's i=
n those languages is really tedious.=C2=A0Changing and updating and adaptin=
g applications for new uses is very frustrating in those environments.
=C2=A0
this certeinly isnt the case for number crunching.Not true, hasn't been true for a long time -- some of the e=
arliest common lisp compilation triumphs were showing that a few carefully =
declared typed variables
can make Lisp as fast as Fortran. Today: =C2=A0http://www.lrde.epita.fr/=
~didier/research/verna.06.imecs.pdf
"How to make Lisp go faster th=
an 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.=
=C2=A0

i think that code is pretty hard to read.
and concision isnt always good.To each his=
own...=C2=A0
there is a reason why people call perl a "write-only" language.Did I even mention perl? Blech.=C2=A0I w=
as suggesting Clojure and Groovy, for their readability/elegance/simplicity=
/ease-of-use and ability to reuse all of Java classes, JVM advances, portab=
ility, wide-adoption, security, etc.
i really dont see any advant=
age 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 @LAC2=
010 indicates we seem to inhabit different islands each with it's own c=
argo-cult...

(07:59:14 AM) npm: Q: what's the difference or motivation for this Bloc=
k 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_co...
uence

(08:03:58 AM) npm: 1936Church's work w=
as the inspiration for the development of Lisp as a language. The "abl=
e to parallelize any valid faust code" is a fundamental corollary to f=
unctional programming and forms the basis of numerous implementations:=C2=
=A0http://en.=
wikipedia.org/wiki/Concurrent_computing
=C2=A0(somebody should add Faust=
as it's not there, clojure and scala are, and are also much more widel=
y known).
Clojure, is the next step past that, as it directly int=
egrates language structures enabling parallelism, along with the functional=
style needed to make it all work:http://clojure.org/agents
=C2=A0
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 peopl=
e do in C or Faust, that's exactly what they should continue doing.=C2=
=A0However, it is simply bad architecture to mudd=
le up RT code with arbitrary UI code. It's much better to setup a simpl=
e 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.sourc=
eforge.net/why-use.html
=C2=A0"DSSI separates the plugin and user i=
nterface, using standard Open Sound Control (OSC) messages to communicate b=
etween them. This ensures that the plugin's controls are consistently e=
xternally available, provides a guarantee of automatability, and encourages=
clean plugin structure."
And then just write an external UI program that talks O=
SC and attempts to keep up as best possible with the realtime processing go=
ing 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 o=
f GUI?and angelscript =
would be a valid interpreted language.=C2=A0because it gives the hosting ap=
p complete control over all allocations

going on.Interesting.=C2=A0=
I was thinking, initially, =C2=A0more of a language to do wh=
at Cakewalk did with "CAL"=C2=A0http://www.bikexprt.com/calfiles/index.htm
except you'd use modern implementation of their primitive lisp for=
MIDI event processing.=C2=A0
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.<=
div>2 years is like 10 in internet time.=C2=A0

stop dreaming :)But that's what I do!=
=C2=A0Looks like I won't have to dream long:<=
/div>http://github.com/r=
osejn/midi-clj

http://github.com/rosejn/=
osc-clj
http://bitbucket.org/amb/clojure-snippets/src/tip/audio.=
clj

http://github.com/amb/rezo<=
/div>htt=
p://osdir.com/ml/clojure/2010-01/msg00900.html

(defn osc-recv=C2=A0=C2=A0"Receive a single message on=
an osc path (node) with an optionaltimeout."=C2=
=A0=C2=A0[peer path & [timeout]]=C2=A0=C2=A0(let [p (promise=
)]=C2=A0=C2=A0 =C2=A0 =C2=A0 (osc-handle peer path (fn [msg]
(=
deliver p msg) (osc-remove-handler)))=C2=A0=C2=A0 =C2=A0 =C2=
=A0 (let [res (try
=C2=
=A0(if timeout =C2=A0 =C2=A0 =C2=A0(.get (future @p) timeout TimeUnit/MIL=
LISECONDS) =C2=A0 =C2=A0@p)
=C2=
=A0(catch TimeoutException t nil))] res)))
I bet the above would combine quite nicely with a=
=C2=A0http://qtjambi.sourceforg=
e.net/
=C2=A0GUI via Clojure....
-- Nielshttp://nielsmayer.com=C2=A0

--001636b2b641b6739504871f0c4c--

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
[LAD] Looking for an introduction to rt programming with a gui, Nathanael Anderson, (Thu May 20, 1:14 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Gabriel Beddingfield, (Thu May 20, 1:37 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Niels Mayer, (Fri May 21, 6:42 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Olivier Guilyardi, (Sun May 23, 9:14 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Jens M Andreasen, (Tue May 25, 12:05 am)
Re: [LAD] Looking for an introduction to rt programming with..., Nathanael Anderson, (Thu May 20, 6:39 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Harry Van Haaren, (Fri May 21, 12:32 am)
Re: [LAD] Looking for an introduction to rt programming with..., Olivier Guilyardi, (Thu May 20, 7:20 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Gabriel M. Beddingfield, (Thu May 20, 5:26 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Gabriel M. Beddingfield, (Thu May 20, 8:09 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Philipp √úberbacher, (Thu May 20, 2:32 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Olivier Guilyardi, (Thu May 20, 4:30 pm)
Re: [LAD] Looking for an introduction to rt programming with..., Olivier Guilyardi, (Fri May 21, 9:52 am)