Re: [music-dsp] Functional Programming C code generation
Here's a little illustration: http://zwizwa.be/rai/rai.html ( Racket's documentation facility is really nice. ) On 05/14/2013 12:11 PM, Tom Schouten wrote: Is there anyone here interested in Functional Programming and C code generation for DSP code? I'm working on a system for DSP code development based on the principle of Abstract Interpretation http://en.wikipedia.org/wiki/Abstract_interpretation Basically, it will allow several interpretations of a single specification program: - specification as a pure functional program - imperative C code generation (for passing to C compiler or LLVM) - Z transform for frequency plots of (linearized) transfer function - automatic differentiation for all kinds of derivative-based tricks - ... It is written in Racket http://racket-lang.org/ It's starting to get to a point where it is actually useful (there is a basic synth core) and could use some feedback, but please note it is very experimental and still needs a lot of work. Familiarity with Racket is probably a prerequisite at this point to make sense of it. Current code is here: http://zwizwa.be/darcs/meta/rai/ It is part of a darcs archive that can be fetched using darcs get http://zwizwa.be/darcs/meta -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
On 05/15/2013 04:54 AM, Jamie Bullock wrote: On 15 May 2013, at 00:42, Tom Schoutent...@zwizwa.be wrote: Faust is amazing. it can compile to many different end targets and even has it's own IDE in FaustWorks. Also, Albert Graf has embedded it (of sorts) into Pd already (via Pure). very powerful combo. the language itself is a little mathematical, finicky and technically minded though. I really like the idea behind Faust, and I made sure that this idea can be used on top of what I am writing. Faust is already a stateless operator/combinator language, so very close to what I have in mind. That combinator approach used in Faust can work well for high level composition, though after working a lot with such style of languages (though more Forth-like) I no longer think combinators are a good basic substrate for low-level work. They can be very powerful and succinct, but are indeed finicky to work with, and produce hard to read code. Overall I prefer a more direct applicative style ie. named variables for input and possibly output. If you don't like FAUST's functional semantics, there is also Poing Impératif https://github.com/kmatheussen/poing-imperatif Paper: http://users.notam02.no/~kjetism/poingimp_lac2011.pdf Thanks for the link. Seems a lot of interesting things happening in Faust land since I last looked. Maybe to clarify a bit, since I do not want the point to be missed that I like the functional semantics. That part is a really great idea. I'm saying that instead of process1 = +, i prefer process2(a,b) = a + b, meaning explicitly named variables. It's easier to build process1 style notation on top of process2 style, instead of the other way around: it's easier to drop local variables than to re-introduce them. The process1 approach works well and can be very powerful once things are properly abstracted, but when you are working with low-level issues like approximation, interpolation, ... there tend to be more magic parameters involved, which is harder to work with if you have to implicitly keep track of where they are at. Similar to stack juggling in Forth-like languages. However, it seems use of local variables is possible in Faust using the with form so I'm not sure to what extent my process1/2 remark actually matters. It does seem possible to have the best of both worlds in Faust. Is with in Faust a recent addition, or was it there from the start? Tom -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
On 05/14/2013 11:12 PM, Alan Wolfe wrote: fwiw, i have a DAW I work on, and on my todo list is the ability to export your creations to C++. what DAW is that? One option would do generic C++ so you could drop it into whatever program you wanted (like, an fmod callback, or custom code etc). The other option to be generating code for a VST plugin. Just wanted to mention it because as you probably know... a lot of people have the same good ideas, but fewer people actually bring them to fruition (: yes, it's a lot of work to make everything fit well. code gen is one of those areas where good design pays off. it can get unwieldy very fast. and good design takes time and often many attempts.. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
[music-dsp] Functional Programming C code generation
Is there anyone here interested in Functional Programming and C code generation for DSP code? I'm working on a system for DSP code development based on the principle of Abstract Interpretation http://en.wikipedia.org/wiki/Abstract_interpretation Basically, it will allow several interpretations of a single specification program: - specification as a pure functional program - imperative C code generation (for passing to C compiler or LLVM) - Z transform for frequency plots of (linearized) transfer function - automatic differentiation for all kinds of derivative-based tricks - ... It is written in Racket http://racket-lang.org/ It's starting to get to a point where it is actually useful (there is a basic synth core) and could use some feedback, but please note it is very experimental and still needs a lot of work. Familiarity with Racket is probably a prerequisite at this point to make sense of it. Current code is here: http://zwizwa.be/darcs/meta/rai/ It is part of a darcs archive that can be fetched using darcs get http://zwizwa.be/darcs/meta -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
On 05/14/2013 12:17 PM, Rohit Agarwal wrote: Good choice of project. A generatively programmed codebase get's more powerful for the programmer over time. The beginning is the slower and more difficult part. This approach to programming holds great promise. Indeed. Moreover, there is a lot to be discovered in the combination of recent developments in FP-based code generation and domains such as DSP which have an inherent mathematical function structure, and particularly music DSP where feedback systems are such a central idea. Often, state gets in the way in feedback systems, and people turn to OO techiques. There are other approaches. While stateful at the sample level, feedback systems are stateless pure functions at the stream level, which is the basic idea behind this project. This view opens up a lot of doors. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
On 05/14/2013 12:44 PM, Jeremy Shaw wrote: Interested -- yes. Time to do anything -- no. But, I have long thought it would be interesting to implement a virtual modular synth that was compiled on the fly. The UI would be written in high-level Haskell, and would allow you to manipulate the synth, patching cables, tweaking knobs, etc. When you repatched the cables, added new components, etc, it would generate new optimized assembly for that new synth configuration. This would, hopefully, allow the developer to continue working in a high-level, type-safe language, but get Haskell out of the real-time loop. Mostly because the garbage collector and real-time do not get along. No idea if your work is applicable to this or not. But, it is a direction I would love to see explored. Yes it is almost directly applicable, and it's also on my no time yet list to do this for Pd :) Input syntax at this point is s-expressions, because that's easiest to do, and because I find textual development to be a bit more easy to use than GUI when things get down to low level structures. Making a wrapper for Pd objects is relatively trivial. Making this work for a pretty gui is a little more work, but on the language side probably the same complexity as getting it to work in Pd. A Pd implementation could serve as an example. Btw, I started out the previous version of this system in Haskell, but got stuck on the steep learning curve. Current state is here: http://zwizwa.be/darcs/meta/dspm/ Doing that first has helped a lot in figuring out the basic structure. A good way of cleaning up a design is to try to implement it in Haskell :) -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Functional Programming C code generation
On 05/14/2013 04:30 PM, pdowling wrote: i'm presuming everyone in this thread knows Grame's FAUST and Cycling 74's GEN ? or maybe i'm missing something about what you want to do? if so apologies. i'm actually just very interested in this subject myself. surely the first step would be to appraise two of the excellent solutions already out there? I'm not familiar with GEN, though I am aware there are already a load of code generators available. Some open source, some not so open. Faust is amazing. it can compile to many different end targets and even has it's own IDE in FaustWorks. Also, Albert Graf has embedded it (of sorts) into Pd already (via Pure). very powerful combo. the language itself is a little mathematical, finicky and technically minded though. I really like the idea behind Faust, and I made sure that this idea can be used on top of what I am writing. Faust is already a stateless operator/combinator language, so very close to what I have in mind. That combinator approach used in Faust can work well for high level composition, though after working a lot with such style of languages (though more Forth-like) I no longer think combinators are a good basic substrate for low-level work. They can be very powerful and succinct, but are indeed finicky to work with, and produce hard to read code. Overall I prefer a more direct applicative style ie. named variables for input and possibly output. The point of the project is not so much to make a graphical design language. It is to go a bit deeper and find a simple basic substrate for coding DSP algorithms (and other arithmetic-intensive code). To take the central idea of different interpretations of the code and make it accessible to a broader public of designers/implementers of DSP code. It is definitely a bit technically minded. Maybe a bit too technical. What I like to find out is in how far my exposure to these ideas made my idea of common sense shift (I have a DSP background originally but got exposed to FP at a later time). I.e. can this approach benefit others? Can the specific implementation I'm using be somehow shifted more into the main stream? What am I (needlessly) re-inventing and what is new? Are there points of integration with other systems? Lot's of questions still. The basic substrate here is the lambda-calculus (a fancy name for the process of building everything out of stateless operations). Everything that can go on top (graphical interface, other combination languages, ...) is not essential from my current pov, but it should definitely not be hindered. Gen (and GenExpr) allows for graphically patching and/or using a clean scripting language (based on top of lua but with a syntax more like C / javascript) to jit compile to machine code in real time whilst the audio stream is running. click a button and you get optimised C++ code. both much like what jeremy shaw mentioned wishing in his post. by the way, Grame have also produced faustgen~, an LLVM object implementation of Faust for working in Max also. Gen also has the advantage of being a generic language, not just a DSP one. can comiple to GPU pixel shader GLSL code equally easilly, for example. i know many DSP/VST coders who now use these environments as their main prototyping jumping off point (not me, i'm just a vaguely creative hacker). just thought i'd mention it all for the sake of the discussion. Looks like I need to give GEN a try. Probably good a source of inspiration. -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
Re: [music-dsp] Starting From The Ground Up
Hi Jeff, Apart from learning C/C++ and digging through things like the VST SDK, I would recommend taking a look at Pd. http://crca.ucsd.edu/~msp/software.html It's quite a fun system in itself, but as a bootstrapping environment for incremental development of C/C++ audio effect and synth plugins, it is awesome. Cheers, Tom On 01/21/2013 11:49 AM, Jeffrey Small wrote: Hello, I'm a recently new computer programmer that is interested in getting into the world of Audio Plug Ins. I have a degree in Recording/Music, as well as a degree in Applied Mathematics. How would you recommend that I start learning how to program for audio from the ground up? I bought a handful of textbooks that all have to do with audio programming, but I was wondering what your recommendations are? Thanks, Jeff -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp -- dupswapdrop -- the music-dsp mailing list and website: subscription info, FAQ, source code archive, list archive, book reviews, dsp links http://music.columbia.edu/cmc/music-dsp http://music.columbia.edu/mailman/listinfo/music-dsp
