[LAD] A small article about tools for electronic musicians

Niels Mayer nielsmayer at gmail.com
Sat May 1 22:20:26 UTC 2010


On Sat, May 1, 2010 at 2:21 PM, Tim E. Real <termtech at rogers.com> wrote:
>
> 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 ]]

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/rW_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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxaudio.org/pipermail/linux-audio-dev/attachments/20100501/15d07792/attachment.html>


More information about the Linux-audio-dev mailing list