Re: [haskell art] haskell-art] euterpea realtime? or other realtime audio in haskell
― Attachment links are at the end of this email ― Em 15-05-2014 17:18, Hudak, Paul escreveu: > Ok, yes, this could be done easily in Euterpea. Another great feature then... ! :-) best, Miguel Haskell Art now contains the following file http://lurk.org/r/file/n1YhWA0f2A6xgD1Vw1tdSZDOcsR-8G-2sQbcoG Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/3Ly3DQ2HXPbDz0ZOh6FTAB 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
Ok, yes, this could be done easily in Euterpea. -Original Message- From: haskell-...@group.lurk.org [mailto:haskell-...@group.lurk.org] On Behalf Of Miguel Negrão Sent: Thursday, May 15, 2014 12:11 PM To: haskell-...@group.lurk.org Subject: Re: [haskell art] haskell-art] euterpea realtime? or other realtime audio in haskell ― Attachment links are at the end of this email ― Em 15-05-2014 16:02, Hudak, Paul escreveu: > Euterpea has what we call "clock polymorphism," with which signal > functions can be defined that are polymorphic in the sampling rate. > And there is a simple mechanism to "coerce" from one rate to another. > Phantom types are used to ensure statically that signals of different > rates cannot be accidentally mixed. > > That said, I don't know if that directly addresses the over-sampling > problem that you refer to. In particular, we can write, for example, > WAV files at different rates, but currently don't have a way to > sample real-time audio at different rates. Seems doable though. Well, even in the case of rendering an audio file you could want to render just part of the graph at a higher sample-rate (.e.g n x 44100), for instance to avoid aliasing of an oscilator with partials above 22050, allowing you to place a low pass filter and remove frequencies above 22050 before they fold back into the audible spectrum, and then you could down-sample again into 44100 (this could even be done automatically), and finally render the file at 44100. In the case of rendering a file this would keep the render times much smaller then if you would have to run the whole graph at the higher sample-rate. best, Miguel Haskell Art now contains the following file http://lurk.org/r/file/oyr1kJ99H4hVDjj0apUR3UAJ1GV-8G-2sPL8K4 Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/7B0wn3rROMeke50CVYQytF To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/5zC8NUeVwbSzMJZlgRrGjw 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
― Attachment links are at the end of this email ― Em 15-05-2014 16:02, Hudak, Paul escreveu: > Euterpea has what we call "clock polymorphism," with which signal > functions can be defined that are polymorphic in the sampling rate. > And there is a simple mechanism to "coerce" from one rate to another. > Phantom types are used to ensure statically that signals of different > rates cannot be accidentally mixed. > > That said, I don't know if that directly addresses the over-sampling > problem that you refer to. In particular, we can write, for example, > WAV files at different rates, but currently don't have a way to > sample real-time audio at different rates. Seems doable though. Well, even in the case of rendering an audio file you could want to render just part of the graph at a higher sample-rate (.e.g n x 44100), for instance to avoid aliasing of an oscilator with partials above 22050, allowing you to place a low pass filter and remove frequencies above 22050 before they fold back into the audible spectrum, and then you could down-sample again into 44100 (this could even be done automatically), and finally render the file at 44100. In the case of rendering a file this would keep the render times much smaller then if you would have to run the whole graph at the higher sample-rate. best, Miguel Haskell Art now contains the following file http://lurk.org/r/file/oyr1kJ99H4hVDjj0apUR3UAJ1GV-8G-2sPL8K4 Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/7B0wn3rROMeke50CVYQytF 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
Euterpea has what we call "clock polymorphism," with which signal functions can be defined that are polymorphic in the sampling rate. And there is a simple mechanism to "coerce" from one rate to another. Phantom types are used to ensure statically that signals of different rates cannot be accidentally mixed. That said, I don't know if that directly addresses the over-sampling problem that you refer to. In particular, we can write, for example, WAV files at different rates, but currently don't have a way to sample real-time audio at different rates. Seems doable though. Best,-Paul -Original Message- From: haskell-...@group.lurk.org [mailto:haskell-...@group.lurk.org] On Behalf Of Miguel Negrão Sent: Thursday, May 15, 2014 5:41 AM To: haskell-...@group.lurk.org Subject: Re: [haskell art] haskell-art] euterpea realtime? or other realtime audio in haskell ― Attachment links are at the end of this email ― Em 14-05-2014 23:45, Paul Hudak escreveu: > Miguel, thanks for your reply regarding Euterpea. Although Euterpea > works well enough for real-time MIDI, it is inadequate for doing any > substantive real-time audio. There are two problems we have faced: > (1) finding a suitable real-time audio back-end that works across > multiple platforms, and (2) optimizing arrows, on which our sound > synthesis work is based, to make them sufficiently fast. The first > problem is a technical issue that I am sure we can resolve with > enough poking around to find the right interface. The second problem > is more serious. Originally the plan was to use CCA optimization to > make arrows go fast, but our first attempt at that using Template > Haskell ran into problems (constraints placed on us by TH) that we > have not resolved. We have also tried using GHC rewrite rules, but > also ran into problems. We have even considered dropping arrows > altogether. I believe that GHC is fast enough to do real-time audio, > but the overhead of arrows is slowing things down. > > In any case, this issue has become a priority for us, and I hope that > sometime in the next six months we will have a good solution. > > Best, Paul Hudak Yale Haskell Group Hi Paul, That's good to hear, please keep us informed. Btw, just does Euterpea allow or has plans for allowing over-sampling in parts of the graph ? This would be quite helpfull to avoid aliasing. best, Miguel Haskell Art now contains the following file http://lurk.org/r/file/lQkVYCjoN4jCqJZt2e0twL4u0Aq-8G-2sPBkBQ Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/343p7eQy6Skve2jgogFFTp To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/6PxFBduhvdnZGbvLl4L6j2 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
Re: [haskell art] haskell-art] euterpea realtime? or other realtime audio in haskell
― Attachment links are at the end of this email ― Em 14-05-2014 23:45, Paul Hudak escreveu: > Miguel, thanks for your reply regarding Euterpea. Although Euterpea > works well enough for real-time MIDI, it is inadequate for doing any > substantive real-time audio. There are two problems we have faced: > (1) finding a suitable real-time audio back-end that works across > multiple platforms, and (2) optimizing arrows, on which our sound > synthesis work is based, to make them sufficiently fast. The first > problem is a technical issue that I am sure we can resolve with > enough poking around to find the right interface. The second problem > is more serious. Originally the plan was to use CCA optimization to > make arrows go fast, but our first attempt at that using Template > Haskell ran into problems (constraints placed on us by TH) that we > have not resolved. We have also tried using GHC rewrite rules, but > also ran into problems. We have even considered dropping arrows > altogether. I believe that GHC is fast enough to do real-time audio, > but the overhead of arrows is slowing things down. > > In any case, this issue has become a priority for us, and I hope that > sometime in the next six months we will have a good solution. > > Best, Paul Hudak Yale Haskell Group Hi Paul, That's good to hear, please keep us informed. Btw, just does Euterpea allow or has plans for allowing over-sampling in parts of the graph ? This would be quite helpfull to avoid aliasing. best, Miguel Haskell Art now contains the following file http://lurk.org/r/file/lQkVYCjoN4jCqJZt2e0twL4u0Aq-8G-2sPBkBQ Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/343p7eQy6Skve2jgogFFTp 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
Miguel, thanks for your reply regarding Euterpea. Although Euterpea works well enough for real-time MIDI, it is inadequate for doing any substantive real-time audio. There are two problems we have faced: (1) finding a suitable real-time audio back-end that works across multiple platforms, and (2) optimizing arrows, on which our sound synthesis work is based, to make them sufficiently fast. The first problem is a technical issue that I am sure we can resolve with enough poking around to find the right interface. The second problem is more serious. Originally the plan was to use CCA optimization to make arrows go fast, but our first attempt at that using Template Haskell ran into problems (constraints placed on us by TH) that we have not resolved. We have also tried using GHC rewrite rules, but also ran into problems. We have even considered dropping arrows altogether. I believe that GHC is fast enough to do real-time audio, but the overhead of arrows is slowing things down. In any case, this issue has become a priority for us, and I hope that sometime in the next six months we will have a good solution. Best, Paul Hudak Yale Haskell Group -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/3ATBoDGLkQ2Lck2XCJ8Rbo 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
― Attachment links are at the end of this email ― Em 13-05-2014 23:44, Ben Burdette escreveu: > So questions: > > 1) how would a reckless individual produce real time audio from > Euterpea? Yes I understand it may fail. > > 2) if someone has used euterpea in real-time, what's the complexity > level that is usable before failure occurs? > > 3) if euterpea is incapable of real time, then can anyone recommend a > noob-class haskell environment for real time audio? Hi I'll let others more knowledable then me answer about Euterpea, although last time I checked it wasn't capable of real-time audio. I look forward to the moment when that will be implemented since I think euterpea is one of the few audio patching languages I'm aware of that really advances what can be done when compared to SuperCollider, max/msp, chuck, etc. For instance the ability to make arbitrary feedback networks (no issues with sample block delay as far as I can remember), dynamic graph changes and writting ugens in a high level language are quite amazing. In the mean time I would suggest using supercollider via hsc3 and hsc3-server packages. It's quite nice to use these packages from the IHaskell interactive environment as you can then do live-coding (emacs is also an option). best, Miguel Negro Haskell Art now contains the following file http://lurk.org/r/file/ilK7VtWdPZ9vZVueDC3XnGmdJBh-8G-2sP0Vrz Name: signature.asc Type: application/pgp-signature Size: 0KB -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/3SOFTbYTsfBmc2FV3oL3Qo To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
[haskell-art] euterpea realtime? or other realtime audio in haskell
Haskell noob here. I came across the Haskell School of Music pdf online and it looks like a great way to get acquainted with the language while doing some music stuff. 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. The second part would be to receive OSC messages and generate signals in real time - sound synthesis with effects like echo, filtering, etc etc. I thought perhaps euterpea might be the way to go, but then I came across this on page 303: /Euterpea can execute some programs in real-time, but sufficiently complex// //programs require writing the result to a file. The function for achieving this// //is:// //outFile :: (AudioSample a, Clock c) ?// //String ? Double ? SigFun c () a ? IO ()// / Ok, so if synthesis is too complex, then you won't be able to do it in real time. But I don't see how to even try this. The book doesn't show a method for real time audio. Looking at IO.hs, where outFile is defined, doesn't reveal anything that seems to be 'play this signal through the speakers'. So questions: 1) how would a reckless individual produce real time audio from Euterpea? Yes I understand it may fail. 2) if someone has used euterpea in real-time, what's the complexity level that is usable before failure occurs? 3) if euterpea is incapable of real time, then can anyone recommend a noob-class haskell environment for real time audio? Thanks for any insight! Ben ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
