Re: [haskell-art] Mail archives end in March 2010
On Sat, 28 Aug 2010, Henning Thielemann wrote: Any reason, why the Haskell archive ends in March 2010? http://lists.lurk.org/pipermail/haskell-art/ It still does not work. :-( ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Announcement: MIDI stream editor
This is primarily for people who control a software or hardware synthesizer by a MIDI keyboard on Linux. I have programmed a little MIDI event editor, that allows you to alter MIDI channels, automate MIDI controller changes, split keyboard, play patterns according to the set of currently pressed keys, switch instrument everytime a key is pressed and so on. I have uploaded it to Hackage: http://hackage.haskell.org/package/streamed but I think it is of more use to get the darcs repository darcs get http://code.haskell.org/~thielema/streamed/ . Nonetheless, 'cabal install' will install all imported packages, that are necessary for a GHCi session. You should alter the module Sound.MIDI.ALSA.Causal according to your wishes and start a GHCi session with streamed$ make ghci In the module you should replace connectLLVM by connectTimidity and adapt connectTimidity to the names of your devices. Then you might try one of the examples in the 'case' branches of 'main'. Good luck! Henning ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] trouble getting hsc3 to produce sound
On Wed, 6 Oct 2010, Heikki Salo wrote: On Wed, Oct 6, 2010 at 8:52 PM, Renick Bell wrote: everything is executed without errors, and without producing any sound. Have you checked to make sure that SuperCollider is definitely connected to the system playback_1 and playback_2? I like to use Patchage for that purpose. Precisely that was the case! I used # export SC_JACK_DEFAULT_OUTPUTS="alsa_pcm:playback_1,alsa_pcm:playback_2" to pass options to SuperCollider before starting it and vóla, there is sound. Something more sophisticated will be eventually needed, that Patchage looks good. Thanks for the incredibly fast response, I had a several hours lasting fight with this one. :) I also had this once, since earlier versions of scsynth automatically connected to JACK outputs. What tutorial did you use, i.e. where do we have to add the hint about the JACK outputs? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Software Synthesizer mapping ALSA/MIDI events to SuperCollider
I have updated my small software synthesizer to use the new alsa-seq package for receiving MIDI events via ALSA. http://hackage.haskell.org/package/supercollider-midi It is more a proof of concept than something serious. Rohan, I have still a problem: How can I achieve that on releasing a key the sound is not immediately aborted but enters a release phase? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Software Synthesizer mapping ALSA/MIDI events to SuperCollider
Hi Rohan, On Sun, 28 Nov 2010, Rohan Drape wrote: Rohan, I have still a problem: How can I achieve that on releasing a key the sound is not immediately aborted but enters a release phase? There are various ways, however normally you'd do this using the 'gate' input of the 'envGen' UGen. I've added 'envASR' and 'envADSR' parameter constructors (arguments as at sclang) to demonstrate this, there are trivial examples in the help files. Ah I see - a new patch in darcs repository. Thank you! I'll check it. Btw. in Sound.SC3.UGen.Envelope.Construct.d_dx the pattern match d_dx [x,y] = [y - x] can be omitted. You could write d_dx (x:y:r) = y - x : d_dx (y:r) d_dx _ = [] or even simpler d_dx xs = zipWith (-) (drop 1 xs) xs . ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] sfml-audio
On Mon, 6 Dec 2010, Sönke Hahn wrote: I am developing a game in Haskell [1]. For that, I needed a library that would do the following: 1. Play music files. 2. Play sound files with a low latency (for jumping sounds, etc.) 3. Compile on all targeted platforms (Linux, Windows, Mac OS X) using open source tools (compilers, etc.) 4. Be available under an open source license for use in both open source and closed source software. The library I got working after some research was sfml [2]. So I came up with (very minimal) bindings to a subset of the audio module from sfml. I put it up on patch-tag [3]. Any comments welcome. Isn't SDL intended for this purpose? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
On Sun, 2 Jan 2011, Stephen Tetley wrote: I'm trying to make a Stream library, hopefully efficient enough for audio synthesis in the style of Jerzy Karczmarczuk's Clarion. I am trying to code real-time audio synthesis in Haskell for some years now. I can tell at least, that it is not so easily done. Even with the right data structure, GHC's optimizer does not always make, what you need. Thus the most efficiency I get by using LLVM to construct signal processing code at run time, so far. (see synthesizer-llvm package) As performance is important, the obvious model is the Stream-Fusion library, but 'cons' is problematic in this style. Yes, 'cons' is problematic. I think efficient 'cons' needs a material data structure, not just a generator function as in stream-fusion:Stream. data Stream a = forall st. Stream !(st -> Step a st) !st For infinite Streams the Done constructor can be removed from the Step type, a truly infinite is never done: For audio synthesis you need also finite signals. Or am I missing something? At least I found that the 'Skip' constructor can be omitted for audio synthesis: http://hackage.haskell.org/packages/archive/synthesizer-core/0.4.0.4/doc/html/Synthesizer-State-Signal.html bad_loopy :: [Int] bad_loopy = S.append1 (S.take 10 v) [] where v = 1 `S.cons` v The problem is that S.cons must take the internal state type of 'v' and must wrap it in a new type. Thus every S.cons makes the internal state more complicated. This is inefficient for several applications of S.cons and impossible for infinitely many calls. In order to get both elegant laziness and efficiency I played around with a head-strict list implemented via Storable. Here an efficient 'cons' seems to be doable: http://code.haskell.org/storablevector/Data/StorableVector/Cursor.hs However if there remains only one bit of laziness in an inner loop, you will not get good efficiency. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
On Sun, 2 Jan 2011, Stephen Tetley wrote: Un-optimized, with a head-strict stream (basically Wouter Swierstra's Stream with a bang on the element), rendering currently takes minutes to generate seconds. But as well as the Stream representation, I've plenty of room to optimize the WAV file generation. Using stream-fusion:Stream rendered to a low-level list representation you get relatively efficient computation. I used my signal generator type and StorableVector.Lazy in order to perform this one in real-time: http://www.youtube.com/watch?v=KA6DE9jlpSY (see packages synthesizer-core and synthesizer-alsa) That is, even interactive realtime processing is possible, but not very complex one. It requires very disciplined programming and after a small change to your program the GHC optimizer may decide to compile it completely different and the program becomes five times slower. I have also written an overview of what data structures are useful for what signal processing purpose: http://hackage.haskell.org/packages/archive/synthesizer/0.2.0.1/doc/html/Synthesizer-Storage.html Probably I can live without definitions like @ ones = 1 <:> ones @, I would like to know whether of not this is impossible with Stream-Fusion anyway. The recursive style allows for elegant writing of feedback, solution of differential (e.g. oscillation) equations. It's sad, but I think you cannot have it with stream-fusion. Maybe in future GHC or JHC get more cleverness to eliminate even more lazy values. For feedback with longer and constant delay, you might buffer the data in a chunky storable vector and then get efficient recursive computation. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
Hudak, Paul schrieb: > I just wanted to mention that at Yale we are still working on CCA > (causal commutative arrows) to get higher performance digital audio. > Although it may seem objectionable to use arrows at all, it has some > key advantages. For example, you can write recursive signals with no > problem, and they will (theoretically) get optimized as well as > straight-line code. In the meantime I am more and more moving to Arrows or Arrow like structures. On the one hand it is often the more appropriate data structure since it models exactly the causality of signal processes and has much less risk for memory leaks (compared to lazy lists). On the other hand it is sad, that Arrows often need more type tricks in order to work and that with arrows I am forced more or less to pointfree style. I like pointfree style for simple chains of operations but I do not like it for diamond-like graphs, i.e. re-use the result of one signal process multiple times. For simplifying those situation I have recently written a package. It allows me to locally pick the output of an arrow and provide an arrow that gives me easy access to that output in a later process. http://hackage.haskell.org/package/functional-arrow ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style? (fwd)
John Lato schrieb: The other big problem is the name of the "z" function. I would like to call it "z-", but that's not an allowed name. Unfortunately "-z" is allowed as an operator name either. So for now it's backwards for convenience. I'd suggest to call it 'delay' since I find it much more descriptive than the 'z' that refers to the arbitrary variable name chosen for the 'z' transform. Finally, in a blog post a while back sigfpe mentioned using comonads for lazy audio. I spent about 20 minutes on this and although the semantics are nice, I couldn't figure out a way to get good performance for recursive functions (iir filters etc.). Has anyone else tried this? No, but it was interesting to read and my first encounter with a practical Comonad. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
Hudak, Paul schrieb: >> In the meantime I am more and more moving to Arrows or Arrow like >> structures. On the one hand it is often the more appropriate data >> structure since it models exactly the causality of signal processes and >> has much less risk for memory leaks (compared to lazy lists). On the >> other hand it is sad, that Arrows often need more type tricks in order >> to work and that with arrows I am forced more or less to pointfree >> style. > > I almost always use one of the arrow preprocessor syntaxes, which at least > give the illusion of not being point-free. > >> I like pointfree style for simple chains of operations but I do >> not like it for diamond-like graphs, i.e. re-use the result of one >> signal process multiple times. > > But this seems easy using arrow syntax -- am I missing something? I think you cannot translate a functional expression like mix x (delay x) literally to a line of arrow syntax, that is, without introducing a variable name for the output of (delay x), unless I am missing something. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Lazy cons, Stream-Fusion style?
On Tue, 4 Jan 2011, Hudak, Paul wrote: I think you cannot translate a functional expression like mix x (delay x) literally to a line of arrow syntax, that is, without introducing a variable name for the output of (delay x), unless I am missing something. You're right, but it seems relatively painless: y <- delay t -< x returnA -< x+y I guess it's just a matter of style. Of course, in this simple case the problem can be resolved quite easy by introducing a new identifier. My point for the general case is: In an expression, where signal processes are functions and signals are function arguments (like (mix x (delay x))), I need names for signals only when they are shared, i.e. used as input to more than one other signal process. In the arrow notation I need more temporary identifiers, namely whenever a signal process has more than one input that are outputs of more than one arrow. This happens quite often in my experience. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Haskell robots: Haskell - pick up the phone
When I search for "haskell music" on YouTube I get for instance these two videos with dancing robots: http://www.youtube.com/watch?v=ugId3EnWfqc http://www.youtube.com/watch?v=fuktIEB8Rb8 I do not know who or what "Haskell" refers to in this video. It seems they made the same video for many different names. I found it cute. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Open source hardware synthesizers
I am reading on http://lac.linuxaudio.org/2011/?page=participation that one topic of the Linux Audio Conference is "Audio Hardware Support". This refreshes my curiosity whether there are open source Hardware synthesizers? It must cool to feed a hardware synthesizer with DSP code generated by LLVM that is written in Haskell. I am also a bit unsatisfied with my E-MU X-Board61 (an USB/MIDI control keyboard without built-in synthesizer). It has all the knobs and buttons and LEDs I need, but they interact in a way that I would like to change. If its firmware would be open source I could easily adapt it to my needs. Unfortunately not only its firmware is closed-source, but some settings cannot be changed by the built-in buttons, but only via the closed-source Windows software. Sure, it might be possible to snoop the USB communication between a firmware updater and the keyboard and try to analyse it. This would require USB knowledge, some guess on the control chip in the keyboard and a lot of time and patience, and an invalid firmware update may leave the keyboard in an unusable and unalterable state. So, do you know of open-source alternatives? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Open source hardware synthesizers
On Thu, 13 Jan 2011, Erik de Castro Lopo wrote: There is a the FPGA-Synth website and mailing list: http://www.fpga.synth.net/ where people are doing synth designs in Verilog or VHDL and programming them into FLGAs. Thank you for that hint! This is actually relatively easy. I've done it a couple of times. The trick is to do the snooping on Linux (with the usbmon kernel module) and run the windows software under Wine or a VM like VirtualBox. I can start the Windows configure tool with Wine, but when it comes to USB communication it crashes. It is documented in Wine, that USB is still not well supported. I could not run VirtualBox, too, because it seems to be tailored to a Windows file system within a file, but I just want to re-use a Windows installed in a separate partition. I read about ways to get Windows running from such a partition anyway, but this sounded quite fragile to me. some guess on the control chip in the keyboard and a lot of time and patience, and an invalid firmware update may leave the keyboard in an unusable and unalterable state. If you snoop and reverse engineer the protocol you wouldn't need to change the firmware, you'd just be doing whatever the windows program does. There is some hardwired logic in the keyboard, that prevents e.g. that multiple LEDs are active at once, or it resets MIDI transfer channel when selecting a patch. I am afraid this needs reprogramming of some internals of the keyboard. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] a short video of Conductive
On Thu, 30 Dec 2010, Renick Bell wrote: Hello everyone. I've uploaded a video demonstrating Conductive, the library I'm working on for live coding and interactive music applications. It's a two-minute video showing live execution of code in ghci. I'm interested in hearing your feedback or answering your questions. http://www.renickbell.net/conductive/doku.php/examples To be honest, I cannot follow the steps. :-( However I am impressed by the high quality of the video stream. Do you have an encoder specialised to computer desktop graphics or do I estimate the required data volume the wrong way? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Wed, 2 Feb 2011, alex wrote: This list has been around for a good few years now, and has 122 subscribers. There have been some interesting threads, mainly about music libraries, but not a great deal of discussion. The archive says you started it in February 2007 and since then I am advertising it on Haskell-Cafe. :-) Unfortunately archiving stopped in March 2010. Thus this thread will not be archived, too. :-( So, why not hit reply and introduce yourself (even if you've posted already), and reveal your interest in haskell and/or art, whatever that may be. I'll do it too, but someone else go first :) answer to this one follows ... ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Thu, 3 Feb 2011, Stefan Kersten wrote: i think that different (natural or computer) languages allow us to think about interesting problems differently. although i've had some previous exposure to functional programming (opal, anyone?), I remember that Christian Maeder has worked with OPAL. You can meet him at Haskell-Libraries and Haskell-Cafe. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Mailing list archive
alex schrieb: > On 3 February 2011 19:33, Henning Thielemann > wrote: >> Unfortunately archiving stopped in March 2010. Thus this thread will not be >> archived, too. :-( > > I seem to have fixed the archives: > http://lists.lurk.org/mailman/private/haskell-art/ Is it intended to restrict the archive to list members? > Also I notice there seems to be a complete archive here too: > http://blog.gmane.org/gmane.comp.lang.haskell.art Good to know that the mails are archived. Nevertheless I like the simple web pages of mailman. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
John Lato schrieb: > On Thu, Feb 3, 2011 at 6:46 PM, Anton Kholomiov > mailto:anton.kholom...@gmail.com>> wrote: > > sorry i've started new thread, it goes here > > Hi > > I'm making dsl's for music/sound composition. Hope some day i will > stop making dsls and do some music with them. But haskell makes it > difficult. With haskell It's too interesting to write dsl than > things that dsl's suppose to describe. > > > I have this problem too. +1 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Balazs Komuves schrieb: > I sometimes make realtime, procedural "music videos" (it's an old hobby, > see http://en.wikipedia.org/wiki/Demoscene). In the last few years, I > have been doing this in Haskell, simply because I enjoy Haskell much more > than other > languages. However, these programs are not at all elegant pure functional > programs, as they should be, but big ugly hacks thrown together in a > short time :) > > Some examples: > http://www.youtube.com/watch?v=BMuzdTFwV-A Like good old demos on good old Amiga! :-) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Evan Laforge schrieb: > An EDSL to assemble physical models would be interesting. There's > "tassman", but it's not a textual language (one of those boxes and > lines things), has only middling models, is real time (so it can only > use cheap models), and of course is proprietary and seemingly > abandoned (no development in many many years). Even with all that, as > far as I know there's nothing else out there like it. Don't know if it helps, but there is Jerzy Karczmarczuk and his work in Clean, where he mentions waveguide models: http://users.info.unicaen.fr/~karczma/arpap/ ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Wed, 2 Feb 2011, alex wrote: So, why not hit reply and introduce yourself (even if you've posted already), and reveal your interest in haskell and/or art, whatever that may be. I'll do it too, but someone else go first :) Ok, where to start - at the very beginning? I first tried to make sound with the ZX Spectrum from 1986 to 1990 with assembly programming, then with Amiga, various BASICs and assembly programming, then with a Modula-II derivative called Cluster until around 2001: http://www.assampler.com/ Then I tried Modula-3 on Linux. When I later got to know Haskell, I found that I had reinvented lazy evaluation for Assampler. Consequently I moved to the original. I wanted to integrate music composition and signal processing. I wanted programming features for music arrangement, since the many trackers known from Amiga did not offer much structuring and thus required a lot of copy and paste. I wanted programming features also for signal processing, since the interactive graph editing became cumbersome for repetitive signal algorithms like vocoders, although I already added some support for them to Assampler. At a long weekend in 2004 I put together a song using Haskore and custom signal processing functions working on lists: http://users.informatik.uni-halle.de/~thielema/Music/winterade/winterade.mp3 Composing this piece was really crazy, since due to a bug in a SuSE upgrade, I could not play sounds. Thus I transfered every rendered stream to an Amiga via FTP and played it there. Starting from this example I wrote more signal processes, tried to make them safer, cleaner, more flexible, faster, aware of physical units, adaptive to sample rates. I extended Haskore by Paul Hudak, wrote packages haskore-realtime, haskore-supercollider, supercollider-midi, event-list, midi, midi-alsa, streamed (realtime MIDI event manipulation in ALSA), sample-frame, sox, synthesizer-core, synthesizer-dimensional, synthesizer-alsa, synthesizer-llvm, extended and maintained storablevector (based on Spencer Janssen's work), numeric-prelude (based on Dylan Thurston's work), alsa-seq, alsa-pcm (based on Iavor Diatchki's work), jack (based on Sönke Hahn's work). Using plain lists for signal processing I got perfect integration of signal processing and music and hours to wait for rendering results. In contrast to that, the hsc3 package by Rohan Drape allowed me to get realtime sound: http://www.youtube.com/watch?v=d2JvOwS26Zg (YouTube is great in making the audio track sound awful. Better follow the links in the video description to the original files.) Using storablevector, stream-fusion:Stream like signal generators, and arrows for causal processes I got eventually realtime sound with plain Haskell: http://www.youtube.com/watch?v=KA6DE9jlpSY Unfortunately this turned out to be really fragile. You can never predict what the optimizer will do and you easily get code that is no longer realtime. In many times the problem is as follows: If you use a function more than one time, then GHC may no longer inline it, and with the overhead of a real function call and lost opportunities for unboxing the performance drops dramatically. Maybe GHC-7.0 is better in this respect, I still have to check that. 2010 I started to use a DSL targeting LLVM JIT. http://www.youtube.com/watch?v=GNiAqBTVa6U http://www.youtube.com/watch?v=cuzYgJGfMfY Performance is excellent, also due to vector unit support (SSE or AltiVec), but every release of LLVM surprises me with things that worked before and do not work any longer. Integration with Haskell is quite good, but it has the usual problems, that every DSL has. In contrast to a connection to SuperCollider or CSound, I can feed signal data from Haskell to LLVM code and pull it back. I would be very happy to use the same code for list based processing, storablevector based processing and LLVM based processing by some type class framework. That's not very easy, but I already managed to employ some computations both for pure Haskell and LLVM processing. I also spent a lot of time of hunting memory leaks. It is very easy to get them when relying on lazy evaluation. It is even hard or impossible to avoid them, even if you know, where they are. I am uncertain whether this problem is specific to GHC or whether this is hard and unsolved in general. I came to the suspicion that memory leaks are _the_ reason, why the garbage collector is considered to be not ready for real-time applications: The more memory is orphaned the more has the garbage collector to check for liveliness. The typical memory leak works as follows: let (prefix, suffix) = splitAt largeNumber xs in processA prefix ++ processB suffix Although this can be perfectly processed in a streaming manner, sometimes GHC does not manage to release the pointer to the beginning of prefix and thus prefix is kept until the processing of suffix starts. I wonder
Re: [haskell-art] Haskell art?
On Fri, 4 Feb 2011, Stephen Sinclair wrote: Anyways, due to the field I work in, one subject area I find myself obsessed with is the seeming conflicts of interest between functional programming and real-time guarantees (for writing DSP programs, etc). The former allows more powerful ways to express programs and modularize logic, but seems to often require methods for abstracting machine architecture such as garbage collection, which is not compatible with time determinism. Avoiding GC seems to require the use of more restrictive languages like in the case of FAUST, which is basically a declarative DSP description language. I'd like to eventually find just the right balance between time determinism and general-purpose programming. FAUST is essentially like Arrow programming in Haskell. I prefer Arrows in Haskell because they are stricter. E.g. in FAUST you can plug together boxes with non-matching numbers of inputs and outputs and FAUST somehow connects them anyway. I suspect I would more like to get an error in such cases. In synthesizer-llvm I programmed DSP arrows that generate LLVM assembly code. There is no Garbage Collection going on silently. It should be appropriate for tasks with hard time and memory constraints. Actually, Haskell with the 'llvm' package is the greatest macro assembler I ever used! :-) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Sun, 13 Feb 2011, Hudak, Paul wrote: First, my group has designed a new computer music library that I call Euterpea (named after Euterpe, the Greek muse of music). Euterpea has all of the original functionality of Haskore, plus an arrow-based signal processing language for doing audio processing and sound synthesis. It also has a GUI for creating sliders, pushbuttons, and so on. Instructions for downloading Euterpea can be found here: You also told earlier that you have pure Haskell audio processing code. But that is not part of CCA (Commutative Causal Arrows) or Euterpea? (Btw. I did not understand why CCA needs both a preprocessor and Template Haskell, I thought that one of it should be enough.) Also, here is a link to some compositions, mostly by my grad student Donya Quick, all done entirely in Euterpea: http://haskell.cs.yale.edu/?page_id=279 I very like the examples and I am very curious about the Haskell sources that produce those results! Are there samples contained, that are not generated in Haskell or is there some arrangement that was not done in Haskell? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
John Lato schrieb: > Does anyone know of a purely functional equivalent to a circular buffer? It depends on the application you have in mind. For programming a constant delay of n samples of a lazy list including feedback, you can use a lazy list instead of a circular buffer. For efficiency reasons you can use a chunky StorableVector with chunk size up to n. This is like rolling out the circular buffer to an infinite list. Something simple like let output :: [Double] output = mix (input + delay n output) would work. > I'm looking for something that supports efficient insertion and lookup, > and doesn't rely upon mutable data. I don't want to use mutable data > because I'd like to embed this in CCA, which to my knowledge doesn't yet > support Kleisli arrows. Embedding the above idea into an arrow that emits one output sample per input sample would not work. Mutable arrays in the ST monad would help, but this requires that the arrow is built around the ST monad. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] memory leaks
On Thu, 17 Feb 2011, Evan Laforge wrote: liveliness. The typical memory leak works as follows: let (prefix, suffix) = splitAt largeNumber xs in processA prefix ++ processB suffix Although this can be perfectly processed in a streaming manner, sometimes GHC does not manage to release the pointer to the beginning of prefix and thus prefix is kept until the processing of suffix starts. I wonder whether Just out of curiosity, how do you find out when this is happening? I notice large leaks when the machine starts swapping intensively. I detect smaller leaks with 'top'. For even smaller leaks I set a trap using runtime options for restricting heap memory: synthi +RTS -M8m -RTS The program should run with constant memory consumption. If the memory consumption increases, then the program stops when the heap overflows. But before that happens often ALSA reports buffer underruns faster and faster, due to the increasing number of memory pieces that the garbage collector has to check. The fastest way to detect a memory leak is certainly not to play the sound at all, but just write it to disk or /dev/null. Then memory leaks hit a heap memory restriction very qickly. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Thu, 17 Feb 2011, Evan Laforge wrote: However, I've basically given up on that for the moment in favor of just generating MIDI. Just composition is already really complicated without throwing signal processing into the mix. So I wish you best of luck on the signal side, maybe when things on both sides mature I can steal^H^H^H integrate some of that work and finally have the top-to-bottom solution I dreamed of... How about "import" ? :-) Coincidentally, I also got my start on the Amiga... perhaps early exposure to trackers let to my dissatisfaction with MIDI and the typical MIDI sequencer :) My current project winds up looking vaguely like a programmable tracker. I had written some simple conversion from a text presentation of a OctaMED module to Haskore. Maybe you find it useful: http://code.haskell.org/haskore/revised/core/src/Haskore/Interface/MED/Text.hs Do you remember the AmigaBasic music demo? It used a music description they called MML: http://code.haskell.org/haskore/revised/core/src/Haskore/Interface/MML.lhs I wondered whether it is possible to program Emacs or another programmable text editor in a way, that it behaves like a tracker. One could also write content in a column oriented style that is valid Haskell code. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On Tue, 22 Feb 2011, Evan Laforge wrote: I had written some simple conversion from a text presentation of a OctaMED module to Haskore. Maybe you find it useful: http://code.haskell.org/haskore/revised/core/src/Haskore/Interface/MED/Text.hs Indeed, I very well might. I have a bunch of music in OctaMED format that I'd like to extract at some point. Unfortunately somehow most of it wound up in "SFCD" compression which is apparently no longer decompressable (I read something where the original author said he lost the source). I remember long time ago I also analysed that format. It was not too complicated, e.g. he encoded the used channels in one line by four bits that preceded the notes. However, I think the later simple module format with generic powerpacker compression was a good choice. Oh, wait it looks like it requires an octamed to export as text... I guess I'd need to go dig into some of the standalone mod players out there. Yes, that was the easiest for me, since I did not convert a lot of songs. My import is also really simple: Only notes, not even some commands. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Stephen Tetley schrieb: > On 22 February 2011 23:41, Evan Laforge wrote: >> Can you write 'inst2 pitch = reverse (inst1 pitch)'? > > Is 'inst2 pitch = reverse (inst1 pitch)' the backwards instrument? My > first thought would be this is hard to write in any continuous > language even functional/FRP. Since SuperCollider is intended as realtime synthesizer it supports certainly only causal signal processes, which 'reverse' is not. I do not think that its internal design of linked nodes and arrays of input and output buffers can be extended to do something like 'reverse'. If lazy evaluation in Haskell would work properly, that is reliably without memory leaks, then you could nicely combine causal processes (via lazy evaluation) and non-causal processes like reverse (not lazy, but could work on the same signal representation). Another nice example of breaking the orchestra-score barrier is the effect of slowing down a record containing synthesized music. That said, I think separating causal and non-causal processes is a good thing anyway, because e.g. feedback can be done reliably (i.e. without deadlocks) only with causal arrows. However Haskell integrates both causal processing (via arrows) and non-time restricted evaluation (via laziness). ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] jack-0.6
I have updated jack to use midi-0.1.5, removed orphan instances and some more cleanup. Edward Amsden added a function for querying the samplerate. Can you please check, whether it still works for you: http://code.haskell.org/jack/ ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Evan Laforge schrieb: > This sounds like something I've noticed, and if it's the same thing, I > agree. But I disagree that you need to separate orchestra and score > to get it. Namely that notes are described hierarchically (e.g. > phrase1 `then` phrase2 :=: part2 or whatever), but that many musical > transformations only make sense on a flat stream of notes. For > example, decide which note a string would be played on and pick a > corresponding corresponding base note + bend. You can't do this > without a memory of which notes have been played (to know currently > sounding strings) and maybe a look a little ways into the future (to > pick between alternatives). Hierarchical composition has no access > the previous and next notes, so it winds up having to be a > postprocessing step on the eventual note output stream, which means > you have to have something in between the score and the sound. By why > be limited to one one instance of this player and a static score -> > player -> sound pipeline? For other examples a hierarchical structure is exactly the right thing: Think of a filter sweep or a reverb that shall be applied during a certain time interval to a certain set of instruments, say all instruments but drums and the melody. You had to filter those events out of the performance stream and you have to specify the overall duration of the filter effect, since it cannot be derived from the performance. The performance stores only start times and durations of individual events, but it does not store trailing pauses of music sub-trees. > I'm not totally convinced the integration is valuable, but seeing as > almost all other systems don't have it, it seems interesting to > experiment with one that does and see where it leads. Maybe another > way of putting it is that different interpretations of abstract > instructions like legato are not necessarily always along instrument > (piano vs. violin) lines: it may vary from phrase to phrase, or > section to section. I think the hierarchical music structure has its value in being able to be converted to a lot of back-ends. The Performance structure is good for MIDI and Csound. The hierarchical structure is better for SuperCollider and pure Haskell signal processing, because of such effects like filter sweeps, speed variation at signal level, or reversing parts of the music. The hierarchical structure can be simply converted to Performance. I would have thought that the hierarchical structure is also better for music notation, but the actual implementations show, that it is not. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] data structure for music (Was: Haskell art?)
On Fri, 11 Mar 2011, Stephen Tetley wrote: I still don't understand what Evan's reverse instrument models. Is it reversing the sound of a note so it is some function wrapping a unit generator? Or is it reversing a sequence of notes according to pitch? I think he means reversing the signal generated by a part of the music, since this is a classical example of breaking the music-signal barrier. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Live Performing With Haskell
On Fri, 11 Mar 2011, aditya siram wrote: Hi all, I'd like to get into live coding with Haskell. Can you recommend a good enviroment? I run Ubuntu Linux. I've looked into Haskore withn Supercollider but it doesn't seem suited to live performance like something like Chuck or Impromptu. Is there something like this in the Haskell space? Hsc3 works out of the box, if you want to create sounds from GHCi: http://hackage.haskell.org/package/hsc3 I also like my utility package based on that: http://hackage.haskell.org/package/supercollider-ht If you want to edit MIDI streams in a programmatic way, you may try: http://hackage.haskell.org/package/streamed (However you have to adapt the 'connect' commands in Sound.MIDI.ALSA.Common to your needs and then choose an example like '2' in Sound.MIDI.ALSA.Causal.main and load that into GHCi.) You can close the chain between ALSA-MIDI and SuperCollider by: http://hackage.haskell.org/package/supercollider-midi ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] reacting on ALSA events in a wxhaskell application
I managed to write my first Haskell program with a GUI! It shows a window of sliders and when you move a slider it sends an according MIDI controller message via ALSA. http://code.haskell.org/~thielema/alsa-gui/ Now I like to provide the reverse direction: If my program receives a MIDI controller event via ALSA, then it shall update the slider position. I can do this by using WX's timer events and check for incoming ALSA events in regular intervals. Is there also a way to wait for ALSA events as they come in, without a busy wait? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Functional view of music?
On Wed, 1 Jun 2011, Stephen Tetley wrote: Hello all, The functional view of images - image as a function from Point -> Colour - is well practised for continuous images - Conal Elliott's Vertigo and Pan, Jerzy Karczmarczuk's Clastic, plus Pancito, Chalkboard and more. It's even been used for discrete pictures (i.e. vector graphics) - Peter Henderson's original picture language, Antony Courtney's Fruit and my own Wumpus[*]. Is there any prior work considering music functionally, though? - i.e. a function from Time -> Sound Translating (Point -> Colour) to sound, would mean (Time -> Displacement), right? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Functional view of music?
On Fri, 1 Jul 2011, gdwe...@iue.edu wrote:
There's also, on the audio (not necessarily music) side,
Faust ("Functional AUdio STream"):
http://faust.grame.fr/index.php
-- based on composition of block diagrams.
In Haskell we would certainly call that Arrow programming.
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] request for review - circular buffer performance
On Wed, 6 Jul 2011, John Lato wrote: Somewhat to my surprise, my tests show that the Data.Sequence implementation both performs better overall and scales better. I'm not certain that I trust my methodology or implementation, and I would greatly appreciate if anyone would be willing to review my work or provide comments. Details can be found at http://johnlato.blogspot.com/2011/07/circular-buffers.html I would be more confident about the speed figures, if the data is actually written to disk. Otherwise I am not sure, whether you are fooled by lazy evaluation. I use 'time' command for measuring, that outputs the "user time", where time for writing to disk is excluded. In an inner loop I would also not use an IORef (or an STRef) for current position in the ring buffer. An IORef can be accessed from everywhere and thus I expect that GHC will never put it into a CPU register, but will leave it as a boxed Haskell value somewhere in memory. In contrast to that chances for optimizations are better, if the ring buffer position is either part of a State monad or StateT transformer or if the position is stored in a Ptr Int. In the first case, GHC might recognize that the ring buffer position is a state in a loop and put it into a register. In the second case, the position will be managed in memory, but in an efficient way. Also random generators from 'random' package used to be slow - but there were changes and I do not know, whether this is still true. I would have liked to suggest a saw tooth signal as alternative, but erm, properFraction is slow, too. :-( (I have tuned 'fraction' in NumericPrelude to be fast.) You may avoid unsafePerformIO on getStdGen by using mkStdGen with an arbitrary argument. getStdGen is also less random than you may think. See GHCi: Prelude> Random.getStdGen 2048092528 1 Prelude> Random.getStdGen 2048092528 1 Regarding your introduction text, I like to mention that IO in Haskell is still pure, that's why Haskell is called a purely functional language. You may call the mutable RingBuffers a monadic or an IO solution in contrast to the Sequence type, that allows non-monadic/non-IO access. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] ANN: clocked - library for timing IO-operations
On Wed, 19 Oct 2011, Heinrich Apfelmus wrote: > 3) Any chance to drop the QT dependency, perhaps at the cost of > accuracy? Most people probably don't need nanosecond resolution. Maybe a > pure Haskell implementation with threads? Recently I managed to use ALSA for timing in a WX GUI. Of course ALSA is not portable as well. But maybe a solution could be to have different timing back-ends and you can choose the one, that your project already depends on. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Haskell live sequencing
I am happy to present the demonstration of a live sequencer that Johannes Waldmann and me are developing for a month now. http://www.youtube.com/watch?v=88jK162l6mE It is similar to composing in Haskore, but it is interactive. The sound in the video is generated in real-time by my Haskell-LLVM-synthesizer. The sequencer just sends MIDI events via ALSA and can be connected to any MIDI device. You can find repository and bugtracker at: http://dfa.imn.htwk-leipzig.de/cgi-bin/gitweb.cgi?p=seq.git;a=tree http://dfa.imn.htwk-leipzig.de/bugzilla/describecomponents.cgi?product=live-sequencer ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell live sequencing
On Tue, 8 Nov 2011, Heinrich Apfelmus wrote: > I didn't quite catch how interactive this is, though, especially for the > longer piece at the end. Are you reloading code on the fly? I edit the top-left text area and from time to time I update the right area with the modified content. This update is protected by a syntax check (no type check yet, unfortunately). At the beginning of the video you see sometimes syntax error messages that are displayed at the bottom status line. > How do you make sure that a new sequence starts on the beat / interleave > nicely with what is still playing? The trick is to update the program but not the currently processed term. Thus the same term can get a new meaning. The advantage is that I can break a loop and redirect it to somewhere else, e.g. by changing > loop1 = append melody loop1 ; to > loop1 = append melody loop2 ; but the melody keeps running and is not interrupted. The disadvantage is that I cannot break a call to "cycle" and that after program change, the current term may refer to functions that are no longer defined. > Do you use an external MIDI controller to change parameters? As written in the video description I played a solo on an external MIDI controller that bypasses the Haskell-sequencer and immediately controls the LLVM-synthesizer. I also changed some of the parameters of the solo instrument using the external controller. In contrast to that the parameter for the sweep sound is controlled by the Haskell sequencer. Have much fun Henning ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell live sequencing
On Tue, 8 Nov 2011, Brent Yorgey wrote: > On Sun, Nov 06, 2011 at 11:48:07PM +0100, Henning Thielemann wrote: >> >> I am happy to present the demonstration of a live sequencer that Johannes >> Waldmann and me are developing for a month now. >> >>http://www.youtube.com/watch?v=88jK162l6mE >> >> It is similar to composing in Haskore, but it is interactive. The sound in >> the video is generated in real-time by my Haskell-LLVM-synthesizer. The >> sequencer just sends MIDI events via ALSA and can be connected to any MIDI >> device. > > Very cool! I am curious: why the restriction to first-order? This was the most simple to start with and we will extend that: http://dfa.imn.htwk-leipzig.de/bugzilla/show_bug.cgi?id=267 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell live sequencing
Bernardo Barros schrieb: > This is very impressive and promising! Thanks for sharing! Thank you (and all the others) for your interest! > How far did you go with llvm-synthesizer concerning more complex sound > synthesis? Thanks to LLVM and vector processing there are still a lot of unused CPU cycles. However during recording of the video I also needed those cycles for video encoding. > It sounds like you are trying synthesis techniques like FM, right? Yes, the repeated pattern is played with a simple percussive FM sound. > And how about the latency with simple and more complex synthesis? The latency does not depend on the complexity of the sounds. If the sounds are too complex, then the sound becomes chopped and the synthesizer becomes unresponsive independent from how large you choose the latency. If sounds are simple then latency is still a problem. However I managed to get latencies around 10 ms what yields a natural repsonse of the sound to pressed keys. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell live sequencing
On Tue, 8 Nov 2011, Brent Yorgey wrote: > On Tue, Nov 08, 2011 at 11:28:24PM +0100, Henning Thielemann wrote: >> >> This was the most simple to start with and we will extend that: >> >> http://dfa.imn.htwk-leipzig.de/bugzilla/show_bug.cgi?id=267 > > Oh, I see, cool, I thought perhaps there was some technical reason. > > A couple more questions: > > 1. Is there a URL that can be used for cloning the git repo (as > opposed to just downloading a snapshot)? I couldn't find one. I am in no ways a git expert. Wasn't the link I posted a full git repository? At least git clone git://dfa.imn.htwk-leipzig.de/srv/git/seq works for me. If you are interested in cutting edge features - I constantly prepare patches that are in my branch at http://code.haskell.org/~thielema/livesequencer/ from where Johannes pulls into the main branch from time to time. (E.g. after recording the video I added playing of individual terms from within the editor and I added note input via external controllers.) > 2. I got everything to build, but when I follow the instructions in > the README, it looks as if everything is working (the gui shows that > it is sending events etc, timidity is running, aconnect shows them > both) but I get no sound. Anyone have any ideas of things I should > check/try? No idea. Does timidity make a sound if you send events directly to it? Does aseqdump show events coming from the live-sequencer? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell live sequencing
On Thu, 10 Nov 2011, Heinrich Apfelmus wrote: > Henning Thielemann wrote: >> On Tue, 8 Nov 2011, Heinrich Apfelmus wrote: >> >>> How do you make sure that a new sequence starts on the beat / interleave >>> nicely with what is still playing? >> >> The trick is to update the program but not the currently processed term. >> Thus the same term can get a new meaning. The advantage is that I can >> break a loop and redirect it to somewhere else, e.g. by changing >> >>> loop1 = append melody loop1 ; >> >> to >> >>> loop1 = append melody loop2 ; >> >> but the melody keeps running and is not interrupted. The disadvantage is >> that I cannot break a call to "cycle" and that after program change, the >> current term may refer to functions that are no longer defined. > > Nice! And that's also why you've implemented a custom functional language? The language should be just Haskell. Actually the modules can be loaded into GHCi. It would be nice have some infrastructure for Haskell processing such that we do not need to re-implement GHC in the end. > I do wonder about the precise semantics of changing expressions > in-flight, though. For instance, imagine that the program is performing > a time-consuming computation that does not (yet) produce any sound, what > will happen if I update the term that is being evaluated? Or will > updates only take effect at certain "checkpoints", namely whenever a new > MIDI note is created and passed to the synthesizer? How do you detect > which terms have changed and which haven't? The music is described by a list of MIDI events and Wait commands. The rewrite engine accepts changes of the program after every list item. However the current term is not immediately affected by a program change. If the current term is append melody loop and a program update changes the meaning of "loop", then "melody" will be played as before and only when "loop" is reached the update to the program becomes audible. > Do you have any formal model of how exactly this works? With a formal > model, it might be possible to concoct an implementation that can embed > the DSL into Haskell. I am afraid from the point of view of formal languages this is an ugly hack. You have no referential transparency. E.g. as noted above at time point zero the term 'loop' may refer to 'NoteOn 23' and two seconds later it may refer to 'PgmChange 42'. The whole matter of sharing and buffering of reduced terms is no longer an issue of performance but an issue of the semantics. As I said above, loop1 = append melody loop1 allows you to continue with 'loop2' after 'loop1' by changing it to loop1 = append melody loop2 on the fly, but if you would have written loop1 = cycle melody in the first place, this would not be possible. (Only by changing the definition of 'cycle'.) On the other hand you can consider live editing of the program as a phase of development and debugging. You may finally decide to just run the program and play the music without any modifications. In this case you have a clean referentially transparent language. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell live sequencing
On Thu, 10 Nov 2011, Heinrich Apfelmus wrote: > Henning Thielemann wrote: >> >> I am afraid from the point of view of formal languages this is an ugly >> hack. You have no referential transparency. E.g. as noted above at time >> point zero the term 'loop' may refer to 'NoteOn 23' and two seconds later >> it may refer to 'PgmChange 42'. The whole matter of sharing and buffering >> of reduced terms is no longer an issue of performance but an issue of the >> semantics. As I said above, >> >> loop1 = append melody loop1 >> >> allows you to continue with 'loop2' after 'loop1' by changing it to >> >> loop1 = append melody loop2 >> >> on the fly, but if you would have written >> >> loop1 = cycle melody >> >> in the first place, this would not be possible. (Only by changing the >> definition of 'cycle'.) > > Ah, so if I understand that correctly, the procedure works as follows: > some terms are referred to by names and updating the program means > changing the terms associated to these names, even while the program is > being evaluated. yes > As soon as graph reduction begins to evaluate one of > the named terms, the "connection" to the name will be broken and an > update to the name will no longer affect the term being evaluated. yes > (So, updating a program would behave a bit like "switching pointers".) > > Is this an adequate representation of what you have implemented? I think so > (That's why I'm looking for something "formal", i.e. a precise > description of what happens.) I think a formal description would have to tag rules and terms with time stamps or step numbers. The step number must be increased after every list element in the top-level list. However these step numbers would have to be automatically attached when you update the interpreted program with modified content from the editor and they are neither shown in the highlighting text area nor in the text area for the current term. > Probably not, because my description would imply that the > cycle melody example should work. After all, the name "melody" is > being duplicated and the later instances could easily be updated on the > fly. Yes, this is possible. You can alter the meaning of 'melody' and cycle will incorporate changes in the definition of 'melody'. However you can break out from cycle only by altering the definition of 'cycle' (and thus every call to cycle is affected, not only the melody-cycle). And if you would have written cycle (concat [note qn (c 4), note qn (e 4)] ) you could even not alter the looped sequence of notes. > Also, my description doesn't seem to rely on the fact the engine > only accepts changes after each MIDI note / wait item. The expected top-level data structure is a list, and the interpreter evaluates this list element by element, asking for program changes before every element. We think about a single step mode for educational purposes that shows reduction steps with certain degrees of granularities. Thus the number of break points might be increased in future. Currently the easiest way to answer questions about the semantics is to run the program (not a good answer, I know :-) Do you plan to attend our after-HaL meeting next thursday? I could also try to add a JACK back-end. I hope this would allow to run the program on Mac, too? > I'm just wondering if there's a way to get this kind of behavior from > plain GHCi by using really dirty tricks. For instance, I'm thinking that > observable sharing (to get names) and hash-consing (to get equal names > after reloading a file) might make it possible to implement the "switch > pointers" method I described. Somehow, it seems to me that the only > thing you need is access the names of variables from a Haskell source file. Update of the program could be done by calling :load in GHCi. But then you have to store the current program content in a way that survives :load. Best, Henning ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] real-time sound synthesis (Was: Haskell live sequencing)
Hi Bernardo, On Tue, 15 Nov 2011, Bernardo Barros wrote: > The whole idea of writing dsp algorithms directly in haskell is very > interesting. I think it would be much more intuitive to extend synthesis > systems like this. That's what I hope for. Currently there still some low-level clutter around. > But there are so many good options like supercollider (and hsc3 for > instance), that it is very discouraging using a less efficient system > for real-time. > > You told you could not do much complex synthesis with your system, Did I tell this? What I wanted to express was, that latency and complexity of sounds are two separate issues. I can't reduce latency by reducing complexity. But I can handle complex sounds at the same latency as simple sounds. > is this because you don't have a bigger block size? I can freely choose the block size. > Or Haskell garbage collector? What is your strategy in this respect? When I had a problem with the garbage collector I had actually always a problem with a space leak. I am now on a good way to eliminate them using arrows instead of lazy lists. However I find programming this way more complicated. > There are other systems trying to make decent DSP performance with > languages other then C. The second version of JSyn is all written in > pure Java, not c like the first version. That is good! The same language > for high and low level work, Yes, that's I achieve with LLVM and Haskell, too. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] real-time sound synthesis (Was: Haskell live sequencing)
On Tue, 15 Nov 2011, Stephen Sinclair wrote: > However, there is certainly potential to implement a FAUST-like DSL in > Haskell. The trick would be to compile it to machine code in-memory > in a non-realtime thread and be able to dynamically modify the DSP > graph by adding and removing blocks without interrupting the audio > stream. I believe this could be achieved by atomic pointer swapping > to new bits of real-time code, but I haven't personally tested the > idea. > > It's already possible to do similar things using Haskell-LLVM, isn't it? In terms of Haskell, FAUST is a DSL based on arrows. I also use (causal) arrows for LLVM based signal processing. > Of course swapping sub-blocks in and out of a larger DSP graph implies > that on some level there is a master "mixer" or something, which is > itself a DSP block. This implies to me that there are multiple levels > of optimization possible. If a subblock is swapped out, should its > parent be recompiled for maximum efficiency? How do you decide where > to stop? Maybe some incremental compilation strategy could be used to > first swap a child and then recompile parents up the chain, eventually > resulting in the whole graph being recompiled. In my LLVM software synthesizer I already swap blocks in and out, since whenever a key is pressed a new signal generator is started and it is stopped and removed when the release phase terminates. The results of all signal generators are mixed. However this is hard-coded and does not yet use one of the functional reactive programming frameworks. I considered on-demand compilation, that is compilation of instrument specific code once the instrument is used first, but this would yield a high latency for the first played tone. > In any case, another difficulty is maintaining state between > recompilations. If a block is swapped out and the parent is > recompiled, it would be desirable for any state (filter history, etc) > in the parent not affected by the child to remain intact. This may > require some tracking strategy in the compiler, but I see it as a > possibly surmountable obstacle. Because of all of these difficulties and because I suspect that the benefit is small, I have not tried to do clever recompilation and optimization during the musical performance. Currently I structure instruments like this: complexSound (append attackDecay release) where each of attackDecay, release, complexSound contains a block of LLVM compiled code and Haskell manages routing of the signal chunks. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] umbrella term for flats and sharps
I have a question for the native English speaking musicians: What is the umbrella term for flats and sharps? In German it is "Vorzeichen" and in Dutch it is "voortekens", which could be translated to "signs". Background: MIDI File specification allows to set a key signature and represents it by the number of flats or sharps and the mode (major or minor), where a negative number measures flats and a positive number counts sharps. Is "signs" a good term for this count or what else is reasonable? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] umbrella term for flats and sharps
On Mon, 16 Jan 2012, Duncan Mortimer wrote: > Hi Henning, > > I just learnt that my previous message was incorrect: I hadn't > realised that an 'accidental' refers only to notes modified from the > current tonal context. Thankyou wikipedia! This was, what I learned from Wikipedia, too. :-) > Sorry about that. I'm not sure what the technically correct English > term is for the 'number of sharps and flats in the key signature'. > 'Signs' seems reasonable to me. Ok ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Mail server problems
On Mon, 6 Feb 2012, alex wrote: I moved the server this list resides on over the weekend. As a result the haskell-...@lists.lurk.org address was not forwarding correctly to haskell-art@lurk.org . I sent a mail but neither got a bounce nor did it appear on this list. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Professorship for Musical computer science in Karlsruhe
Since my latest e-mail passed the mailing list, I resend this one: -- Forwarded message -- Date: Mon, 6 Feb 2012 16:23:53 +0100 (CET) From: Henning Thielemann To: Haskell Art Mailing list Subject: Professorship for Musical computer science in Karlsruhe Maybe this job advertisement is interesting for some of you: http://jobs.zeit.de/jobs/karlsruhe_professur_fuer_musikinformatik_w3_72423.html They seek people with experiences in LISP, but maybe they are also interested in Haskell as a "successor" to LISP? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell] ANNOUNCE: diagrams 0.5
On Fri, 9 Mar 2012, Brent Yorgey wrote: I am pleased to announce the release of version 0.5 of diagrams [1], a full-featured framework and embedded domain-specific language for declarative drawing. Check out the gallery [2] for examples of what it can do! [1] http://projects.haskell.org/diagrams [2] http://projects.haskell.org/diagrams/gallery.html I can't see the images in the gallery. :-( Are these simple HTML-img images or are there advanced JavaScript hacks involved? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell] ANNOUNCE: diagrams 0.5
On Fri, 9 Mar 2012, Henning Thielemann wrote: On Fri, 9 Mar 2012, Brent Yorgey wrote: I am pleased to announce the release of version 0.5 of diagrams [1], a full-featured framework and embedded domain-specific language for declarative drawing. Check out the gallery [2] for examples of what it can do! [1] http://projects.haskell.org/diagrams [2] http://projects.haskell.org/diagrams/gallery.html I can't see the images in the gallery. :-( Are these simple HTML-img images or are there advanced JavaScript hacks involved? I see these images are in SVG, that seems to be the problem. Would it be much effort to make the images in the overview PNGs and show the SVG only in the source code page? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell] ANNOUNCE: diagrams 0.5
On Sun, 11 Mar 2012, Brent Yorgey wrote: Hi Henning, Ah, sorry about that. I was under the impression that SVG was just as widely supported now as PNG, but I see now I was mistaken. The reason I used SVGs was purely selfish: they look better when resized by browsers so I only had to generate the large size which could be used both on the individual pages and as (resized) thumbnails. I have now switched back to using PNGs and generate the thumbnail size separately so they still look good. How does it work for you now? Superb! The crazy thing is, that my browser shows SVGs but only standalone and not embedded in an HTML page. :-( ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Professorship for audio design and digital music production in Munich
Hi all, sometimes I read job advertisements like the following one where I think they could be interesting for Haskell artists. Are you interested in such advertisements or shall I stop spamming the Haskell art mailing list with them? "Professor für Audiodesign und digitale Musikproduktion" http://www.academics.de/jobs/professorin_professor_fuer_audiodesign_und_digitale_musikproduktion_75157.html Regards, Henning ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] HaL-7, 2012-07-13, Call for submissions
Call for submissions and Save the date for our local Haskell Workshop in Halle/Saale, Germany. Tutorials, talks, demonstrations ... everything welcome. Workshop language is German (mainly), and English (by request). Submission deadline: May, 21, Workshop date: July, 13 Workshop homepage: http://iba-cg.de/hal7.html The complete call in German: - Aufruf zum Einreichen von Beiträgen und Hinweis zum Vormerken des Termins Was: Haskell-Treffen HaL-7 Wann: Freitag, 13.07.2012 Wo: Institut für Informatik an der Martin-Luther-Universität in Halle an der Saale Wir suchen Vorträge zu Haskell im Besonderen und der funktionalen Programmierung im Allgemeinen, zum Beispiel zu den Themen * Neues von Sprache, Bibliotheken, Werkzeugen, * Anwendungen von Kunst bis Industrie, * Lehre an Schulen und Hochschulen, gerne aber auch zu anderen Themen. Die Beiträge können präsentiert werden als * Tutorium (60 .. 90 min) * Vortrag (30 min) * Demonstration, künstlerische Aufführung Die Veranstaltungssprache ist Deutsch, in begründeten Ausnahmen Englisch. Presentations will be given in German but we can switch to English if requested. Bitte reichen Sie Kurzfassungen der Beiträge ein (2 bis 4 Seiten), die dem Programmkomitee eine Einschätzung ermöglichen. Die Kurzfassung soll mit einer Zusammenfassung (10 Zeilen) beginnen und einem Literaturverzeichnis enden. Teilnehmer des Workshops sind Interessenten (keine Erfahrung mit Haskell/FP), Anfänger (wenig Erfahrung) und Experten. Wir bitten die Vortragenden, die Zielgruppe des Beitrags anzugeben und die nötigen Vorkenntnisse zu beschreiben. Bei Tutorien sollen Teilnehmer auf eigenen Rechnern arbeiten. Bitte beschreiben Sie dazu die vorher zu installierende Software. Schicken Sie Beitragsvorschläge als PDF-Dokument bis zum 21.05.2012 per Mail an hal-committee at iba-cg punkt de oder an ein Mitglied des Programmkomitees. Programmkomitee * Henning Thielemann - Univ. Halle (Vorsitzender), * Petra Hofstedt - BTU Cottbus, * Alf Richter - iba CG Leipzig, * Uwe Schmidt - FH Wedel, * Janis Voigtländer - Univ. Bonn, * Johannes Waldmann - HTWK Leipzig. Mit besten Grüßen Henning Thielemann ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] hosc, rfc
On Fri, 25 May 2012, Rohan Drape wrote: Dear List, I've made some rather basic changes to hosc. This message is to let people know before it ends up on hackage, and because I'm interested in any comments. Through to hosc-0.11 the representation has been: data OSC = Message Address [Datum] | Bundle Time [OSC] At http://slavepianos.org/rd/sw/hosc it is now: data Message = Message Address [Datum] data Bundle = Bundle Time [Message] data Packet = P_Message Message | P_Bundle Bundle class OSC o where toPacket :: o -> Packet ... The initial representation followed the OSC specification and allowed nested bundles. As far as I understand, people can still use the Packet type, if they prefer case analysis to type distinction. However, I think the transition would be easier if the names Packet and OSC are swapped and you provide smart constructors that emulate the behaviour of old Bundle and Message constructor. I think I have never pattern matched on the old OSC constructors but I used the Bundle constructor for construction. With OSC keeping its semantics, all existing type signatures can remain. Thus I propose: data Message = Message Address [Datum] data Bundle = Bundle Time [Message] data OSC = OSCMessage Message | OSCBundle Bundle message addr dat = OSCMessage (Message addr dat) bundle time msgs = OSCBundle (Bundle time msgs) class Packet o where toOSC :: o -> OSC ... I don't think I have used nested bundles - how would the time stamp be interpreted? But if people need it then you could provide it by a Bundle type with type parameter. Then you could statically enforce a certain nesting depth by making the type parameter Message or Bundle, or you can do arbitrary nesting by using the OSC type as parameter. data Message = Message Address [Datum] data Bundle msg = Bundle Time [msg] data OSC = OSCMessage Message | OSCBundle (Bundle OSC) message addr dat = OSCMessage (Message addr dat) bundle time msgs = OSCBundle (Bundle time msgs) class Packet o where toOSC :: o -> OSC ... This solution would give you all of the type safety of your new approach and easy transition for the people who are used to the old approach. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Lilypond parsing with Haskore
On Fri, 29 Jun 2012, Corbin Simpson wrote: I've written a library, called Lye, that compiles a strict subset of Lilypond to a meta-MIDI format. Lilypond can generate MIDI files for the notesheets you create. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Audio Processing and Sound Sunthesis in Haskell
On Sun, 1 Jul 2012, CK Kashyap wrote: I started reading the paper "Audio Processing and Sound Sunthesis in Haskell" - I was wondering if there is some place I could download the source code from? I'd appreciate it very much if you could point me to the source. I dont know if it is part of Haskore - but I'd prefer a standalone source code so that I could work with it as I read the paper. Hm, good question. That code is really old. The audio signal processing code is stand-alone code embedded in the TeX file and the Haskore code refers to http://hackage.haskell.org/package/haskore-vintage My further work lead to the 'synthesizer' packages, like synthesizer-core, synthesizer-dimensional, synthesizer-midi, synthesizer-alsa, synthesizer-llvm. You may find an overview in: http://hackage.haskell.org/packages/archive/synthesizer/0.2.0.1/doc/html/Synthesizer-Overview.html ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Audio Processing and Sound Sunthesis in Haskell
On Sun, 1 Jul 2012, CK Kashyap wrote: Hi All, I started reading the paper "Audio Processing and Sound Sunthesis in Haskell" - I was wondering if there is some place I could download the source code from? I'd appreciate it very much if you could point me to the source. I dont know if it is part of Haskore - but I'd prefer a standalone source code so that I could work with it as I read the paper. I want to add, that in the meantime we developed a kind of interactive Haskore: http://hackage.haskell.org/package/live-sequencer Here is a demonstration of what 'scanl (=:=) empty' means for music: http://www.youtube.com/watch?v=sXywCHR9WwE :-) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Audio Processing and Sound Sunthesis in Haskell
On Sun, 1 Jul 2012, CK Kashyap wrote: Hi All, I started reading the paper "Audio Processing and Sound Sunthesis in Haskell" - I was wondering if there is some place I could download the source code from? I'd appreciate it very much if you could point me to the source. I dont know if it is part of Haskore - but I'd prefer a standalone source code so that I could work with it as I read the paper. I see you meant a different paper than my "Audio Processing using Haskell". Then my answer was not correct and Paul Hudak may answer instead. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] asound not found during Euterpea installation
On Thu, 5 Jul 2012, CK Kashyap wrote: Hi all, I tried to install Euterpea on ubuntu 12.04 and ran into this problem. Can someone tell me the exact package name that I need to install using apt-get to solve this problem? Resolving dependencies... Configuring PortMidi-0.1.3... cabal: Missing dependency on a foreign library: * Missing C library: asound This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. apt-get install libasound2-dev (found with: dpkg --search alsa/pcm.h ) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] asound not found during Euterpea installation
On Sun, 8 Jul 2012, CK Kashyap wrote: After this, I tried to do "play childSong6" - nothing happened - my sound card probably does not support midi. So I installed timidity and ran it as follows "timidity -iA -Os&" - I re-ran ghci and found that it still did not play the music. So did a "" and generated the midi file. timidity played it beautifully Are you on Linux? 'play' is part of the SoX package and should only play pcm audio files. It may try to play the MIDI data as raw pcm data, though. As a first test you can play a MIDI file using simply 'timidity file.mid'. If you run timidity with -iA option, then it is in server mode and may be controlled by other programs like an external keyboard, 'pmidi', our live-sequencer or some Haskell code from GHCi like reactive-balsa. In order to actually control timidity by another program you must connect the controlling program and the controlled program either from the command-line with 'aconnect' or from a GUI like 'patchage', 'qjackctl', 'alsa-patch-bay' or 'kaconnect'. With 'pmidi -l' or 'aconnect -o -i' you can list servers and clients with their ALSA address. I assume that Euterpea uses PortMidi which uses ALSA but in order to be portable PortMidi does not integrate so nicely with the ALSA framework. A program using PortMidi does not appear as an ALSA client or server, it can only directly control other programs. I think the default is that PortMidi writes to the Client 'Midi Through'. So you must connect 'Midi Through' to TiMidity: $ aconnect 'Midi Through' TiMidity I still cannot believe "the quality of synthesis" does timidity synthesize the instruments or it has stored samples??? TiMidity is a sampling synthesizer. If you want better samples you may install package fluid-soundfont-gm. (For real sound synthesis in Haskell I can assist building synthesizer-llvm. :-) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] asound not found during Euterpea installation
On Tue, 10 Jul 2012, CK Kashyap wrote: Thank you very much Dr Hudak, Yup it helps ... I was able to play it from GHCI ... I cannot describe my excitement in words!!! ... then express it with music! :-) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Quick questions about volume control
On Fri, 13 Jul 2012, CK Kashyap wrote: Henning et al, Looks like It's gonna take me a little more time to get a hang of Haskore - although editing music in Emacs has been extremely thrilling. I have a quick question - how do I specify the volume of a note in Haskore? First I think that it is essential to distinguish strictly between 'velocity' and 'volume' (in the MIDI sense). Velocity is a parameter per note, that tells with what force a tone is played. A higher velocity may alter the sound to be brighter than normal or to not alter the sound at all. This depends entirely on the instrument. In contrast to that there is MIDI (channel) volume (controller 7). This is a simple amplification at the signal level. You may alter the velocities of notes with the dynamics constructors, like crescendo and decrescendo. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Quick questions about volume control
On Sat, 28 Jul 2012, Hudak, Paul wrote: Sorry for the late reply to this. In Euterpea (which subsumes Haskore) there are two ways to deal with volume. First, a Music value is polymorphic. So a value of type Music Pitch only contains pitch, whereas a value of type Music (Pitch,Volume) contains both pitch and volume. You can add a default volume to a Music Pitch value using addVolume: addVolume :: Volume -> Music Pitch -> Music (Pitch,Volume) But such a per-note volume is actually a Velocity (in MIDI terms), right? doubleVol (Prim (Note d (p,v)) = note d (p,2*v) doubleVol m = m The MIDI standard says, that in case that a velocity is mapped simply to a volume (and not to an altered sound) then this mapping should be exponential. That is, 2*velocity is certainly not what you want, but making the tone louder should be done by adding a constant to the velocity. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Is Haskell Really A Real-Time Language?
On Mon, 6 Aug 2012, Anton Kholomiov wrote: Haskell is not for hard real time. Hard real time means for any operation you know how long does it takes to execute it. Current GC makes it impossible. You have to design GC for real-time. There is one real world real time library in Haskell that I'm aware of. It's Atom. It's code generator for C. There is another library called Copilot and it is built on top of the Atom. There is also Feldspar which compiles signal processing code to C. Heinrich has already kindly pointed to my synthesizer-llvm project. There I create LLVM code for inner loops in audio signal processing that contain no allocations and thus no garbage collection and thus should be realtime. However, when it comes to synthesis of some sounds according to MIDI input I use a lot of Haskell code which is not hard realtime. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Is Haskell Really A Real-Time Language?
On Mon, 13 Aug 2012, Anton Kholomiov wrote: Online code generation is an interesting option. You can do many optimisations. For example if we have chain of units -> a -> b -> c -> d -> We can (in theory) make one loop, instead of four loops. That's what I do with the LLVM-JIT. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Is Haskell Really A Real-Time Language?
On Tue, 14 Aug 2012, Anton Kholomiov wrote: Cool stuff! Is it a great win in practice? I have compared SuperCollider and my synthesizer-llvm and they are comparable in speed (it is difficult to find equivalent processes in both projects). That is, synthesizer-llvm is really fast, but not faster than SuperCollider, although synthesizer-llvm fuses loops and SuperCollider does not. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Is The Amplitude Scaling Formula in Dodge/Jerse Correct?
On Sat, 18 Aug 2012, Haskell Media wrote: Hi, Page 152 of the second edition of Computer Music by Dodge/Jersey reads: A practical method is to equalize the power in the signal to a constant value. For true power scaling, the scaling function is chosen as: S(a) = 1 / [(1/4)*h0(a)^2 + h1(a)^2 + h2(a)^2 + h3(a)^2 + ... + hN(a)^2 ]^(1/2) But if you use the pure sine wave (in other words h0(a) = 1 and all the other harmonics are zero, S(a) = 2 not 1. It seems to me that if your scaling factor is above 1 then something is wrong with your scaling factor. I think a pure sine wave has h1(a)=1 and h0(a)=0 since h0 is the direct current offset. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Quick questions about volume control
On Sun, 19 Aug 2012, Hudak, Paul wrote: On Sat, 28 Jul 2012, Hudak, Paul wrote: The MIDI standard says, that in case that a velocity is mapped simply to a volume (and not to an altered sound) then this mapping should be exponential. That is, 2*velocity is certainly not what you want, but making the tone louder should be done by adding a constant to the velocity. It is my understanding that both volume and velocity can be interpreted differently by different MIDI devices. Sure, but I in my understanding the MIDI standard recommends an exponential scale. A different volume can be specified for each MIDI channel, although Euterpea does not provide a direct way to do this (currently the channel volumes are all set to the maximum). The MIDI spec recommends that a device use the volume value in a logarithmic manner, as specified by the following formula: 40 log (Volume/127) Is Volume the MIDI Channel Volume value or the signal amplitude? In my opinion the MIDI Channel Volume must be inside an 'exp' call. I searched for such a recommendation in the MIDI specification several times and was disappointed to not find one. Where did you find that formula? I have once sampled the output of a Yamaha synthesizer and found that they represent a doubling of amplitude by 16 steps of MIDI channel volume. I found this to be a reasonable convention. The according formula would be: amplitude = 2**((midiChannelVolume-127)/16) or equivalently amplitude = 256**((midiChannelVolume-127)/128) midiChannelVolume = 16 * logBase 2 amplitude + 127 midiChannelVolume = 16 * logBase 2 (amplitude * 2**(127/16)) where 2**(127/16) ~ 245 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Is The Amplitude Scaling Formula in Dodge/Jerse Correct? (fwd)
-- Forwarded message -- Date: Mon, 20 Aug 2012 11:07:09 +0200 (CEST) From: Henning Thielemann To: Haskell Media Subject: Re: [haskell-art] Is The Amplitude Scaling Formula in Dodge/Jerse Correct? On Sun, 19 Aug 2012, Haskell Media wrote: f0 is the fundamental. Dodge defines f0 to be the fundamental when he was talking about distortion techniques a few pages before this... That's very strange because the coefficient 1/2 for the direct current partial is very common since it matches our intuition of amplitude of sine waves and direct current. The complex Fourier series is simpler in this respect because the coefficients are all equally weighted. https://en.wikipedia.org/wiki/Fourier_series#Fourier.27s_formula_for_2.CF.80-periodic_functions_using_sines_and_cosines My guess is that the scaling factor they used in the book was specifically for Chebyshev polynomials. Still not clear on why it scales up to 2 Would be nice to have a general scaling formula for additive synthesis (if the "Dodge" amplitude scaling isn't the general formula already). Btw. for computing the power of the signal you do not need the harmonics at all. You can simply compute the L2 norm of the signal thanks to Parseval's identity. https://en.wikipedia.org/wiki/Parseval's_identity ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Starquake music
Are some lovers of the good old 8-bit era here? I have remade some songs of the ZX Spectrum game Starquake (it seems to have had different melodies on different systems): http://www.youtube.com/watch?v=ogSeONthWK0 Of course, there was a lot of Haskell involved in the processing, although you cannot see it. The original sound was: http://www.youtube.com/watch?v=SV_8hAAZ8Hk ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Starquake music
On Mon, 24 Sep 2012, David Barbour wrote: Wonderful work, Henning! Yours is definitely better than the original. May I suggest another? Try some dungeon music from Legacy of the Wizard. I don't know this game - have to scan my Speccy ClassiX CD. Another game with cool music I remember is in Ping Pong. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Library for simple playing of sounds?
On Wed, 10 Oct 2012, Iavor Diatchki wrote: is there an existing Haskell library that makes it easy to play and mix audio samples in a portable way? (with emphasis on easy and portable :-) At the first glance I wondered why _you_ ask this question, because you have written the ALSA bindings that I maintain. :-) Easy and portable is certainly a problem. You may try the 'sox' library which calls the 'play' command. However this requires that the 'sox' package is installed. It is certainly also possible to add the functionality to the soxlib bindings. http://hackage.haskell.org/package/sox http://hackage.haskell.org/package/soxlib http://hackage.haskell.org/packages/archive/sox/0.2.2.2/doc/html/Sound-Sox-Play.html ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] controlling a digital fly and building a USB power supply
I prepared another small video: http://www.youtube.com/watch?v=om5q_Ror_bo It shows * a Döpfer Pocket Fader controlling a fly sound generated by the Haskell LLVM synthesizer * disassembling my self-made USB power supply for the Pocket Fader ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Sending MIDI via Jack
On Sun, 4 Nov 2012, alex wrote: Would anyone have a example to hand of how to send MIDI messages over Jack using Haskell? I have not a working example but I would like to add one to the 'jack' package. The general idea is to chop your MIDI stream into blocks of a duration that the JACK server provides, and then send the blocks when their time comes. You may communicate with your JACK client from the main thread via Concurrent.Chan. E.g. you may send the MIDI stream block by block via a Chan. You may also use an IORef to maintain a state in the JACK client. Then you could initialize the client with a pointer to the stream and let the client chop the stream. Here is a simple software synthesizer that converts MIDI input to audio output, if that helps: http://code.haskell.org/jack/examples/Synthesizer.hs ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] ANN: hsc3-process-0.8 and hsc3-server 0.5
On Thu, 20 Dec 2012, Miguel Negrao wrote: Writing long functions or expressions in emacs to be run in ghci is a bit difficult because you can’t use the normal indentation rules (at least I haven’t figured out how), so one possibility would be to just write those functions in a .hs file and load the file to ghci, but every time one does that the previous bindings are destroyed and loose access to the server that we booted, and any resources on it, so that doesn’t work for interaction with a sc server via hsc3-server. Does anyone have any tips about this ? Instead of indentation you might break big expressions into small expressions and local functions using 'let'. Would that help? Nonetheless, you lose what you wrote if you leave GHCi. (If you are lucky some lines are stored if you re-enter GHCi and can be retrieved with cursor-up.) ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] ANN: hsc3-process-0.8 and hsc3-server 0.5
On Fri, 21 Dec 2012, Rohan Drape wrote: You can run the 'unlayout' process over outgoing expressions in emacs using 'shell-command-to-string'. You can define GHCi commands (those with leading colon) based on Haskell functions. Maybe you can create an :unlayout command? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] port midi
On Wed, 26 Dec 2012, Balazs Komuves wrote: I cannot help with portmidi, however, if you don't need Linux compatibility, the hmidi package (http://hackage.haskell.org/package/hmidi/) works on both OSX and Windows (and does not have any external dependencies). There are some simple examples included in the package. Don't forget to use the --threaded flag when building. JACK and the Haskell jack package are another option. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] hsc3-server interactive session was ANN: hsc3-process-0.8 and hsc3-server 0.5
On Fri, 4 Jan 2013, Miguel Negrao wrote: I’m happy to report that I’ve found that leksah has a quite nice and working interactive ghci pane. It has a window for writing code (a scratch buffer), where one can use indentation based rules, and it has another pane with all the variables defined so far. To evaluate code one either selects a portion of code or puts the cursor on a line and hits ctrl-enter. It feels very interactive. Thank you for this hint! If I want to run multiple IO actions in ghci and bind the result to “variables” that I can use later, is this the best way ? (engine,r,send) <- do engine <- MS.new withDefaultSynth let send a = MS.execute engine $ exec_ a r <- MS.execute engine rootNode return (engine, r, send) In GHCi you could just write Prelude> engine <- MS.new withDefaultSynth Prelude> let send a = MS.execute engine $ exec_ a Prelude> r <- MS.execute engine rootNode But if you want to bundle all three actions, then your do-block is certainly the best way. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] hsc3-server interactive session was ANN: hsc3-process-0.8 and hsc3-server 0.5
On Sat, 5 Jan 2013, Renick Bell wrote:
You can do multiline evaluation in ghci with regular indentation
(without internal braces) by preceding and following up your code like
this:
Prelude> :{
Prelude| do putStrLn "first line"
Prelude| putStrLn "second line"
Prelude| :}
first line
second line
Prelude>
Cool! I was not aware of this GHCi feature.
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] special Rate types for hsc3
Hi Rohan, I just ran into another instance of using an UGen with a Rate type that it does not support. I got the error: *** Exception: mk_osc: rate restricted: (KR,[AR],"Pulse") but I thought this could also be solved on the type level. data AudioRate = AudioRate data ControlRate = ControlRate class GenericRate rate where toRate :: rate -> Rate instance GenericRate AudioRate where toRate AudioRate = AR instance GenericRate ControlRate where toRate ControlRate = KR impulse :: GenericRate rate => rate -> UGen -> UGen -> UGen pulse :: AudioRate -> UGen -> UGen -> UGen Even better would be to make the rate a type parameter of UGen: impulse :: (GenericRate rateFreq, GenericRate rateWidth, GenericRate rate) => UGen rateFreq -> UGen rateWidth -> UGen rate pulse :: (GenericRate rateFreq, GenericRate rateWidth) => UGen rateFreq -> UGen rateWidth -> UGen AudioRate ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] private e-mail archive
I found that the e-mail archive of haskell-art is now private. Is this intended? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] testing if values can be applied to polymorphic functions
On Thu, 7 Feb 2013, alex wrote: Now I have idea for making this more interesting and practical (for live music-making, if nothing else), and would like to re-write it all in Haskell. Testing type compatibility of expressions is foxing me though. For example, say I have (++) and [1,2,3]. I then want to see if a value of type (Num a => [a]) can be applied to a function of type ([a] -> [a] -> [a]). That is, you want to do Haskell type checking in Haskell? I do not understand how Typeable could help here. If you are happy with a simplified Haskell type system you could try the type checker from the Helium project. I have also heard that the Haskell suite shall contain a type checker. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] talks concerning Haskell on Linux Audio Conference, May, 9th and 10th
If you are interested in the two talks at Linux Audio Conference by Renick Bell and me you can watch them life and ask questions via IRC at: http://lac.linuxaudio.org/2013/stream They are: May, 9th, 15:10 Renick Bell: An Approach to Live Algorithmic Composition using Conductive May, 10th, 15:10 Henning Thielemann: Live music programming in Haskell Best, Henning ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Generating sounds in Haskell
On Sun, 1 Sep 2013, Noah Hall wrote: Hi all, I'm currently working on a game where the music is being generated through converting the pixels on screen into musical tones. At the moment, I have a working prototype in Python, however, I'm working on converting it into Haskell. The question I have is are there any recommended texts or open source libraries that I should look at in order to improve the conversion process? I intend on using the Data.WAVE module and simply porting the variance and ADSR envelope algorithms over. Any other suggestions regarding creating more "authentic" tones would also be appreciated. Is it important for you to generate particular sounds, or would it be ok for you to control a MIDI synthesizer like TiMidity via MIDI? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Generating sounds in Haskell
On Mon, 2 Sep 2013, Noah Hall wrote: On Mon, Sep 2, 2013 at 12:02 AM, Henning Thielemann wrote: Is it important for you to generate particular sounds, or would it be ok for you to control a MIDI synthesizer like TiMidity via MIDI? At the moment, I'm quite interested in maintaining control over the generation of sounds as a learning experience. I can advertise my own sound generation routines. There are simple ones that are pure Haskell: http://hackage.haskell.org/package/synthesizer-core/ and other ones that need LLVM, that are very fast, but have installation overhead: http://hackage.haskell.org/package/synthesizer-llvm/ For real-time sound generation you might also like to control SuperCollider: http://hackage.haskell.org/package/hsc3/ Euterpea also has sound synthesis, but as far as I know it is not on Hackage: http://haskell.cs.yale.edu/euterpea/ ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Haskell can sing
Hi all, it's again Advent time and I took the opportunity to program another song for you. Those who liked last year's songs [1,2,3] may also be interested in the new one: http://www.youtube.com/watch?v=0EQCgi5qa3E "Alta trinita beata" It employs the great Haskell live sequencer and a new speech synthesizer that I developed with Haskell and LLVM. You find additional information in the video description. Best, Henning [1] http://www.haskell.org/pipermail/haskell/2012-December/023591.html [2] http://www.youtube.com/watch?v=-fmxHM69zgI [3] http://www.youtube.com/watch?v=O5k0wUh0lj8 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] ANN - csound-expression-3.1.0 - now with GUI elements
On Thu, 12 Dec 2013, Evan Laforge wrote: On Thu, Dec 12, 2013 at 12:23 PM, Anton Kholomiov wrote: The little piece: https://github.com/anton-k/csound-expression/blob/master/examples/Heartbeat.hs I was sort of hoping for an MP3, yeah I know I'm lazy :) I am lazy, too, in this respect. Thus my vote for a rendered audio file. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)
On Fri, 13 Dec 2013, Evan Laforge wrote: This is my experience too (though I'm a notation guy, I tried hard with DAWs but still found them slow and awkward). And I've never heard any music out of csound or other text languages that isn't more or less abstract and sound-designy. Maybe there is someone out there that manages to do it, but I haven't heard them. Music, as always, is largely determined by the tools used to create it. At the Linux Audio Conference 2013 in Graz someone recommended in his talk not to think of audio programs as software but as instruments. For programs users request more and more features, whereas for instruments the restriction on certain producible sounds is a feature. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell art] Haskell art in the media
Am 12.04.2014 21:48, schrieb Karsten Gebbert: > Quoting Evan Laforge (2014-04-12 17:49:59) > >> The same goes for MIDI, MIDI drivers already provide a scheduler. > > When I wrote this I focussed on trying to find the simplest solution for > MIDI output and ended up using the Alsa raw MIDI library as a starting > point. This was quite instructive for understanding how talking to > hardware in such a simple case works and worked, but it does indeed lack > scheduling of MIDI messages, which is probably why I completely > overlooked that approach. You may study the examples of the alsa-seq package, e.g. example/melody.hs for how sending with timestamps works: http://hackage.haskell.org/package/alsa-seq -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/1u0N6BH5JnzWi196Gg5i4A To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
[haskell art] HaL-9 - Call for Contributions
Hi all, in case you missed the announcement at: http://www.haskell.org/pipermail/haskell/2014-March/024115.html I'll forward it to here. Our workshop still lacks some art artifacts generated with Haskell. Original-Nachricht HaL ist ein lokaler Haskell-Workshop mit überregionaler Bedeutung, der nun bereits das 9. Mal stattfindet. Dieses Jahr laden wir für den 20. Juni ins Institut für Informatik an der Martin-Luther-Universität Halle-Wittenberg ein. Wir suchen Beiträge zu Haskell im Besonderen und der funktionalen Programmierung im Allgemeinen, aber auch Anknüpfungen an andere Programmierparadigmen. Dabei interessieren wir uns unter anderem für die Themenbereiche * Neues von Sprache, Bibliotheken, Werkzeugen, * Anwendungen von Kunst bis Industrie, * Lehre und Forschung an Schulen und Hochschulen. Die Beiträge können präsentiert werden als * Tutorium (etwa 90 min) * Vortrag (etwa 30 min) * Demonstration, künstlerische Aufführung Die Veranstaltungssprache ist Deutsch, nach Absprache auch Englisch. Presentations will be given in German but we can switch to English if requested. Bitte reichen Sie Kurzfassungen der Beiträge ein (max. 3 Seiten), die dem Programmkomitee eine Einschätzung ermöglichen, sowie eine knappe Zusammenfassung von etwa 100 Wörtern. Teilnehmer des Workshops sind Interessenten (keine Erfahrung mit Haskell oder funktionaler Programmierung), Anfänger (wenig Erfahrung) und Experten. Wir bitten die Vortragenden, die Zielgruppe des Beitrags anzugeben und die nötigen Vorkenntnisse zu beschreiben. Bei Tutorien sollen Teilnehmer auf eigenen Rechnern arbeiten. Bitte beschreiben Sie dazu die vorher zu installierende Software. Senden Sie die Beitragsvorschläge als PDF-Dokument bis zum 27. April 2014 an hal-commit...@iba-cg.de Wir werden Ihnen bis zum 9. Mai mitteilen, ob wir Ihren Beitrag in das Programm aufnehmen. Für das Organisationsteam Henning Thielemann -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/7jyItVXjYYVE7UvjRTVa9p To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
[haskell art] robot drum machine (was: Haskell art in the media)
Am 12.04.2014 16:12, schrieb Karsten Gebbert: > Last year I wrote a little music sequencer in Scheme, partly because it > was needed in an installation I was working on with a friend (see > http://sonicrobots.com/ for an impression), The drum machine is really cool! -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/4Hd2G1kG16TKpxgreBeOXQ To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] Haskell art in the media
Am 14.04.2014 02:49, schrieb Evan Laforge: > I know the question isn't for me, but I do the same kind of stuff and > the gc isn't a problem for me because latency is not a problem. I > think only time latency is relevant is when you want external input to > immediately have a reaction. So basically only if you're creating a > physical performance instrument and want that ear-to-hand feedback > cycle. right > I'm guessing livecoding doesn't care that much, because while > you want your change to be reflected soon, it's not critical that it > happen within 4ms of your hitting enter. It's probably going to wait > until the next beat or cycle anyway. Yes, for our live sequencer we also accept a latency of 0.1 seconds. > Henning Thielemann's synthesizer work would care about GC though, > because he's making a real time instrument. He can speak for himself, > but I seem to recall he either is very careful to get allocation out > of the core loop, or he compiles down to allocation-free code via LLVM > or something. But I'm guessing that's more for performance on the > synthesis side than latency. Right, I am using LLVM mainly for increasing performance. Keeping allocations out of the core loop using LLVM would be nice, but there is still a lot of Haskell code involved in that loop. This becomes a problem with short buffers, like the standard buffer of JACK containing only 64 samples, i.e. ~1ms at 48000. > All that said, I think if you don't allocate unreasonable amounts, > even major GCs are pretty fast. I wouldn't worry about it for soft > real time like music. You might have to spend some time with the > profiler and threadscope to work out your lag/drag, is all. My early problems with the garbage collector were space leaks. The more memory the GC has to process the slower it becomes. I used lazy lists and it was very easy to produce space leaks and it was very hard to get rid of them. Since I switched to causal arrows these problems have gone. -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/4Nuakfn9O1M2c86wRVJNmW To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
[haskell-art] Automated YouTube uploads
In case I did not announce it before - I wrote a set of two small programs that upload videos to YouTube. It is useful in two situations: 1. Upload a list of videos with metadata fetched from a spreadsheet. 2. Upload from a remote machine without a graphical browser. http://hackage.haskell.org/package/youtube You need 'curl' to be installed and you need to register for a YouTube developer key. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell art] Automated YouTube uploads
In case I did not announce it before - I wrote a set of two small programs that upload videos to YouTube. It is useful in two situations: 1. Upload a list of videos with metadata fetched from a spreadsheet. 2. Upload from a remote machine without a graphical browser. http://hackage.haskell.org/package/youtube You need 'curl' to be installed and you need to register for a YouTube developer key. -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/3AtsLk1V1i57vEcCDgT25c To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] [haskell-art] Retirement of mailman list - last email
Am 14.05.2014 12:03, schrieb alex: > Dear all, > > This is the last email to the haskell-art mailing list, as hosted by mailman. > > To continue receiving messages to haskell-art, make sure you are > subscribed to the new groupserver forum here: >http://lurk.org/groups/haskell-art/ It seems the new web-site requires javascript in order to see the archive of posts. That's a real regression compared to the former setup. :-( -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/3yANtL60DQYLAOLeJZ8eQ6 To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] [haskell-art] euterpea realtime? or other realtime audio in haskell
it seems that my comment got lost ... Am 14.05.2014 00:44, schrieb Ben Burdette: > I'm doing a project where incoming values from sensors are to be turned > into music. currently I have a haskell program that scans the sensors > and generates OSC messages as a result. So far so good. How about this one: https://www.youtube.com/watch?v=om5q_Ror_bo However, it is not Euterpea but synthesizer-llvm. See example/Synthesizer/LLVM/LNdW2011.fly as an entry to the code. -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/29RU23RSbvdC5aP64YLt8u To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
