2 May
2010
2 May
'10
1:58 a.m.
On May 1, 2010 06:20:26 pm you wrote:
On Sat, May 1, 2010 at 2:21 PM, Tim E. Real
<termtech(a)rogers.com> wrote:
Ah, so
'Stalin' is a Scheme compiler, among many.
So could Scheme be used in real-time audio apps? Jack-SuperApp-Scheme?
What I'm 'Geda'ing at, is a marriage of electronics and realtime audio...
Easy electronics-schematic-to-audio-plugin, or something like that...
Realtime functional audio blocks? (Hmm, PD territory?)
Or beyond audio: Realtime functional electronics blocks?
There was an old linux app - CHIP or something like that - which
allowed you to draw circuits and they 'just worked' live when completed.
I've always wondered why they don't make
a fixed-point co-processor...
That's what the three other 3.4G cores are for... or should be, in a more
ideal world.
It's too bad people don't write programs that can automatically decompose
into a parallel-execution (e.g. multithread) solution. Today's talk on
using continuation-passing style in scheme was a step in the right
direction ( http://lac.linuxaudio.org/2010/download/kjetil.pdf ) --
"Implementing a Polyphonic MIDI Software Synthesizer using Coroutines,
Realtime Garbage Collection, Closures, Auto-Allocated Variables, Dynamic
Scoping, and Continuation Passing Style Programming" Kjetil Matheussen. [[plug: http://mitpress.mit.edu/sicm/book.html --
Structure and
Interpretation of Classical Mechanics ]]
Quite the tome. (Found a Poincare term
"resonance island". Sounds neat.)
Good text. Applies mechanics + Scheme programming. And it's free? Well...
Thanks. Tim.
Speaking of java, all these concepts should be "cloudified" -- figure out a
way to get google app engine to make a "cloudsynth" (of course, it should
integrate qmidinet so as to setup midi routing appropriately). Maybe using
clojure -- since it's basically lisp in java, with attention paid to
parallel programing. And since underlying clojure is java, you get the
standardized and widely-used/debugged java.math libs such as arbitrary
precision arithmetic, so you can mix and remix to your hearts' content
without bit-loss... of course, if a mix itself was a closure, then there'd
be no bit-loss, or copying, since everything would just be a computation
upon an original, prior, sound source. (You'll be able to 'unmix' any sound
-- kind of like an infinite "mix" undo -- and like self-describing data, a
"self describing mix")....
For more info on clojure and functional programming:
See
http://www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/0609/r
W_CS_FunctionalProgramming.pdfas good intro.
The Promises of Functional Programming
By Konrad Hinsen
Adopting a functional programming style could make your programs more
robust, more compact, and more
easily parallelizable. However, mastering it requires some effort.
Wondering whether Google App Engine would be able to host such an
application, I check
http://elhumidor.blogspot.com/2009/04/clojure-on-google-appengine.html
which says:
THE BIG CAVEAT
Two unusual aspects of the Google AppEngine environment create pretty major
constraints on your ability to write idiomatic
Clojure.
First, an AppEngine application runs in a security context that doesn't
permit spawning threads, so you won't be able
to use Agents, the
clojure.parallel library, or Futures.
Second, one of the most exciting features of AppEngine is that your
application will be deployed on Google's huge
infrastructure, dynamically
changing its footprint depending on demand. That means you'll potentially
be running on many JVMs at once. Unfortunately this is a strange fit for
Clojure's concurrency features, which are most useful when you have
precise control over what lives on what JVM (and simplest when everything
runs on one JVM). Since shared references (Vars, Refs, and Atoms) are
shared only within a single JVM, they are not suitable for many of their
typical uses when running on AppEngine. You should still use Clojure's
atomic references (and their associated means of modification) for any
state that it makes sense to keep global per-JVM, since there may be
multiple threads serving requests in one JVM. But remember JVMs will come
and go during the lifetime of your application, so anything truly global
should go in the Datastore or Memcache.
-- Niels.
http://nielsmayer.com