
Hello All, I'm not sure if this is possible with Reactive or any extant FRP language, but it couldn't hurt to ask the experts :) the high level version of my question is: Does Reactive (or one of its friends) provide the right basic abstractions for doing a subset of - specifying mixing / fades over time (and other DJ related tasks), which conceptual would be constructing some sort of Digraph out of various computational steps (and that are each potentially ) - a mechanism for changing this sequencing in some part of the digraph (ie at some point conceptually changing how the djing is being done) I'm sort of thinking about things wrt the basic djing streams being processed by a circuit / digraph of computations, and there being a meta language for manipulating the circuit. This probably falls totally outside the purview of current FRP as far as I can tell, but if I'm incorrect in thinking that / or some equally appealing approach exists, I'd love to find out! thanks -Carter Schonwald

Hello, The Haskell-Art mailing list is an alternative forum for such subjects: http://lists.lurk.org/mailman/listinfo/haskell-art Personally, I believe the FRP paradigm should be suitable for the tasks you describe, but we are probably not there yet. Changing the graph is probably the nontrivial part, but specifying fades/etc should be easy. If you want a full-blown music producing / synthesizer system, then it again becomes hard because of the performance requirements. You probably need to Just-In-Time compile the circuit to some low-level language. But this is definitely possible; for example Henning Thielemann has such a prototype synth: http://hackage.haskell.org/package/synthesizer-llvm Balazs On Sun, May 13, 2012 at 2:47 AM, Carter Schonwald < carter.schonwald@gmail.com> wrote:
Hello All, I'm not sure if this is possible with Reactive or any extant FRP language, but it couldn't hurt to ask the experts :)
the high level version of my question is: Does Reactive (or one of its friends) provide the right basic abstractions for doing a subset of
- specifying mixing / fades over time (and other DJ related tasks), which conceptual would be constructing some sort of Digraph out of various computational steps (and that are each potentially ) - a mechanism for changing this sequencing in some part of the digraph (ie at some point conceptually changing how the djing is being done)
I'm sort of thinking about things wrt the basic djing streams being processed by a circuit / digraph of computations, and there being a meta language for manipulating the circuit. This probably falls totally outside the purview of current FRP as far as I can tell, but if I'm incorrect in thinking that / or some equally appealing approach exists, I'd love to find out!
thanks -Carter Schonwald
_______________________________________________ Reactive mailing list Reactive@haskell.org http://www.haskell.org/mailman/listinfo/reactive

On 14.05.12 15:11, Balazs Komuves wrote:
Personally, I believe the FRP paradigm should be suitable for the tasks you describe, but we are probably not there yet. Changing the graph is probably the nontrivial part, but specifying fades/etc should be easy. If you want a full-blown music producing / synthesizer system, then it again becomes hard because of the performance requirements. You probably need to Just-In-Time compile the circuit to some low-level language. But this is definitely possible; for example Henning Thielemann has such a prototype synth: http://hackage.haskell.org/package/synthesizer-llvm
fwiw, henning also has released a package for doing midi event processing with the reactive-banana library [1]. regarding sound synthesis and processing, there are some options that allow haskell control of a synthesis engine written in C/C++, e.g. hsc3 (supercollider) [2] and hCsound (csound) [3]. personally i've been using reactive-banana and hsc3 in some recent projects, where FRP "events" are rendered by sending graph manipulation messages to the supercollider synthesis engine. <sk> [1] http://hackage.haskell.org/package/reactive-balsa [2] http://hackage.haskell.org/package/hsc3 [3] http://hackage.haskell.org/package/hCsound
participants (3)
-
Balazs Komuves
-
Carter Schonwald
-
Stefan Kersten