[haskell art] [ANN] hsc3-server 0.9.2 bugfix release
hi all, in response to the recent release of hsc3 0.15 here's a bugfix release of hsc3-server: http://hackage.haskell.org/package/hsc3-server thanks + best, stefan -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/185YGPbj6KqSUr3LvhiD2d To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
[haskell-art] [ANN] hsndfile 0.7
I am happy to announce version 0.7 of hsndfile [1], a set of Haskell bindings to the venerable libsndfile library. This release is a bugfix and maintenance release, thanks to Roman Cheplyaka for his contributions! Changes since 0.6 [3]: * Read and write signed instead of unsigned integer samples and rename `sf_readf_wordXX` and `sf_writef_wordXX` to `sf_readf_intXX` and `sf_writef_intXX`, respectively * Add new supported header and sample formats Have fun, sk [1] http://hackage.haskell.org/package/hsndfile [2] http://www.mega-nerd.com/libsndfile/ [3] https://github.com/kaoskorobase/hsndfile/blob/master/ChangeLog.md ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] draw 2D pixel array
On 27 Feb 2013, at 18:13, Miguel Negrao wrote: > I know diagrams but it is more suited for working with primitives then with > direct pixel manipulation. I already have some opengl experience in Haskell, > but since it’s for 3D stuff I assumed it would be overkill. Would the Haskell > SDL bindings be a better option then opengl, or should I go with opengl ? i don't have experience with the SDL bindings, but with opengl it's just a matter of configuring the projection for 2D, right? sk ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] draw 2D pixel array
hi miguel, On 27 Feb 2013, at 13:07, Miguel Negrao wrote: > I would like to draw in Haskel simulations of turing patterns, cellular > automata, etc. Basically I will only need to take an array of pixels and draw > it to the screen directly. What is the best Haskel graphic library and > functions to do this ? i've been using diagrams [1] lately --there's also an animation package [2]-- but maybe it's too slow for realtime. imo opengl would be a good option if you're already familiar with it ... sk [1] http://projects.haskell.org/diagrams/ [2] http://hackage.haskell.org/package/active ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] ANN: hsc3-process-0.8 and hsc3-server 0.5
I am happy to announce the release of version 0.8 of hsc3-process [1] and version 0.5 of hsc3-server [2], both providing additional features and abstractions for the excellent hsc3 interface [3] to the SuperCollider synthesis server [4]. hsc3-process allows to start external scsynth processes and run actions that communicate through the associated OpenSoundControl transport. hsc3-server builds on hsc3 and hsc3-process and adds the following features: * A `Server' monad for accessing synthesis server state from concurrent threads, * Resource ID allocators for nodes, buffers and buses, * A composable `Request' abstraction that allows to assemble synchronous and asynchronous server commands into OpenSoundControl bundles for efficient scheduling, * A type-safe interface to the SuperCollider synthesis server command set. hsc3-server has been in use internally for some time but this is the first release that is ready for consumption by the general public. Have a look at some examples here [5]. Any feedback welcome! Happy synthesis! [1] http://hackage.haskell.org/package/hsc3-process [2] http://hackage.haskell.org/package/hsc3-server [3] http://hackage.haskell.org/package/hsc3 [4] http://supercollider.sourceforge.net/ [5] https://github.com/kaoskorobase/hsc3-server/tree/master/examples ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Livecoding in Haskell like Chuck/Impromptu/Overtone?
On 31.07.12 20:28, Al Matthews wrote: > I'm also wondering what has become of > https://github.com/kaoskorobase/mescaline . oh, the project's not dead, just scheduled right behind a number of more urgent things ;) note that mescaline's scope is not a general purpose audio signal processing environment. we're using supercollider because our needs are limited and it fits the bill. eventually it will be replaced by a custom audio engine based on faust. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
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).
[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. [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] hsndfile
hi john,
On 22.09.10 13:14, John Lato wrote:
> > Now it works and reports the proper answer, but when I run the program
> with
> +RTS
> > -s it shows low memory usage. Very low.
> >
> > 40,488 bytes allocated in the heap
> >1,484 bytes copied during GC
> >6,124 bytes maximum residency (1 sample(s))
> > 14,356 bytes maximum slop
> >1 MB total memory in use (0 MB lost due to fragmentation)
> >
> > However, the system monitor shows that the program is occupying about
> 230MB of
> > RAM. For my test file the this program reports:
> >
> > Info {frames = 17479453, samplerate = 44100, channels = 2, format =
> Format
> > {headerFormat = HeaderFormatWav, sampleFormat = SampleFormatPcm16,
> endianFormat
> > = EndianFile}, sections = 1, seekable = True}
> >
> > so 230MB seems consistent with allocating a single vector of Doubles.
> >
> > So my second question is, why is this memory usage not reported by +RTS
> -s,
> or -hT?
>
> i'm not sure either, maybe because the memory is allocated on the heap by
> malloc? this might indicate a memory leak, i'll investigate. i'm
> currently on
> the road and won't have the time to look into the problem before sunday
> ...
>
>
> I'll try asking on haskell-cafe, maybe somebody there will know.It's not at
> all
> urgent, so whenever you get a chance to look at it is fine by me. I doubt
> it's
> a memory leak in any case.
could you try the new version in the darcs repository
darcs get http://code.haskell.org/hsndfile
?
i think i've fixed a memory leak (there was a finalizer missing from the memory
allocated with mallocBytes) and i've also removed the lazy read functions from
the interface.
thanks + bst,
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] hsndfile
hi john,
On 22.09.10 11:37, John Lato wrote:
> Initially I tried using readFileChunks, but I never got any data from it. The
> info would print out, but the calculation of the maximum value would be 0
> because "chunks" would be an empty list. I tried using several different
> numbers for the first argument to readFileChunks, such as 1, 2, 8, and 1024
> (is
> it the number of frames to read?), but always received an empty list. Could
> any
> point me to what I'm doing wrong? This is with ghc-6.12.1.
you're not doing anything wrong; i think the reason is that the way readChunks
is implemented the file handle is closed prematurely. this function needs to be
removed from the interface.
> Now it works and reports the proper answer, but when I run the program with
> +RTS
> -s it shows low memory usage. Very low.
>
> 40,488 bytes allocated in the heap
>1,484 bytes copied during GC
>6,124 bytes maximum residency (1 sample(s))
> 14,356 bytes maximum slop
>1 MB total memory in use (0 MB lost due to fragmentation)
>
> However, the system monitor shows that the program is occupying about 230MB of
> RAM. For my test file the this program reports:
>
> Info {frames = 17479453, samplerate = 44100, channels = 2, format = Format
> {headerFormat = HeaderFormatWav, sampleFormat = SampleFormatPcm16,
> endianFormat
> = EndianFile}, sections = 1, seekable = True}
>
> so 230MB seems consistent with allocating a single vector of Doubles.
>
> So my second question is, why is this memory usage not reported by +RTS -s,
> or -hT?
i'm not sure either, maybe because the memory is allocated on the heap by
malloc? this might indicate a memory leak, i'll investigate. i'm currently on
the road and won't have the time to look into the problem before sunday ...
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] ANN: hsndfile 0.4
i'm pleased to announce version 0.4 of hsndfile [1], a haskell interface to libsndfile [2]. in version 0.4 the buffer i/o interface has been simplified and instances for i/o based on the vector package [3] is provided by hsndfile-vector [4]. enjoy! [1] http://haskell.org/haskellwiki/Hsndfile [2] http://www.mega-nerd.com/libsndfile/ [3] http://hackage.haskell.org/package/vector [4] http://hackage.haskell.org/package/hsndfile-vector ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Sound.SC3 and trig controls?
Rohan Drape wrote: >> i was thinking that DR could be abused for this >> purpose, i.e. control DR "myTrig" 0 would construct a >> trigger control (DR isn't used by Control yet, is >> it?). > > no, & it's hard to imagine it ever would be, but... > > i think tr_control is ok? sure! fine with me ... >> i personally don't care too much about the "t_" >> prefix, so if you're not intending to use it, i'd >> suggest to leave this mildly error-prone "convention" >> away ;) > > personally no, i'd not use it, but on the other hand > writing "t_" for non-trigger controls'd be pretty > confusing as well?! yeah well, but only for readers of your code that know sclang ;) all i'm saying is that these kinds of shortcuts might be an invitation for bugs that can be hard to find. bst, ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Sound.SC3 and trig controls?
hi rohan + list, Rohan Drape wrote: >> i've been wondering how to create "trigger" synthdef >> controls > > you couldn't, however as of today there is an initial > implementation pass with examples in the tutorial file. > > it is not well tested yet. and it pushes all four > types of control ugens into the graph regardless of how > many you actually use. (ie. a minor optimisation > issue.) thanks a lot! i'll check it out ... > short instructions: darcs pull & use either the > 'tr_control' function with any parameter name you like, > or, if you must, the 'control' function with a "t_" > prefixed parameter name. i was thinking that DR could be abused for this purpose, i.e. control DR "myTrig" 0 would construct a trigger control (DR isn't used by Control yet, is it?). i personally don't care too much about the "t_" prefix, so if you're not intending to use it, i'd suggest to leave this mildly error-prone "convention" away ;) thanks again, ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Sound.SC3 and trig controls?
hola,
i've been wondering how to create "trigger" synthdef controls, i.e. ones that
are reset to zero immediately after they've been set and which are introduced in
SC SynthDefs by special argument names ("t_something") or a rate argument to the
SynthDef (\tr). there is trigControl, but it's not obvious how it is to be used.
any hints?
thanks,
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Sound.SC3.Lang.Pattern and external events
hi rohan, Rohan Drape wrote: >> that was exactly what i was about to do ... what was >> the problem with this approach? > > it is some time ago, however i imagine the problem was > that connecting a (P s1 a) graph with a (P s2 a) graph > is a nuisance. the simplicity of being able to connect > any (P a) to any other (P a) is part of the 'charm' of > the system... hmm, yes, that might turn out to be a problem, but i'll have to experiment a little first. in a particular use case i have there's only ever going to be pattern graphs of the same type, so i'll try how far i get. >> i would think that if step were exposed in the >> interface, i could pass in a new state for each value >> produced by the pattern; a hypothetic `pask' would >> return the current state (or rather environment; it's >> not changed by the patterns). > > i think i concluded that what'd be best is to extend > the internal state from simply StdGen to perhaps > something like: > > data PState = PState StdGen Control.Concurrent.Chan > > and provide some way for users to access the channel. > this'd allow external asnchronous communication but > require it to go through a common representation, > maintaining the simple and interconnectable (P a) type > signature. but you still would need to expose the type of the channel elements in P, wouldn't you? also, patterns then wouldn't represent pure computations anymore. >> what do you mean by plain haskell, lazy lists? i'm >> having trouble imagining how i could deal with >> asynchronous events, but that's probably just my lack >> of imagination ;) > > actually Control.Concurrent.Chan.getChanContents works > suprisingly well! but no, i just meant using the > standard Control.Concurrent libraries and writing for > the 'specific case' - ie. no 'frameworks'! i see what you mean; my goal atm is to have some kind of DSL that can be taught to non-programmers, and based on my experiences with the SC pattern system, i wanted to give yours a try. > i guess it'd need to somehow support at least the most > useful of the various 'merging' rules, also blocking > and non-blocking external reads (ie. pause pattern > until data available, or provide cached data) etc. yes, in my view this is one of the major shortcomings of the SC pattern system: events are not first class, but are so to speak implicitly present by injecting them into a pattern graph by an impure driver function, yielding one event per input event. for blocking reads for example, it's possible to write a new driver function, but running pattern graphs (on different drivers) cannot easily communicate and exchange events. it woud be interesting to hear the opinion (or even success stories) of others on this list, because i know some have been very active in FRP research ;) > http://lambda-the-ultimate.org/node/3659 looks > promising, but these systems often 'look promising'! interesting read indeed, thanks for the pointer! ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Supercollider : Installing an Instrument to A Channel
Julian Rohrhuber wrote: > Well, theoretically, scsynth couls supply a client with free node > ids, but this would require a round trip for each synth. Considering > that ids may be used at a rate appropriate to granular synthesis, > this makes not too much sense. but usually when doing granular synthesis you won't need to modify the grains individually after they've been started, so you normally use -1 as a node id anyway. > What you do in sclang normally is to > give each client a unique integer id and divide up the integer id > space into the maximal number of clients (I think it is 32 in sclang > currently), providing each client with their own id range. a possibly interesting solution --not only for node ids-- would be to use universally unique identifiers (UUID, [1]), which are basically 128 bit hashes. they could be generated on each node without any need for communication. i'm wondering how high the probability of hash collision would be in a realistic scenario, and how clashes could be resolved. of course this would require quite a lot of architectural changes in scsynth and sclang ... [1] http://en.wikipedia.org/wiki/Universally_Unique_Identifier ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Sound.SC3.Lang.Pattern and external events
hola rohan, all, i was wondering how to inject events from external sources (controllers, etc.) into a pattern. i was about to extend P with an environment parameter that can be modified between 'step' invocations, but maybe there's a better (existing) way to accomplish this. any thoughts? thanks, ___ 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: > What are the reasons, you do not like lazy IO? i guess the biggest issue is when it is safe to release resources. i think a safe paradigm would abstract timely allocation and release of resources; at which point you need to "consume" your whole lazy stream of data and arrive at an abstraction similar to streams + foldl' or iteratees. oleg's paper lists more benefits like improved performance and robustness wrt deadlocks, but i haven't really checked it out yet. > But in general I find lazy stream processing a very elegant > way of programming. recently i've been working with a framework closer to the notion of stream processors rather than working on streams themselves, with the main motivation of being able to use the same algorithms in a non realtime setting (soundfile IO) and in a realtime, callback-based framework (e.g. coreaudio or jack). i'm not sure how lazy streams would be used in such an environment without additional buffering, are you doing this in your synthesizer package? > Why else should we use Haskell and not, say OCaml? because there are far more good uses for lazyness than "just" stream processing ... plus, haskell is way cooler than ocaml ;) ___ 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, ___ 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 ... ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
