Re: [LAD] Prototyping algorithms and ideas

On Thu, 24 Jan 2008, Albert Graef wrote:

> Kjetil S. Matheussen wrote:
>> If you _really_ like functional programming and aren't
>> afraid to learn a really different syntax, faust might probably
>> be a very good alternative. I don't think you'll get the kind of tight
>> interactive development environment with it as the other systems
>> though. ie. you have to write code, compile up, run test, etc.,
>> while in the other systems, you can just write code and test directly.
>
> That's true, I'm the first one to admit that as I already use the
> Faust/Pd combination in courses, and the students complain about this
> all the time. ;-) We definitely need to work on that. This might need
> some cooperation from Pd (right now, Pd doesn't seem to like reloading
> externals on the fly, at least I haven't figured that out yet).
>
> The Pd/Q interface works much better in that respect since it already
> allows hot-swapping the running Q script, and you can trigger that,
> e.g., from Emacs. A similar trick could be done with Faust plugins, too,
> by making a generic Faust external which just acts as a container, and
> loads the real plugin on its own behalf.
>
> CLAM is supposed to offer nice Faust integration (via LADSPA) already,
> but I haven't tried it yet. I'm looking forward to use that combination
> in one of my next audio programming courses, though.
>
> CLM and snd are also nice for prototyping purposes, of course, as are
> all the others mentioned in this thread. But for me the special thing
> about Faust is that it's purely functional to boot and has a formal
> semantics. Your programs read like mathematical specifications, and
> that's what they are. I won't even mention the expression syntax, as I
> don't want to invite the 5625342th parens-versus-infix flamefest. Oops,
> now I did it. :)
>
> Faust isn't perfect either. For one thing, it still lacks multirate
> processing. And my pet peeve: the lack of a unary minus operator. ;-)
>
> What an interesting thread. Keep it going. :)
>

Okay. :-)

The second problem (besides its lack of interactivity) I have about faust
is that is purely functional. I have programmed lots of code in purely
functional style, and I like it very much, so thats not the issue. But, I
feel that being forced to work in one paradigm gives me less
possibilities.

For example, when I made the san dysth softsynth,
I thought in imperative terms, a sort of state machine where a set of
variables change value for each sample. In an imperative languages, its
straight forward to make such a routine, but in purely functional
languages the code must be transformed first. And doing that
tranformation can be very hard, even impossible, if you quite don't
know how your dsp function is supposed to work yet.

When I actually implemented san dysth,
I did a lot of trying and failing before eventually getting something
which sounded somewhat okay. Its not a great synth
mathematic-vice, and I don't know very well what I'm doing regarding
signal processing. But if I hadn't had a programming environment
which supports imperative operators, there would most likely
never have been a san dysth softsynth at all. So I may think that for a
person who have a more experimental approach to signal processing,
faust isn't a good choice, at least not for prototyping.

Well, after being finished writing the softh synth I made block diagrams
of the signal processing routine:
http://www.notam02.no/~kjetism/sandysth/ so I would probably not
have that much a problem writing san dysth in faust now. But the
original implementation worked (and still works) like this:

"
func get_one_sample:
   if val <= -1
     inc_addval=true
   elseif val <= 1
     inc_addval = false
   elseif addval > max-add-val
     periodcounter = period
     inc_addval = false
   elseif addval < -max-add-val
     periodcounter = period
     inc_addval = true
   elseif 0 == (--periodcounter)
     periodcounter = period
     inc_addval = not inc_addval

   drunk-change = random( max-drunk-change )
   addval = filter( das_filter, inc-addval == true
                                ? drunk-change
                                : -drunk-change
                  )
   val += addval
   return val

out( vol * src( sr, rate, get_one_sample) )
"

("src" is a resampler function)

It would be interesting to see how the routine would
look like in faust, if you have the time. :-)
(I think it should be a straight forward job though
when looking at the block diagrams on the san dysth
homepage.)
_______________________________________________
Linux-audio-dev mailing list
Linux-audio-dev@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-dev
Received on Mon Jan 28 00:15:02 2008