Re: [LAD] A small article about tools for electronic musicians

On May 1, 2010 06:20:26 pm you wrote:
> On Sat, May 1, 2010 at 2:21 PM, Tim E. Real <termtech@email-addr-hidden> 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.
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.

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

_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Received on Sun May 2 04:15:02 2010