Re: [haskell-art] Haskell art?
On 2/23/11 1:07 PM, John Lato wrote:
SuperCollider classically was a real-time tuned Smalltalk-like
language for sound synthesis. The language allows you to do pretty
much any symbolic processing you would expect - of course some things
will be easy whereas others will be hard.
Here's the score to play a scale from Stephen Travis Pope's book
'Sound and Music Processing in SuperCollider':
defaudioout L, R; -- Declareoutputs.
deftabletabl1, env1; -- Declare2wavetables--onefor theenvelope.
start { -- Playascoreinthestart function
-- time instrument dur pitch amp
[0.00, ‘chorus_instr, 0.25, 48, 0.5].sched;
[0.25, ‘chorus_instr, 0.25, 50, 0.5].sched;
[0.50, ‘chorus_instr, 0.25, 52, 0.5].sched;
[0.75, ‘chorus_instr, 0.25, 53, 0.5].sched;
[1.00, ‘chorus_instr, 0.25, 55, 0.5].sched;
}
Score and orchestra are the same language - I'm guessing start is the
equivalent of main. SC has a GUI toolkit so you can make elements
controllable in real-time via sliders and the like.
From my (admittedly limited) experience with SC, they're the same
language only insofar as you can intermix lines with score and orchestra
control, however the orc/sco division seems alive and well. The above
code uses the score metaphor. The instrument 'chorus_instr' is created
with the orc metaphor (likely a synthdef). The supercollider server
understands both, either creating (or modifying) signal processes, or
turning them off and on, as instructed, but there are two layers of control.
It's certainly useful to be able to mix the two in the same document,
but I think there's a useful gulf between signal processing and note
scheduling.
fwiw, this distinction was introduced in supercollider 3 server around
2002 [1,2]. the synthesis server (scsynth) is a separate process from
the control language (sclang). scsynth is a DSP graph interpreter quite
similar to, but more flexible than, e.g. csound or pure data. synth
definitions, graphs of unit generators similar to csound instruments,
are sent to the server in a binary format and serve as templates that
can be instantiated and controlled through the OpenSoundControl
protocol. sclang is a smalltalk-like language with single inheritance, a
bytecode interpreter and a realtime garbage collector.
versions prior to supercollider 3 server [3] didn't have such a clear
separation between synthesis and control; language statements were
executed synchronously from within the audio interrupt, but afaik only
at buffer (or control) rate, not at the sample rate. this synchronicity
even allowed for the DSP graph to be changed in realtime on the unit
generator level, something which is not possible anymore with SC3. (i
don't have any real experience with SC2, though).
sk
[1] http://en.wikipedia.org/wiki/SuperCollider
[2] http://www.mitpressjournals.org/doi/abs/10.1162/014892602320991383
[3] http://www.audiosynth.com/icmc96paper.html
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
hi all, On 03.02.11 00:11, alex wrote: So, why not hit reply and introduce yourself (even if you've posted already), and reveal your interest in haskell and/or art, whatever that may be. I'll do it too, but someone else go first :) i stumbled over haskell about three years ago, when i was confronted with (sometimes boring) score analysis tasks at work and thought it was time to learn a new language. i've been hooked ever since and never looked back ;) these days i'm using haskell for my phd research [1], our data-driven synthesizer mescaline [2] and occasionally for sound and video installations [3]. none of this would have been possible without the amazing infrastructure and the high quality libraries the haskell community offers. i think that different (natural or computer) languages allow us to think about interesting problems differently. although i've had some previous exposure to functional programming (opal, anyone?), haskell essentially forced me to re-think my approach to programming, which, after all, turned out to be quite stimulating. sk [1] http://mtg.upf.edu/people/skersten [2] http://mescaline.puesnada.es [3] http://dissonoisex.org ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
hi john, John Lato wrote: Using unsafeFreezeIOCArray and my stream implementation provides the fastest version yet, with an average of about 1.9s per run. This is in the hsndfile.hs test code as function test1. For the record, the stream implementation and fold I'm using are copied from Data.ByteString.Lazy. I changed the types to suit this code, but that's the source. thanks for posting the code. i'm not very convinced of lazy IO, but i'd be very interested in incorporating an iteratee based approach into hsndfile. i'm currently finalizing various api changes and extensions (mostly to do with abstracting both mutable and immutable buffers) and when i'm done i'll have a look at what you did in hsoundfile-3. obviously oleg's iteratee code is not hackaged yet, and i couldn't find it anywhere else, do you have any pointers? thanks, sk ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell audio I/O packages
Henning Thielemann wrote: Thank you for this benchmark! I'm particularly interested in StorableVector because I hacked it quite a bit and use it for my own signal processing. I would also like to know how Fusion+Inlining improves the picture, but I do not know if there is anything to fuse at all in this simple example. Can you show us the actual test you run? I would then compare with my fusing signal data type from the synthesizer package. yes, thanks john, very interesting ... i'd also be interested in the benchmarking code ;) hsndfile - a recursive I/O function reads a chunk from the file (using IOCArray type) and accumulates the maximum values from each chunk. I attempted to create a framework like used for HSoundFile-3, however performance dropped dramatically; I suspect the slowdown is mostly from the process of freezing mutable arrays to immutable arrays. for CArray i've been using unsafeFreezeIOCArray, which does an O(1) conversion (simply keeping the pointer to the mutable array). For chunked data types, all data is with chunk size 1000. All timing/memory data is the median value from multiple runs. In general different runs had very similar performance. Timing results: HSoundFile-3, StorableVector - real 16.5s HSoundFile-3, UArr- real 15.7s HSoundFile-3, List - real 17.6s Is this the plain Prelude [] type? Why are List and StorableVector similar in speed? i'm curious about that one too ... sk ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
