Re: [haskell art] SCHelp parser?
Hi Tom If no-one has one already I'd be up for writing one. The new developments with Haskell and SuperCollider (your system and Super Dirt) are pretty exciting and I've been thinking I ought to get involved. Best wishes Stephen On 4 April 2016 at 08:03, wrote: > Does anyone have a Haskell parser laying around for supercollider's .schelp > files? > > Thanks! > Tom > -- > > Read the whole topic here: Haskell Art: > http://lurk.org/r/topic/AKSKbQ1R16C2KjuzJqWrH > > To leave Haskell Art, email haskell-...@group.lurk.org with the following > email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/67gCZf2tVskY5rb15U64cS To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] Paul Hudak
It's very sad news that Paul Hudak has died. I remember pre-ordering The Haskell School of Expression from my local Waterstones and being genuinely excited about its arrival - here was a book that meshed both functional programming and multimedia - wow!. As it happens college work (and some confusion with Hugs) got in the way of me learning Haskell and it was another three years before I read the book properly. As a reference, it's been near the top of my pile programming books ever since - the simple model of reactive functional programming it presents is the most illustrative I've seen. Reading the notices for Paul's death was very sad but also heartening. As I didn't know Paul personally (only through this list) I didn't know had hard his continuing struggle with leukemia had been. I knew he had treatment 5 years ago, but as he resumed work on Euterpea and The Haskell School of Music and returned to generously contributing to this list one hoped his treatment had gone well. But it was greatly heartening that his generosity was was very large and not limited - he clearly had made an exceptional contribution to Yale and the wider academic world, not just as a researcher and co-creator of Haskell (which we know about on here) but as Master of his college and an inspiration to his students. Condolences to his family and friends. Stephen On 1 May 2015 at 21:33, alex wrote: > Dear all, > > Lets feel for the family and friends of Paul Hudak, who sadly died on > Wednesday after a long battle with Leukemia. > > Paul has surely contributed more to the Haskell Art community than anyone, > e.g. writing the Haskell School of Expression, the Haskell School of Music, > Euterpea, his contributions to Functional Reactive Programming, in > co-founding and chairing the ACM SIGPLAN workshop on Functional Art, Music, > Modelling and Design, and of course in helping make Haskell itself in the > first place. As a relative outsider to the Haskell community, I can only > understate his achievements here, I hope no-one minds. > > I'll look forward to celebrating his life by reading, enjoying and benefiting > from all he has left. > > Best wishes, > > alex > -- > > Read the whole topic here: Haskell Art: > http://lurk.org/r/topic/TLwToB0X1TBx3019CaeBt > > To leave Haskell Art, email haskell-...@group.lurk.org with the following > email subject: unsubscribe -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/2RGmdAnWcWHvYDX6cHlJnb To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell art] haskell in several upcoming live performances in the UK
Hi Renick Excellent - I'll definitely go along to the Leeds night, though as an "out-of-towner" I'll have to leave before the end to get a train home. Do you know the running order yet? Thanks Stephen -- Read the whole topic here: Haskell Art: http://lurk.org/r/topic/B8fIDfP0bnGaTUJr9TpGW To leave Haskell Art, email haskell-...@group.lurk.org with the following email subject: unsubscribe
Re: [haskell-art] CFP: Workshop on Functional Art, Music, Modelling and Design (FARM)
Hi Alex and Henrik and Michael Thanks for continuing the FARM workshop this year, it's a great initiative to fly the flag for FP in creative areas. Thanks as well to Paul, Conal and Brent for their work on last years workshop. On 28 February 2014 00:08, alex wrote: > FARM 2014 > > 2nd ACM SIGPLAN International Workshop on Functional Art, Music, > Modelling and Design > > Gothenburg, Sweden; 6 September, 2014 > > http://functional-art.org [Snip] ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)
Hi Evan Maybe there is something to be mined from the "OM-Chroma" research at IRCAM? http://repmus.ircam.fr/cao/omchroma It looks like they are using different timing resolutions to get expressive control of "synthesizers" - in this case via Csound. Best wishes and Happy New Year to everyone on the list. Stephen On 28 December 2013 01:29, Evan Laforge wrote: > Do you know of any existing work along these lines, especially on the > practical side? It seems like an obvious direction to go in once you > start thinking about how the structure of music works along with > notation and performance, so surely lots of people have thought of it. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)
Hi Evan [Comments inline... ] On 19 December 2013 03:52, Evan Laforge wrote: > On Fri, Dec 13, 2013 at 11:44 PM, Stephen Tetley > wrote: >> Hi Evan >> >> Ha, though miles away from being ready for public consumption my own >> "tower of DSLs" built over Csound gained symbolic notes, chords, >> trills and "Solo Parts" this week. Hopefully arpeggios, tremolos and >> more should follow soon. > > I assume this is the "Lirio" program you mentioned a while back? At > the time I recall you were mostly programmatically generating lilypond > scores, but I suppose even so you still need a way to describe the > higher level structures. The new score language is called Majalan after Michael Tenzer's book and targets just Csound sco files - Lirio is out to pasture at the moment. Grace notes didn't work well in my new score language - so I'm back to the drawing board. > By the way, back then you mentioned something I meant to respond to: > >> where chord transformations can be easily encoded[1] and a nice model >> of gamelan melodies in Michael Tenzer's book "Gamelan Gong Keybar". > > I was curious about that, because I too have that book. I remember > getting a little lost in that section, but also wondering what the > practical purpose of all this reduction to "normal forms" was. > Perhaps you have come up with such a practical purpose, though I still > don't fully understand it :) I've started to implement a few concepts > from Balinese music, but mostly restricted to concrete things like > performance techniques, idiomatic derivation (e.g. reyong kilitan), > and "arrival" oriented rhythm, where notes are written at the end of > their duration rather than the beginning. I like the simplicity of Michael Tenzer's model - it helps that he doesn't have to account for differing note durations due to gamelan orchestras being largely made of percussion instruments. I never got further than a back-of-the-envelope sketch storing intervals in lists. For me high level stuff is always pending on a workable low-level representation - which I seem to have perennial problems with. >> More concretely Roger Dannenberg (Score), Stephen Travis Pope (Smoke) >> and Paul Hudak, of course, have made score languages with tangible >> musical objects like chords, clusters, drum rolls etc. > > I'm familiar with Dannenberg's work on nyquist, but was unable to find > any references to Score, and it's a generic name and hard to search > for. I found a single short paper on Smoke, which I'm reading, but no > musical examples. And haskore of course I'm familiar with. "Canon" is Roger Dannenberg's score language - I don't know why I was thinking it was called "Score" (apparently there is a LilyPond-like program of that name). >> Regarding your comment in the other thread Evan, David Seidel (aka >> Mystery Bear) has made music with Csound that crossed over well enough >> from "computer music" to feature on Kyle Gann's Postclassic radio when >> it was running. > > Do you have any recommendations? I found some on his site, > http://mysterybear.net/, but it was all very much in the "abstract > sound design" genre, at least by my judgement. David Seidel's "Elementals" album was made with Csound (and Supercollider for one track). I wouldn't argue that it would sound like "abstract sound design" to many people, but it is attractive enough to catch a wider audience (vis it being featured on both Kyle Gann's Postclassic radio and his Artstjournal blog): http://www.stasisfield.com/releases/year07/sf-7004.html http://www.artsjournal.com/postclassic/2009/08/im_a_little_slow.html My personal favourite of the Csound pieces is: http://mysterybear.net/article/43/elegy-for-jon Best wishes Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] abstract music from csound et.al. (Was: ANN - csound-expression-3.1.0)
Hi Evan Ha, though miles away from being ready for public consumption my own "tower of DSLs" built over Csound gained symbolic notes, chords, trills and "Solo Parts" this week. Hopefully arpeggios, tremolos and more should follow soon. More concretely Roger Dannenberg (Score), Stephen Travis Pope (Smoke) and Paul Hudak, of course, have made score languages with tangible musical objects like chords, clusters, drum rolls etc. Regarding your comment in the other thread Evan, David Seidel (aka Mystery Bear) has made music with Csound that crossed over well enough from "computer music" to feature on Kyle Gann's Postclassic radio when it was running. Best wishes Stephen On 14 December 2013 04:12, Evan Laforge wrote: > Csound's instruments, once you design them, are instruments in the > restrictive sense, and in fact they come with a very limited score > language. Too limited---to use them according to "the rules", you'd > need layers of libraries and abstractions above to express notes, > phrases, ornaments, and melodies linguistically. Or you could > short-circuit all that by recording data from a physical instrument. > I'm sort of working on the first approach, but I haven't seen examples > of someone else trying that. ... ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] ANN: csound-expression - library to make electronic music
I haven't looked Anton's work so can speak for it, but Csound itself has Zak ports to route signals between "instruments". Zak ports are equivalent to SuperCollider's Synth Bus. On 2 November 2013 05:41, Evan Laforge wrote: > ... The only way to get the sound back in was to run > multiple csounds, in series, and you'd wind up recreating the internal > signal flow thing with a makefile mess. Is this limitation no longer > in csound, or did you find a way around? ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Is Haskell Really A Real-Time Language?
The "French School" of reactive programming has mostly extended imperative languages with reactivity (Reactive C, SugarCubes -> Java, ...). Stephen Edwards and Edward Lee proposed "a new era of processors whose temporal behaviour is as easily controlled as their logical function" five years ago, sadly chip manufacturers haven't followed their call: http://www.cs.columbia.edu/~sedwards/papers/edwards2007case.pdf (FWIW - PRET machines target "control realtime" - for audio synthesis "realtime" is something rather different). On 6 August 2012 16:57, Haskell Media wrote: > Pure/Faust = Haskell/Supercollider? (maybe Faust is not a "server") > > Has someone written an FRP language in C/C++? > > I'm beginning to appreciate Pure-Data more everyday... > > It's funny how difficult the realtime problem must be if most mainstream > languages can't guarantee a how long an operation will take to execute with > 2012 hardware. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
Hi Evan Mostly I want to generate small scores, maybe just a few bars, from "models". There are some really nice models of aspects of music that seemingly can be coded fairly easily - I pointed someone on this list (maybe you?) to Francois Pachet's OO (Smalltalk) model of intervals, scales and chords; other ones I like are "uniform triadic transformations" where chord transformations can be easily encoded[1] and a nice model of gamelan melodies in Michael Tenzer's book "Gamelan Gong Keybar". I've worked with these models coding them in Haskell, but I'd really like to look at output from them as notation to know I've understood them and got a decent implementation. When I know the original models from text with notation embedded, I want my versions to be comparable (generating MIDI and relying on my ear for validation isn't very good for me as I'm an ill-disciplined listener). As my starting point would be encoding something with a model, I don't care that I can't roundtrip with hand-made changes or merge a regenerated model. If it start hand modifying a score that would turn it into a "composition" something different to a illustration of a model and I'd have a one-off artefact. Best wishes Stephen [1] There was an accessible paper by Scott Alexander Cook using UTTs to analyse music by Gavin Bryars, unfortunately the main reference for UTTs by Julian Hook is only available via JSTOR. On 23 July 2012 19:54, Evan Laforge wrote: > > Did you have a specific score or family of scores you wanted to write > with haskell, or is this mostly an intellectual exercise? > ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
Hi Evan Lirio is a code generator - I consider it a macro expander / pretty printer as ideally it expands Haskell functions into LilyPond output. Unfortunately with LilyPond having its annoying parenthesizing syntax a[ b c ... ] Lirio sometimes has to transform its preliminary output during generation. I suppose I'll end up with a LilyPond with Haskell syntax - this is both good and bad. LilyPond is syntactically optimized for writing scores, so Haskell will always be less concise. Also I see full scores as essentially one offs - so it makes sense for someone writing a score to do so idiomatically (thus use LilyPond). To use an analogy with text processing - it's agreeable to use generation to create web sites (many pages sharing common traits) but unwise to use programmatic generation to generate the LaTeX of a dissertation (just write it in LaTeX). The singular positive of a "LilyPond with Haskell syntax" is that it shouldn't limit the kind of scores you can create whereas a composition language that translated to LilyPond would. I haven't looked at overlays yet for Lirio. Neume had them, but I suspect for Lirio they might be challenging. Best wishes Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
Hi Evan Thanks for the interest in Neume and Lirio. Neume was the predecessor which used a syntax representation that has bars, notes, chords, beams, tuplets (generalized to "n-plets") etc. Lirio is a rethink and simplification that uses a pretty printed representation with little tangible syntax. Both Neume and Lirio are supposed to generate "good" LilyPond scores (Neume also generated ABC). By good I mean the output should look like it was hand written (so it can be hand edited for a final score) and it should be possible to generate a "lot" of the syntax of LilyPond (so you shouldn't need to stitch the generated code into hand written templates). Initially I wanted Neume to generate scores form "notelist" formats like Haskore, but there isn't enough information in note lists to generate good scores. On my Flickr there is a rendering of Child Song 6 from Haskore - I don't expect to be hearing from Chick Corea's publishers: http://www.flickr.com/photos/44929957@N03/4459628487/in/photostream I worked on Neume quite a bit more trying to make its own notelist format more powerful, but I was adding "arbitrary" elements to the syntax so I could model e.g. "overlays" where a pianist holds down a root note with their thumb, whilst playing varying shorter notes with the fingers - this is clearly a different thing to a chord. By "arbitrary" I mean that the elements were needed for expressive power, but they didn't seem to have canonical names from standard notation or other notation programs so the names I gave them were arbitrary - this made for a complicated syntax which was still far from complete (articulations like crescendos were missing). I decided to start again with Lirio. Although Lirio still aims to generate "good" LilyPond, I see its use for "illustration" rather than final score generation - e.g. you might want to generate and print a catalogue Brazilian rhythms or sets of scales like the famous Slonimsky book. Note lists get some special help but basically all the other LilyPond syntax is just pretty-print Doc constructors. Beaming is done with "glyph transformers" that add beam marks to notes (unfortunately LilyPond has bizarre preffix-suffix notation for grouping such as beaming - this is really annoying for an output format). Direct glyph transformers feel wrong in most cases though - so I still have a lot of design work to do and I've largely shelved work on it until I take some holiday from the day job. Best wishes Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Lilypond parsing with Haskore
Hi Corbin, and welcome. Haskore should be a good target for a "note list" format. Note there are three "versions" of Haskore - Vintage which is circa the original School of Expression book, Henning's extended version and Euterpea[1] the successor to Haskell from Paul Hudak's Yale group. [1] http://haskell.cs.yale.edu/?page_id=103 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
Hi Evan In Neume - my "primitive notator" which generated LilyPond and ABC I spent a lot of time on metrical segmentation - mostly so I could get automatic beam grouping for ABC and LilyPond. If I remember correctly, one of them doesn't beam automatically and the other beams by time signature which is not always what you want as the same time signature can have different beaming grouping - grouping should be done by "meter pattern" but as there isn't an explicit notion of meter pattern Western notation you can't specify it (even though you can readily see meter patterns once a score is printed). For Lirio, my successor to Neume which only generates LilyPond, I've given up on automatic metrical segmentation - a library user is expected to know how the beaming should work and "pretty print" accordingly. Lirio is modestly intended to be a "pretty printer" rather than a score "generator", but even then there is quite a lot of "quirkiness" it has to handle. Beaming to a meter pattern isn't too hard, though I spent / wasted a lot of time on it. I gave up doing it automatically because it induces a hierarchy that doesn't work well with slurs, ties and other articulations. Lirio essentially has no abstract syntax whatsoever, whereas Neume had measures > bars > beam-groups / notes. There's an example of Arabic percussion on my Flickr that is in 7/8 but has a meter pattern of 2-2-3: http://www.flickr.com/photos/44929957@N03/4571078223/in/set-72157623851515959 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] code golf: diatonic transposition
On 29 May 2012 18:46, Evan Laforge wrote: > On the subject of keyboards, they are convenient > being cheap to buy, but it's also interesting to work with different > tools there too. So it's worth exploring primitives which are not > easy to use with a keyboard. Getting very off topic - do you know the keyboard designs of the tuning theorist Erv Wilson? The composer Kraig Grady has been generously archiving Erv's work and putting it on the web, otherwise it would have been lost to the world. http://www.anaphoria.com/wilson.html ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] code golf: diatonic transposition
Hi Evan For a fairly comprehensive take on similar work you might find Francois Pachet's "An Object Oriented Representation of Pitch Classes, Intervals, Scales and Chord: The Basic MusES" useful (available on Citeseer). Although the code in the paper is in Smalltalk it should be pretty easy to glean what it is doing. In Haskell I'd probably use Conal Elliott's nice vector space classes to model pitch alteration which seems like scalar addition, plus I'd make newtype wrapped Num types where you have modular arithmetic. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] umbrella term for flats and sharps
On 16 January 2012 18:23, Yitzchak Gale wrote: > In my experience, sharps and flats in the key signature are > not referred to as "accidentals". They are just called > "sharps and flats", or "the key signature". The term > "accidentals" really is reserved for inline exceptions to > the key signature. The Harvard Dictionary of Music calls them "sharps and flats" in the context of a key signature. Gardner Read's Notation book which is pretty authoritative, refers to them as "accidentals" making a key signature. So I guess it doesn't much matter... ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] MIDI-controlled application
On 27 December 2011 22:08, Heinrich Apfelmus wrote: > Stephen Tetley wrote: >> >> Incidentally, I've been working on a MIDI "animation language" for the >> last couple of days based on the animation language in Paul Hudak's >> book. I've wanted continuous behaviours to model modulating volumes >> (crescendos, decrescendos) and panning, but I've found the work tough >> going for modelling the note lists where I want the system discrete in >> both input (specification) and output. > > > Consider me interested. How does your approach compare to > Conal-style FRP with behaviors and events? > Moving from Cafe which has been a bit giddy of late... Unfortunately I didn't get very far with it. For non-realtime scores (think MIDI or Csound) I couldn't reconcile FRP's evaluation (which is sampling) with non-realtime Events that are specified by their onset time. For the output, I would want the evaluation trace to have only the specified events (elaborated with time varying values like loudness...) at the times they were specified. I have worked up a fairly substantial system where the representation is a functional "extensional"[*] one: OnsetTime -> Event. However, this representation doesn't really allow meaningful transformations - any transformations must pre-transform the input data of the event constructors as they cannot transform the output (the output can only be evaluated by the render, assembling it to a linear event list). The extensional view is the same one used by my vector graphics software Wumpus, which does allow the usual affine transformations because points are always in paths so you can scale the vector between them. I suppose I could add a notion of events being on a local timeline (rather than just unconnected points in time) to the music system, making be an analogue of paths in the graphics domain. With a timeline there would be a 1-dimensional vector (distance) between the events, so this would make them scaleable. Happy new year, all. [*] Thanks to Brent Yorgey on the beginners list recently for this term. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Functional view of music?
Hi everyone - thanks for the comments so far. Alex - I don't mean this as a criticism, but Paul Hudak's Music data type (p288 of SoE) is a data type rather than functional - you can pattern match on it, for instance. Your Pattern data type appears functional though. Functional types have been somewhat problematic for Wumpus (vector drawing) as they don't support introspection, so some drawings are very convoluted (e.g. centered or right aligned text). I'm looking for examples in the music domain to measure whether functional is worth pursuing rather than data / syntax. Evan - music and sound would be synonymous here, though analogue to pictures (Pan) or textures (Clastic) is important for my own purposes. I'd want to compile a Haskell source file to produce a sound file, probably with multiple instruments, and use panning, mixing etc. I'm well aware of ugens as continuous signals, there's a lot of work already in that domain - Paul Hudak's recent work, Jerzy Karczmarczuk's Clarion, Henning's synthesizer. Henning - I'm not sure precisely, it would probably end up as being as a not very illuminating - Time -> Syntax - as I would be looking to generate scores for CSound or Supercollider. Thanks again Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
[haskell-art] Functional view of music?
Hello all, The functional view of images - image as a function from Point -> Colour - is well practised for continuous images - Conal Elliott's Vertigo and Pan, Jerzy Karczmarczuk's Clastic, plus Pancito, Chalkboard and more. It's even been used for discrete pictures (i.e. vector graphics) - Peter Henderson's original picture language, Antony Courtney's Fruit and my own Wumpus[*]. Is there any prior work considering music functionally, though? - i.e. a function from Time -> Sound Thanks Stephen [*] For Wumpus, the jury is still out whether it is actually a fruitful approach... ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On 11 March 2011 08:58, Henning Thielemann wrote: > [SNIP] I would have thought that the hierarchical > structure is also better for music notation, but the actual > implementations show, that it is not. Haskore's structure unfortunately maps badly to LilyPond or ABC in a few ways: Systems really need to be separate from the beginning - so with Haskore you would have to do a traversal extracting each instrument from the tree. As you can change instrument then change back this is not so simple. Chords have discrete syntax - you can extract them from Haskore, but again its simply easier to have them from the beginning. Overlays - the same instrument playing simultaneous notes of different durations (e.g. on piano holding down the thumb on a note but moving the fingers through an arpeggio) need synch-ing to bar lines. If the overlay isn't sounding for the full bar it needs "spacer" rests - not-printed rests - to synchronize with the other overlay lines. This is hard to program "initially" i.e. find nice data types that accommodate it - trying to synthesize it from Haskore adds more woe. ... I still don't understand what Evan's reverse instrument models. Is it reversing the sound of a note so it is some function wrapping a unit generator? Or is it reversing a sequence of notes according to pitch? The second would seem easier to implement if you have a distinction between score and orchestra. I'd guess a score and orchestra distinction makes the first easier as well, though I haven't got very far with synthesis. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On 22 February 2011 23:41, Evan Laforge wrote:
>
> I'm not super knowledgable about supercollider, but isn't it basically
> a synthesizer which you configure by sending OSC over, and can then
> play it by sending more OSC?
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.
> Can you write 'inst2 pitch = reverse (inst1 pitch)'?
Is 'inst2 pitch = reverse (inst1 pitch)' the backwards instrument? My
first thought would be this is hard to write in any continuous
language even functional/FRP.
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
On 18 February 2011 07:00, Evan Laforge wrote: > To my eyes the problem is in the score vs. orchestra division that > starts with music-n languages like csound and goes all the way through > midi sequencers. Nyquist is the only language I know of that tried to > tackle that. I don't think SuperCollider has the score vs. orchestra division either and suspect ChucK doesn't either. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] purely functional circular buffers
On 17 February 2011 19:48, Stephen Sinclair wrote: [SNIP] > However, there is this common pattern in media- or simulation-oriented > programs (like games too): > > 1. Initialize state. > 2. Update state based on initial state. > 3. Update state based on state 2. > 4. Update state based on state 3. > ... > > or more succinctly.. > > t=0. Initialize state. > t=t+1. Update state based on state t-1. > > It seems to me that if it can be proven that state t depends only on > state t-n, then memory for states before t-n can be reused. If n is > known at compile time, which can be true for a lot of signal > processing applications, this should be feasible. If states t-n to t > are treated as immutable, then it could be considered as pure from an > outside perspective, something like the ST monad for instance. [Maybe off going topic, maybe not...] Martin Erwig and Paul Hudak did quite a bit of work around the topic "functional update" that seems not to have got the attention it might deserve. I've been curious for a while whether this work isn't still pertinent: Paul Hudak "Mutable Abstract Datatypes - or - How to Have Your State and Munge It Too" Yale Research Report RR-914 http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.66.3875 Martin Erwig "The Categorical Imperative - Or: How to Hide Your State Monads" http://web.engr.oregonstate.edu/~erwig/papers/CategoricalImperative_IFL98.pdf The latter is actually in the ST monad but it still seems quite different from today's state-of-the-art of ByteString, Builders and Stream-Fusion. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] Haskell art?
Hello all I'm the author of Wumpus (vector graphics) and Neume (music score setting). Wumpus is on Hackage. Wumpus-Core is the stable part - it is a library for generating PostScript and SVG from a fairly simple graphics model that's somewhat like PostScript but is essentially stateless. Wumpus has some other libraries that are a bit more problematic. As anyone who has dabbled in vector graphics soon finds out, the hiatus between the simple drawings (Lindemayer systems, Sieperski triangles, ...) and complicated but actually useful graphics (charts, block diagrams, petri nets...) is huge. The other Wumpus libraries (Wumpus-Basic, Wumpus-Drawing, Wumpus-Tree) are work towards producing useful graphics, unfortunately they are a long way from being generally useful: functionality and API's regularly change or disappear. Ideally I wouldn't have put the higher-level packages on Hackage as I wouldn't recommend anyone use them in their present state, but when I uploaded them I felt they were a lot nearer readiness than they turned out to be. Some pictures are on Flickr: http://www.flickr.com/photos/44929957@N03/ Neume generates LilyPond and ABC scores from Haskell, it rather resembles Wumpus-Core in that it manages the low-level functionality pretty well but for practical use there's another big hiatus between the low-level functionality and a higher-level model that would be pleasant and concise to program with. I have tried to tie Neume to Haskore, but Haskore has numeric (rather than symbolic) note lengths and arbitrary nesting of "systems" via the par combinator. Both of these make Haskore a very difficult candidate for a (printed) score language. Neume isn't on Hackage as although it is competent at what it does, it's a long distance from being a "Text.PrettyPrint for LilyPond" and I think people might expect it to be a "pretty print for LilyPond" if they stumbled across it in the wild. I hope to pick up work on Neume this summer after I've pushed Wumpus further along. Again there are some examples on Flickr. Best wishes Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] [Haskell-cafe] Lazy cons, Stream-Fusion style?
Hi Henning, thanks. For me, I can live without real-time. Real-time would be nice of course but the simplicity of Jerzy's Clarion (non-real-time, solely a "renderer") is compelling: eliding counting the lines of code for the stream type and the WAV file I/O, Clarion can produce audio in 2-3 lines of code which is amazing for a general purpose language rather than a custom audio language like RTCmix or Chuck. Un-optimized, with a head-strict stream (basically Wouter Swierstra's Stream with a bang on the element), rendering currently takes minutes to generate seconds. But as well as the Stream representation, I've plenty of room to optimize the WAV file generation. For finite signals, my initial thought is simply that the finite part can be the prologue to a tail stream of zeros. Probably I can live without definitions like @ ones = 1 <:> ones @, I would like to know whether of not this is impossible with Stream-Fusion anyway. Thanks again. Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] common structures in temporal media
On 1 November 2010 17:18, Anton Kholomiov wrote: > Temporal class > > Temporal class is something like timed Maybe. 'dur' takes measurement and > 'none' stands for Nothing that lasts for some time t. It's rest for music or > black screen for movie. Yes the the Temporal class is in Paul Hudak's research report RR-1259, its a while since I've read it and I missed that it was already defined. > Stretchable > > it looks like, but to define scalar multiplication in vector space you have > to define (+). And there are rules. > forall k, v : (k) `smul` v + (-k) `smul` v === 0 > I can't find meaningful (smul, +) for Media. Semantically 'stretch (-k)' - > may be stretch and reverse. But what is (+)? Good point - I hadn't thought of the other parts of a vector space. Stretching doesn't seem to be considered as a type class in RR-1259 though it is considered as an operation on specific types. Another possiblity is to consider you have a one-dimensional geometry: Stretch then is scale - negative scaling is a reflection and (abs) scaling. Translate is shifting start times. Rotate is problemmatic, I think because you have no Y dimensions all you can do with a rotation is a reflection. Its not a probably not a valuable operation here anyway. Relection is reverse. I don't think there's a notion of shearing as you only have one dimension. Now with reverse as reflection I think you get fairly good sematics for reverse - but it does mean that music might start before t=0. Geometers don't much care where things are in relation to the origin they just make sure the viewport is large enough to show everything. However, you might find this unacceptable for music / events streams. Pictorially, assuming a fixed with font... (t) is treble, (b) is bass, (+) is the origin t=0: + + This also takes things away from Paul Hudak's Media type where, for me at least, "concatenation" either vertically or horizontally is primary to the Media type. In a geometric view, drawing with respect to an initial coordinate (which here is the onset time) is primary. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] common structures in temporal media
Hello Anton I think the Temporal class might more simply be metric / distance space. I can't see what 'none' is doing, 'dur' seems to be taking a measurement. The FingerTree paper by Ralf Hinze and Ross Paterson uses a distance space, but otherwise I haven't seen people use them in Haskell. Its a class I'd like if some one designed it properly worked out other valuable derived operations (I don't have the math skills to do this myself). Strechable looks like scalar multiplication in a vector-space. I don't quite see what TMap does to require a class rather than this function: tmap :: Functor f => (t -> a -> b) -> t -> f a -> f b tmap fn t = fmap (fn t) I suspect your event list will be very inefficient. It seems to be avoiding the tree shape of the original Media type by annotating the linear elements in a list with time values. This gives you the ability to represent parallel events but puts a lot of burden on traversing and maintaining the list. Because of this I'd be a bit concerned that some of your classes really only have "one good instance" for the Media type and a bad (i.e inefficient) instance for EventList. Having "classes with one good instance" is generally an anti-pattern and usually indicates plain functions would be better. Apologies if the above is over-critical. Representing music (and event lists / media) is actually a very difficult topic. All work in this area is valuable and your contribution is very welcome. Best wishes Stephen ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
