27 Jan
2008
27 Jan
'08
2:45 p.m.
On Thu, 24 Jan 2008, Albert Graef wrote:
Kjetil S. Matheussen wrote:
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.)
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. :)