Re: [haskell art] SCHelp parser?

[Stephen Tetley]

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

[Stephen Tetley]

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 a...@slab.org 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

[Stephen Tetley]

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)

[Stephen Tetley]

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 a...@slab.org 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)

[Stephen Tetley]

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 qdun...@gmail.com 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] ANN: csound-expression - library to make electronic music

[Stephen Tetley]

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 qdun...@gmail.com 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] rhythmic spelling

[Stephen Tetley]

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] code golf: diatonic transposition

[Stephen Tetley]

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

[Stephen Tetley]

On 16 January 2012 18:23, Yitzchak Gale g...@sefer.org 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

[Stephen Tetley]

On 27 December 2011 22:08, Heinrich Apfelmus apfel...@quantentunnel.de 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?

[Stephen Tetley]

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

Re: [haskell-art] Haskell art?

[Stephen Tetley]

On 11 March 2011 08:58, Henning Thielemann
lemm...@henning-thielemann.de 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?

[Stephen Tetley]

On 22 February 2011 23:41, Evan Laforge qdun...@gmail.com 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?

[Stephen Tetley]

On 18 February 2011 07:00, Evan Laforge qdun...@gmail.com 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

[Stephen Tetley]

On 17 February 2011 19:48, Stephen Sinclair radars...@gmail.com 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?

[Stephen Tetley]

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?

[Stephen Tetley]

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