[haskell-art] real-time sound synthesis (Was: Haskell live sequencing)

[Henning Thielemann]

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] real-time sound synthesis (Was: Haskell live sequencing)

[Henning Thielemann]

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