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
Paul, I took a cursory look at your book. 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. Mike > -Original Message- > From: Paul Hudak [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 19, 2000 6:45 AM > To: [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED] > Subject: 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
> 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
Mike Jones wrote: >.. . 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. In general this is one of the gray areas between continuous (discretized anyway) and discrete (clocked) simulations. Synchronous, clocked approach is less than well adapted to this sort of problems, because the link between the global clock time and the local discrete time for an adaptive DE algorithm ceases to exist. Yes, why not division? Or just, if you are interested in the final solutions as trajectories and *not* as sequences of events, you forget about clocks. (This is my very naive and minima- listic viewpoint...) The *strictly technical* problem on how to control the step size depends on the algorithm. I wonder whether there are some generic strategies here. Jerzy Karczmarczuk Caen, France
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
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
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
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
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
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
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
> > 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
> Has anyone built any block simulators (for modeling continuous electronic > systems, like OP Amps, RC networks, etc) in Haskell? If so, any website > URLs would be of help to me. Not really my area, but I haven't seen any answers (or adverts) yet, so here are my 2 cents: I assume that you've checked haskell.org, and have done a bibliography search, so you've probably seen the work on hardware description in functional languages. Those I know of model digital systems, but you can get some ideas about general approaches to hardware simulation in Haskell. A non-obvious relation: you might want to check the links to functional reactive programming. There are instances for animation (Fran), robotics (Frob), vision (Fvision), but the common core is continuous time based simulation. This includes differentiation and integration, so you might be able to model some simple systems directly via differential equations, with the bonus of getting support for animating your circuits/measurements. The algorithms in current Fran are a bit crude (better numerical approximations were used in earlier versions, but haven't been ported yet..). If you are going to built a new library: it would be interesting to see whether Fran ideas could be combined with Jerzy Karczmarczuk's functional differentiation (links to both can be found in the libraries section on haskell.org). Claus
Block simulation
Hi, Has anyone built any block simulators (for modeling continuous electronic systems, like OP Amps, RC networks, etc) in Haskell? If so, any website URLs would be of help to me. Mike