Hi Pd devs
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 gethttp://zwizwa.be/darcs/meta
I use Pd for most of the experiments. There is a generator for Pd externs, and a "live coding" reload mechanism that can reload recompiled processing code without messing up internal state, as long as the types are compatible.
Cheers Tom
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Tom, pd-dev,
On 14/05/13 17:18, Tom Schouten wrote:
Is there anyone here interested in Functional Programming and C code generation for DSP code?
Yes! My most recent experiments are:
https://gitorious.org/maximus/tilde http://mathr.co.uk/blog/2012-12-25_clive.html http://mathr.co.uk/blog/2013-04-05_bitbreeder.html
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
What about automatic oversampling (or even undersampling?) by calculating bounds on signal bandwidth at various points in the DSP process?
- ...
Cool stuff!
What about using the same system generating GPU code (OpenGL/GLSL, OpenCL, Cuda, ...) for video DSP stuff?
[snip]
Claude - -- http://mathr.co.uk
On 05/14/2013 01:19 PM, Claude Heiland-Allen wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi Tom, pd-dev,
On 14/05/13 17:18, Tom Schouten wrote:
Is there anyone here interested in Functional Programming and C code generation for DSP code?
Yes! My most recent experiments are:
https://gitorious.org/maximus/tilde http://mathr.co.uk/blog/2012-12-25_clive.html http://mathr.co.uk/blog/2013-04-05_bitbreeder.html
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
What about automatic oversampling (or even undersampling?) by calculating bounds on signal bandwidth at various points in the DSP process?
Sure ;) This approach is opening a lot of doors for all kinds of program analysis and computer-assisted development. Though, I'm trying to get a solid base going first. The transfer functions were a nice surprise.
- ...
Cool stuff!
What about using the same system generating GPU code (OpenGL/GLSL, OpenCL, Cuda, ...) for video DSP stuff?
There you have the reason for my PDP cleanup. All these things are on my mind, but the main trouble is available time and energy at this point. I'll need to get a job soon to fund the rest of this work..
Cool stuff!
What about using the same system generating GPU code (OpenGL/GLSL, OpenCL, Cuda, ...) for video DSP stuff?
I've been far removed from that world for a while. Last time I looked there was just OpenGL with some 8-bit texture ops.
What would be a good way to start? There seems to be several non-orthogonal ways to get access to 2D graphics these days.
What I want to do is to get the image processing part of PDP to run on the GPU. Target platforms: desktop, Android, iOS, something like raspberry pi, ... Currently probably Android as first attempt.
Also, PDP is 16 bit integer pixel depth. Is that something that can be done easily these days?
On 16/05/13 16:32, Tom Schouten wrote:
What I want to do is to get the image processing part of PDP to run on the GPU. Target platforms: desktop, Android, iOS, something like raspberry pi, ... Currently probably Android as first attempt.
OpenGL ES2 is probably the best thing to target first for phones and rpi:
http://www.khronos.org/opengles/2_X/
The pdf spec seems to be quite readable.
I think ES2 is vaguely the intersection of OpenGL 2 and OpenGL 3, with some parts removed and other parts adapted to embedded systems.
There's an ARB_ES2_compatibility extension for full OpenGL, so it should be simpler to port from GLES to GL than the other way around. Plus Mesa
= 8 apparently supports GLES.
Also, PDP is 16 bit integer pixel depth.
16bit per channel or per pixel?
Is that something that can be done easily these days?
In OpenGL, yes - but OpenGL ES 2 only goes up to 8bit per channel (apart from Depth which goes up to 16bit I think) and there are some packed formats with fewer bits per channel (pages 63 and following in the spec pdf). There are probably extensions to GLES that support more stuff. Also computation is specified as "floating point with accuracy to around 1 part in 10^5", with precision modifiers for less/more accuracy/speed... Desktop OpenGL also uses mainly floating point for computation, with more storage formats (eg float textures).
Claude
On 05/17/2013 06:47 AM, Claude Heiland-Allen wrote:
On 16/05/13 16:32, Tom Schouten wrote:
What I want to do is to get the image processing part of PDP to run on the GPU. Target platforms: desktop, Android, iOS, something like raspberry pi, ... Currently probably Android as first attempt.
OpenGL ES2 is probably the best thing to target first for phones and rpi:
http://www.khronos.org/opengles/2_X/
The pdf spec seems to be quite readable.
I think ES2 is vaguely the intersection of OpenGL 2 and OpenGL 3, with some parts removed and other parts adapted to embedded systems.
There's an ARB_ES2_compatibility extension for full OpenGL, so it should be simpler to port from GLES to GL than the other way around. Plus Mesa
I see. A bottom up approach seems best then. See what is there, then see what it can be used for..
= 8 apparently supports GLES. Also, PDP is 16 bit integer pixel depth.
16bit per channel or per pixel?
Per color channel.
Is that something that can be done easily these days?
In OpenGL, yes - but OpenGL ES 2 only goes up to 8bit per channel (apart from Depth which goes up to 16bit I think) and there are some packed formats with fewer bits per channel (pages 63 and following in the spec pdf). There are probably extensions to GLES that support more stuff. Also computation is specified as "floating point with accuracy to around 1 part in 10^5", with precision modifiers for less/more accuracy/speed... Desktop OpenGL also uses mainly floating point for computation, with more storage formats (eg float textures).
That is a bit limiting.. 8 bit isn't much when you start playing with feedback. Though still possible to do something interesting I guess.
I had a look at GLSL too for GPGPU computation using the pixel shaders. I think I get the point now, but it sure isn't straightforward to work with!
Porting the RAI C code gen stuff to create shader kernels seems quite straightforward.
However, the texture juggling for composing multiple shader programs when the memory access can't be parallellized is something that would require some new approaches.
Apart from image processing, I can see this have some application for generating complex dynamic wavetable synths (i.e. scanned synthesis).
Btw, Tom, great to see you back in Pure Data business! gr~~~
-- Thomas Grill http://grrrr.org
Am 14.05.2013 um 18:18 schrieb Tom Schouten:
Hi Pd devs
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 gethttp://zwizwa.be/darcs/meta
I use Pd for most of the experiments. There is a generator for Pd externs, and a "live coding" reload mechanism that can reload recompiled processing code without messing up internal state, as long as the types are compatible.
Cheers Tom
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Here's a little illustration: http://zwizwa.be/rai/rai.html
( Racket's documentation facility is really nice. )
On 05/14/2013 12:18 PM, Tom Schouten wrote:
Hi Pd devs
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 gethttp://zwizwa.be/darcs/meta
I use Pd for most of the experiments. There is a generator for Pd externs, and a "live coding" reload mechanism that can reload recompiled processing code without messing up internal state, as long as the types are compatible.
Cheers Tom
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Hi Pd devs,
been cleaning it up a bit. still quite raw in the details, but it basically works.
added synth-lib.rkt basic synth kit and synth.rkt example synthesizer:
- envelopes - parameter control dezippers - parameter control scales (exponential, "squashed" exponential, ...) - SVF filter - supersaw osc - anti-aliased saw osc - saturation functions - FDN reverb tail
How I use it at this time, Linux + Pd:
make sp_host.pd_linux # build binary Pd wrapper pd sp_test.pd & # run Pd patch built around sp_host make livecode # continuously compile synth.rkt -> synth.sp binary module
then edit synth.rkt or any of its dependencies and the binary code running in Pd will be updated, leaving state intact if the type didn't change.
some docs at http://zwizwa.be/rai
For headless Windows VST plugin: "make synth.dll" This needs a Linux->Windows cross compiler; follow the error messages.
Cheers Tom
On 05/14/2013 12:18 PM, Tom Schouten wrote:
Hi Pd devs
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 gethttp://zwizwa.be/darcs/meta
I use Pd for most of the experiments. There is a generator for Pd externs, and a "live coding" reload mechanism that can reload recompiled processing code without messing up internal state, as long as the types are compatible.
Cheers Tom
Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
-
Claude Heiland-Allen -
Thomas Grill -
Tom Schouten