As it looks now: All I had to do was enable the SYN cookies feature and restart my web server. Before I enabled SYN cookies none of the requests even got to my web server (on my el cheapo vps box).
If you tried cloning the repo, and the server threw up on you, please excuse me! I have an issue with too many open fd's right now, please be patient and don't let it put you off. :)
Where is the output wave file written? Just loading the "example.lisp" file produces nothing. FWIW, I am using SBCL on OSX Lion.
Since your software is eventually about sound, having an "example.lisp" file that actually writes out a wave file for quick listening and tweaking would make it easier for first-time users to become and remain interested in your work!
You can render signals using EXPORT-WAVE and EXPORT-GRAPH. The first produces a RIFF/WAVE file, the latter Gnuplot compatible data.
I should add example renderings to the website! If I added calls to EXPORT-WAVE to examples.lisp, loading it could take pretty long depending on what is rendered on what kind of processor.
E.g. in you're case to render the final signal of the example:
(1) the function SEQUENCE had to be renamed in two places in order for this to run on SBCL.
(2) since I am using quicklisp, had to append (ql:quickload 'soundlab) to top of example.lisp for it run straight from command line via: sbcl --load example.lisp
(3) added the following to the bottom of example.lisp: (export-wave (stage-4) 30 #p"/tmp/foo.wav")
Took about a 90 seconds to render the complete wav file.
Just added the above to benefit others who may be trying to make this work.
Nice to hear that it worked out for you! Thanks for the hint on SEQUENCE, it didn't occur to me while using CCL.
90 seconds to render 30 seconds is much faster than on my computer! :)
In case you come around trying to import a WAVE file (using WAVE-SIGNALS): It does not work on all WAVE files out in the wild(yet?). Turns out reading WAVE files is much harder than writing them, because the format is specified very ambigiously. The temporary solution is to rewrite existing WAVE files using audacity for example. Audacity will produce clean WAVE files.
As of now SOUNDLAB is not tuned for performance at all. It's rather think/write/compile/listen. It's focus is on simplicity and composability. It aims to make exploring sound synthesis as simple as possble, and to be as thin of a layer between the user and the signal as possible.
It is as stated, Exploratory/experimental software.
I am not a formally educated sound engineer. So a lot of this is trial and error. The problem got very interesting very fast, and at the point where I established the signal combinator concept in SOUNDLAB, I knew I was beyond simple implementation and arrived at exploration. Because I truly can not fortell the implications of this approach. Thus this honest comment.
I shamefacedly say that this version is way out of date; I've hacked on it quite a bit more than is in the public repo, and have added things like OpenAL support (yay!).
25 comments
[ 2.9 ms ] story [ 71.1 ms ] threadRight now there is no real tutorial, but SOUNDLAB is quite usable as is. To get a grip of it, read one more multiple of: http://mr.gy/software/soundlab/lazy-signal-combinators.pdf http://mr.gy/software/soundlab/example.lisp http://mr.gy/software/soundlab/demo.pdf
Alternatively, just dive into the source. It's written in a VERY simple way.
Thank you for showing interest!
Since your software is eventually about sound, having an "example.lisp" file that actually writes out a wave file for quick listening and tweaking would make it easier for first-time users to become and remain interested in your work!
I should add example renderings to the website! If I added calls to EXPORT-WAVE to examples.lisp, loading it could take pretty long depending on what is rendered on what kind of processor.
E.g. in you're case to render the final signal of the example:
(in-package :soundlab-user)
(export-wave (stage-4) length-in-seconds #p"/path/to/foo.wav")
where length-in-seconds could be (* 2 note) to be the duration of two notes for instance. Rendering this may take a while! :)
Some other issues I faced:
(1) the function SEQUENCE had to be renamed in two places in order for this to run on SBCL.
(2) since I am using quicklisp, had to append (ql:quickload 'soundlab) to top of example.lisp for it run straight from command line via: sbcl --load example.lisp
(3) added the following to the bottom of example.lisp: (export-wave (stage-4) 30 #p"/tmp/foo.wav")
Took about a 90 seconds to render the complete wav file.
Just added the above to benefit others who may be trying to make this work.
Thanks again! Will play some more :-)
90 seconds to render 30 seconds is much faster than on my computer! :)
In case you come around trying to import a WAVE file (using WAVE-SIGNALS): It does not work on all WAVE files out in the wild(yet?). Turns out reading WAVE files is much harder than writing them, because the format is specified very ambigiously. The temporary solution is to rewrite existing WAVE files using audacity for example. Audacity will produce clean WAVE files.
As of now SOUNDLAB is not tuned for performance at all. It's rather think/write/compile/listen. It's focus is on simplicity and composability. It aims to make exploring sound synthesis as simple as possble, and to be as thin of a layer between the user and the signal as possible.
``I have no idea what I am doing. I thought I knew but boy am I lost. Still, all this appears to be something good!''
I am not a formally educated sound engineer. So a lot of this is trial and error. The problem got very interesting very fast, and at the point where I established the signal combinator concept in SOUNDLAB, I knew I was beyond simple implementation and arrived at exploration. Because I truly can not fortell the implications of this approach. Thus this honest comment.
The comment struck me, because I often feel the same!
It's both audio software yes, but Overtone is an layer on top of a (very impressive) C++ real time signal synthesis system.
SOUNDLAB on the other hand is a synthesis toolbox written from scratch, which probably consists of fewer code than the Overtone wrapper.
Edit: So, Overtone is not SOUNDLAB for Clojure. One would rather compare SOUNDLAB to Overtone's underlying SuperCollider.
I shamefacedly say that this version is way out of date; I've hacked on it quite a bit more than is in the public repo, and have added things like OpenAL support (yay!).