# FAuSt

# 1 Heist

Note: there is a name clash. This experiment is unrelated to the (later) heist package on Hackage.

Back in 2009 I wrote some type-gymnastic Haskell that embedded FAuSt’s DSP block diagram algebra in a type safe way: Heist: dataflow algebra (blog post).

In 2009 an 8-way parallel composition led to Out Of Memory (3GB limit per process on 32bit operating system), and compilation time was exponential in parallel count: Heist: busted (blog post).

In July 2023 I wrote a small .cabal file listing the dependency on tfp-0.8 (later versions changed API and won’t work), and the basic VCF example (ported from Pure-data) works fine with GHC 9.0.2.

In 2023 a 16-way parallel composition leads to OOM (on a desktop with 32GB RAM).

Probably there’s a better way to do it these days, but I don’t have the energy to rewrite it.

Source code download: heist.tar.gz.

# 2 Geist

Just a concept (“FAuSt for graphics/video”) at this stage. What if

• FAuSt’s block diagram algebra language
• GridFlow’s multidimensional array data types
• compiled via OpenCL (or Vulkan, OpenGL, …) to run on GPU

Ideally audio and video would be supportable in the same program, with data transfer between them, and the GPU would only be used for parts with large data parallelism.

Concepts like delayed and frozen arrays from Haskell GPU array libraries may be useful: each kernel should do as much as possible in one invocation, only seldom freezing to concrete memory buffers (either for efficiency, e.g. just before a graphical convolution; or when required, e.g. for temporal video feedback).

Packing multiple signals into one could be useful (like Pure-data 0.54’s snake~ object).

Packing multiple samples of a signal into one block could be useful too (like Pd’s block~ object, which defaults to 64 samples). This would require ability to handle multi-rate processes (block size 1 would be e.g. 44100 Hz, reblocked to size 64 would be 689 Hz) which AFAIK FAuSt still doesn’t support.