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
I'm pretty sure that you can specify time signatures and key signatures in Midi -- not sure about triplets and other subtleties. In any case, my hope was that some music notation editor can do a lot of the important interpretation for me -- beaming across bar lines, etc. -- although I realize it won't be perfect. -Original Message- From: Bernardo Barros [mailto:bernardobar...@gmail.com] Sent: Saturday, July 28, 2012 3:48 PM To: haskell-art@lurk.org Subject: Re: [haskell-art] rhythmic spelling 2012/7/28 Hudak, Paul : > A long time ago I was considering designing a Haskore-to-Lilypond converter, > but I stopped when I realized if I could generate Midi, and then feed the > Midi file to a music notation editor like Cakewalk or whatever, then my needs > were satisfied: just getting some visible version of the music in common > practice notation. Of course, this doesn't get me a key signature and time > signature, but I wonder if just adding a couple of things like that to > Euterpea (for example as a Phrase Attribute discussed in my last message) > would be good enough for many people's applications. > The problem is that MIDI doesn't know nothing about meter either (time signatures, tuplets etc). Also quartertones and other microtonal accidentals are not understood by MIDI. I think a good converter would be nice. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
2012/7/28 Hudak, Paul : > A long time ago I was considering designing a Haskore-to-Lilypond converter, > but I stopped when I realized if I could generate Midi, and then feed the > Midi file to a music notation editor like Cakewalk or whatever, then my needs > were satisfied: just getting some visible version of the music in common > practice notation. Of course, this doesn't get me a key signature and time > signature, but I wonder if just adding a couple of things like that to > Euterpea (for example as a Phrase Attribute discussed in my last message) > would be good enough for many people's applications. > The problem is that MIDI doesn't know nothing about meter either (time signatures, tuplets etc). Also quartertones and other microtonal accidentals are not understood by MIDI. I think a good converter would be nice. ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
A long time ago I was considering designing a Haskore-to-Lilypond converter, but I stopped when I realized if I could generate Midi, and then feed the Midi file to a music notation editor like Cakewalk or whatever, then my needs were satisfied: just getting some visible version of the music in common practice notation. Of course, this doesn't get me a key signature and time signature, but I wonder if just adding a couple of things like that to Euterpea (for example as a Phrase Attribute discussed in my last message) would be good enough for many people's applications. -Paul -Original Message- From: Stephen Tetley [mailto:stephen.tet...@gmail.com] Sent: Sunday, July 22, 2012 4:43 PM To: haskell-art@lurk.org Subject: 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 ___ haskell-art mailing list haskell-art@lurk.org http://lists.lurk.org/mailman/listinfo/haskell-art
Re: [haskell-art] rhythmic spelling
> I suppose I'll end up with a LilyPond with Haskell syntax - this is > both good and bad. LilyPond is syntactically optimized for writing Right, that's what I was getting at. It seems the only benefit lilypond with haskell syntax would offer is the power of a real language to abstract, e.g. generate score. It would also possibly be a better syntax, but at least I think lilypond isn't so bad, as you mentioned it's pretty well tuned for writing one-off scores. Generating lilypond you'd also be limited in how fancy you get, I'd think most of hand tweaking that a real score inevitably involves you'd have to write as an "inline lilypond" hack, which of course is weakening the point of using haskell in the first place. That also fits in with generation, since that stuff exists at a level above score layout concerns. On the other hand, having to hand-edit output and having no way to automatically merge further changes to the original seems like a trap. The workflow gets more tricky if there's a one-way door in it. 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
So is the idea to have something like lilypond (e.g. something to generate staff notation), but with haskell syntax? Or is it a general purpose composition language that happens to have a staff notation output? The "overlays" thing you describe makes it sound like a composition language because you are wanting to write things with no direct correspondant in staff notation, but then Lirio sounds like it's basically a lilypond generator. On Mon, Jul 16, 2012 at 4:50 AM, Stephen Tetley wrote: > 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 ___ 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] rhythmic spelling
On Thu, Jun 14, 2012 at 6:02 AM, Stephen Tetley wrote: > 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). Sorry about the long delay, I was travelling. It turned out I really needed a decent lilypond export feature so I put some time into getting the durations right, though all the music was in duple meters, so I haven't bothered to support that yet. The core is a function to figure out how much time is allowed at a certain position in a bar before the note has to be split and tied: -- | Figure out how much time a note at the given position should be allowed -- before it must tie. -- TODO Only supports duple time signatures. allowed_dotted_time :: TimeSignature -> Time -> Time allowed_dotted_time sig measure_pos | pos == 0 = measure | otherwise = min measure next - pos where pos = measure_pos `mod` measure measure = measure_time sig level = log2 pos + 2 -- TODO inefficient way to find the next power of 2 greater than pos. -- There must be a direct way. next = Maybe.fromJust (List.find (>pos) [0, 2^level ..]) Anyway, lilypond does do automatic beaming, but durations is a different problem because beams are either on or off, while durations keep dividing all the way until you get tired of counting flags. For beaming I don't see why you'd need to compromise the data structure, eventually the notes have to be flattened into a stream of lilypond notes, just do a postprocessing step on that. At least that's what I do, the internal score format has a completely different notion of hierarchy. Neume and Lirio sound interesting, what are they used for? ___ 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
[haskell-art] rhythmic spelling
Since my last query about music yielded so many interesting responses,
I thought I'd ask again about something that's currently puzzling me.
This one is about rhythm, rather than pitch.
In the course of generating output for lilypond (a music typesetting
system that emits western style 5-line staff notation), I found myself
needing to figure out how to spell rhythms. That is, given notes with
starting times and durations in absolute time, to come up with a
series of half notes, quarter notes, ties, etc. to spell them into
measures in a given time signature.
I started with the notion that notes should tie across divisions of
the measure, rather than spanning them. So I wrote a function,
'allowed_time' to calculate the largest possible duration at a given
point in a measure, and split up notes into series of tied notes by
repeatedly calling it (some code omitted below for brevity):
-- | Time in score units. The maximum resolution is a 128th note, so one unit
-- is 128th of a whole note.
newtype Time = Time Int deriving (Eq, Ord, Show, Num, Enum, Real, Integral)
-- | This time duration measured as the fraction of a whole note.
data Duration = D1 | D2 | D4 | D8 | D16 | D32 | D64 | D128
deriving (Enum, Eq, Ord, Show)
data TimeSignature = TimeSignature { time_num :: !Int, time_denom :: !Duration }
deriving (Show)
allowed_time :: TimeSignature -> Time -> Time
allowed_time sig pos
| power_of_2 (time_num sig) = allowed
| otherwise = min (dur_to_time (time_denom sig)) allowed
where
measure = measure_time sig
rest = measure - pos `mod` measure
allowed = 2 ^ log2 rest
power_of_2 = (==0) . snd . properFraction . logBase 2 . fromIntegral
The idea was that this would emit the most conservative spelling and I
would later fix things up by replacing e.g. 'c4~ c8' with 'c4.' (this
is lilypond notation, 'c' is the pitch, 4 is a quarter note, '.' adds
a dot, and ~ ties it to the next note). However, there are a lot of
awkward things to fix up, e.g. in 4/4 'c8 c4.' is ok, but 'c16 c4.
c16' should be tied like 'c16 c8.~ c8. c16'. 'c4 c2 c4' is ok, but
when they don't line up on major beats, like 'c8 c2 c8 c4' you should
write 'c8 c4.~ c8 c8 c4'. Also I had to make an awkward exception
where meters whose denominator is a power of 2 may subdivide evenly,
but 3/4 can only divide up to quarter notes, even though 'c4 c2' is
perfectly reasonable.
So I decided a better approach might be to not emit so many ties in
the first place instead of trying to merge them back together
afterwards. The idea is that notes beginning on a low order division
(e.g. log2 so the 1st division of 4/4 is beats 1 and 3, the 2nd is
beats 1 2 3 and 4, etc.) can span divisions >=n-1. So a note
beginning on beat 2 is allowed to span the division 1 on beat 3,
because beat 2 is division 2 and 1>=2-1, so it can be anything up to a
dotted half. But a note beginning on beat 2.5 must break at beat 3
(division 1), because 2.5 is on division 3, and can only span division
2 and up (so if it were on 1.5 it would be good up to a dotted
quarter, but if it's on 2.5 it maxes out at an eighth).
Of course in non-power of 2 time signatures, the first division is not
binary, but is the numerator of the time signature (so 3/4 divides
into 3 quarters instead of 2 halfs). And of course for the moment I'm
neglecting signatures with multiple levels of division, like 3+2 / 4
or 4/4 + 3/8.
I *think* this would work, though it seems complicated. But it seems
like the sort of problem that would have to be faced as soon as you
need to go from absolute time to a western-style log2-oriented rhythm
notation. I intend to do a bit of digging into the source of programs
that try to turn recorded music into notation (rosegarden I believe
can do that), but I imagine it's probably buried in tons of c++
implementation detail. Has anyone here dealt with this kind of
problem before?
___
haskell-art mailing list
haskell-art@lurk.org
http://lists.lurk.org/mailman/listinfo/haskell-art
