Re: Block simulation / audio processing
Koen Claessen wrote:
The reason we removed the monads was that circuits with
feedback (loops) in them became very tedious to define. One
had to use monadic fixpoint operators (or "softer" variants
on them), which were really unnatural to use. Also, the
monadic style enforces an ordering on the components that
you are using, while in a circuit, there is no such ordering
(everything works in parallel).
I always thought that monads (or just more concretely: CPS) *help*
to sequentialize the processing of streams, but that one is
never obliged to put them where unneeded.
Loops ("short" loops which in Matlab are called "algebraic")
either must be sequentialized anyway, or - as in Matlab - they
generate some equations which must be solved globally; one gets
into something like constraint programming.
I wonder what is the Lava approach to those loops then. OK, I will
read the cited paper. For the moment Koen mentioned that the system
"detect" loops. And the real fun *begins* here...
Jerzy Karczmarczuk
Caen, France
Re: Block simulation / audio processing
Has anyone built any block simulators (for modeling continuous
electronic systems, like OP Amps, RC networks, etc) in Haskell?
There have been several replies to this already, but permit me to add my
2 cents worth:
FRP ("Functional Reactive Programming") is an abstraction of Fran
("Functional Reactive Animation") that is ideally suited to describing
such things, since it is based on continuous (time-varying) values, as
opposed to discrete values. You can find out a lot about Fran from
Conal Elliott's home page (http://www.research.microsoft.com/~conal) and
from my book (http://haskell.org/soe), and about FRP at
http://haskell.org/frob. My student Zhongong Wan and I also have a new
PLDI paper on the formal underpinnings of FRP if anyone is interested
(it's not on the web yet).
As for Haskore:
I'm also interested in this. I am thinking of extending
Paul Hudak's Haskore system to generate and handle true audio data
(instead of, or in addition to) MIDI data.
I don't think I'll have enough time to do the programming myself,
but since I'll be using Hudak's book in next term's course,
I hope I can attract some students, and set them in the right
direction.
In fact one student who read the course announcement
(and the book's web page) already asked me
about functional audio signal processing.
The latest release of Haskore (http://haskell.org/haskore) includes an
interface to Csound. That is, one can wire up oscillators, modulators,
special effects, etc. in a nice declarative style in Haskell, which then
gets compiled into a Csound instrument file, which in turn gets compiled
by Csound into actual sound files (.wav, .snd, etc.). The nice thing
about this is that it's fairly efficient because of the back-end
processing. To do this in FRP would be much less efficient.
Hope this helps,
-Paul
Re: Block simulation / audio processing
Am I correct in saying that the way time is handled is by a function that gets the current time and functions that calculate the state of the system at the time given by that call? So in FRP, time is continuous, but the points of calculation are not controlled by the Haskell code. I'm not sure I understand the question. Here's an example that might clarify. In FRP/Fran/Fal I can write "sin time". The meaning of that behavior depends on some kind of an interpreter. Normally, the intepreter tries to run it in real time, as I think you are suggesting, for example when trying to generate graphical animations. But you can define the interpeter any way that you like. For example, you could define one that took very small time steps, thus generating a very fine-grained animation that you played back later at a faster rate. Or you could define an interpreter mimicking the denotational semantics that would give you the single value of the behavior at some given point in time: sin time `at` pi/2 == 1 By the way, relative to a given interpreter, you can also do time transformations, such as: timeTrans (pi/2) (sin time) `at` 0 == 1 I hope this helps, -Paul
Re: Block simulation / audio processing
Has anyone built any block simulators (for modeling continuous electronic systems, like OP Amps, RC networks, etc) in Haskell? I'm also interested in this. I am thinking of extending Paul Hudak's Haskore system to generate and handle true audio data (instead of, or in addition to) MIDI data. I don't think I'll have enough time to do the programming myself, but since I'll be using Hudak's book in next term's course, I hope I can attract some students, and set them in the right direction. In fact one student who read the course announcement (and the book's web page) already asked me about functional audio signal processing. Any pointers appreciated, -- -- Johannes Waldmann http://www.informatik.uni-leipzig.de/~joe/ -- -- [EMAIL PROTECTED] -- phone/fax (+49) 341 9732 204/209 --
Re: Block simulation / audio processing
Johannes Waldmann : Has anyone built any block simulators (for modeling continuous electronic systems, like OP Amps, RC networks, etc) in Haskell? I'm also interested in this. I am thinking of extending Paul Hudak's Haskore system to generate and handle true audio data (instead of, or in addition to) MIDI data. In fact one student who read the course announcement (and the book's web page) already asked me about functional audio signal processing. Any pointers appreciated, There are two distinct problems/areas here. 1. Block simulators, dataflow interfacing etc... People mentiond FRAM, but somehow I missed (improbable that nobody fired the *obvious* keyword here): HAWK!!! See the Haskell Home page, you find all about. 2. DSP, audio streams, etc. This is another story, although DSP in a dataflow style is something full of sex-appeal (at least for me, an old physicist...). Frankly not too much about the functional approach to DSP on the Web. I can give you some dozens of pointers to tutorials, algorithm description, etc., since I am interested (at least conceptually) myself. Lazy algorithms for the filter design, for mad recursive special effects (flanging, reverb), for the spectral synthesis, pitch shifting - all this is nice, elegant, fascinating, clever... ...and horribly inefficient ... Do you realize the amount of data processed in order to generate 10 seconds of audio stream at 96kHz of the sampling frequency? First, real-time generation might have severe problems with the garbage-collection. Generating all this off-line is OK. (BTW. I remember that Paul Hudak thought about generating CSound streams from Haskore, but I lost tracks of it...) Generating true audio data might be quite heavy. Frankly, I think that perhaps one should begin with something intermediate between MIDI and real audio streams, we could for example make a functional tracker which combines (and transforms) pre-formed audio samples. Thank you for the inspiration. If I had time enough... Jerzy Karczmarczuk Caen, France
Re: Block simulation / audio processing
Mike Jones asked: | Has anyone built any block simulators (for modeling | continuous electronic systems, like OP Amps, RC | networks, etc) in Haskell? Johannes Waldmann added: | I'm also interested in this. I am thinking of | extending Paul Hudak's Haskore system to generate and | handle true audio data (instead of, or in addition to) | MIDI data. Jerzy Karczmarczuk answered: | HAWK!!! See the Haskell Home page, you find all about. : | DSP, audio streams, etc. Do you realize the amount of | data processed in order to generate 10 seconds of | audio stream at 96kHz of the sampling frequency? I did not reply with *my* abvious answer: LAVA!! :-) This is because I thought the original question was about *continuous* systems, and Lava (and Hawk) are about discrete/digital systems. But if you find that the Hawk way is interesting to do these kind of things, take a look at Lava as well. Lava has recently gotten a major rewrite (no monads left!), and at the moment we are evalutating the new version in a course. One can take a preview in the Lava tutorial, available on: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/ The main difference between Hawk and Lava is the following. Hawk programs describe sequential systems mainly targeting simulation (running these in Haskell). This means one can use any Haskell datatype and function in the definition of a system. Very powerful and expressive! Lava programs can be simulated, but also unfolded to yield a description of the system in a different, lower-level, language. Examples of these languages are VHDL, C, EDIF, state machine notation, temporal propositional logic, etc. This means that the programmer is limited to use datatypes that can be expressed in terms of basic types supported by the target language (usually booleans and integers or floats), and to use functions that can be expressed in terms of basic operations on these types. When describing a specific domain, for example gate-level hardware, this does not seem to be too much of a problem. It would be interesting to see if one can use the Lava approach to describe a system that performs, say, an algorithm on an audio stream. The algorithm would be expressed in terms of basic operations on audio streams. In the end one could generate C (or so) from this description. If anyone is interested in doing such a thing, I would be happy to send a preliminary version of Lava, and to explain how it is implemented and how to modify it to deal with other domains than digital hardware. Regards, Koen. -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 e-mail:[EMAIL PROTECTED] - Chalmers University of Technology, Gothenburg, Sweden
Lava (was Re: Block simulation / audio processing)
Koen Claessen wrote: I did not reply with *my* abvious answer: LAVA!! :-) This is because I thought the original question was about *continuous* systems, and Lava (and Hawk) are about discrete/digital systems. But if you find that the Hawk way is interesting to do these kind of things, take a look at Lava as well. Lava has recently gotten a major rewrite (no monads left!), and at the moment we are evalutating the new version in a course. One can take a preview in the Lava tutorial, available on: http://www.cs.chalmers.se/Cs/Grundutb/Kurser/svh/ Great! Does this mean that at last you will release Lava? I found Lava very interesting, but could not re-create it completely from your published papers. And so far you have not made the source code available.. Regards, Rob MacAulay Rob MacAulay Cambridge
RE: Block simulation / audio processing
Koen Claessen wrote: But if you find that the Hawk way is interesting to do these kind of things, take a look at Lava as well. Lava has recently gotten a major rewrite (no monads left!), ... I'm interested to know the rationale behind removing the monads. My admittedly small experience with Haskell has led me to avoid monads when the same can be achieved with "pure" functions, and for much of the same reasons that I find imperative programming ugly. But other people seem to love them! --PeterD
RE: Block simulation / audio processing
Jerzy, 1. Block simulators, dataflow interfacing etc... People mentiond FRAM, but somehow I missed (improbable that nobody fired the *obvious* keyword here): HAWK!!! See the Haskell Home page, you find all about. This is exactly what I have been looking at. My be problem is how to dynamically control the step size of algorithms to support algorithms that have non-uniform step size. Perhaps some kind of clock divider scheme. Mike
RE: Block simulation / audio processing
Peter Douglass wrote: | [Lava] I'm interested to know the rationale behind | removing the monads. The reason we removed the monads was that circuits with feedback (loops) in them became very tedious to define. One had to use monadic fixpoint operators (or "softer" variants on them), which were really unnatural to use. Also, the monadic style enforces an ordering on the components that you are using, while in a circuit, there is no such ordering (everything works in parallel). The way we removed the monads was by making a little extension to Haskell, called Observable Sharing, which allows one to detect if two branches in a tree are really the same branch or merely copies of each other. Since this is not possible to do in Haskell, this extension technically defines a new language (not Haskell). See our paper for more details [1]. The extension allows one to detect loops and shared component in a datastructure. To our delight, Lava circuit descriptions now look very much like Hawk circuit descriptions. One of our goals was to make the two systems come closer together. Unfortunately, when we were struggling taking the monads out of Lava, the Hawk people seem to have it gotten into their mind to put in monads! :-) Their solution to the feedback problem is to extend the do-notation to introduce monadic fixpoint combinators automatically (just as it introduces = at the moment). This idea has been around for a long time, but I have not seen or come up with a satisfactory solution to it. I am looking forward to seeing their solution! A big advantage of having monads is of course that you can put a lot of extra information in them about the used components, such as layout information. Currently we are developing new ways to do this without monads. Regards, Koen. [1] Koen Claessen, David Sands, "Observable Sharing for Functional Circuit Description", ASIAN '99, Phuket, Thailand, 1999. http://www.cs.chalmers.se/~koen/Papers/obs-shar.ps -- Koen Claessen http://www.cs.chalmers.se/~koen phone:+46-31-772 5424 e-mail:[EMAIL PROTECTED] - Chalmers University of Technology, Gothenburg, Sweden
