Copperbox revision 617.
Arghh! The idiom that yesterday I thought was promising for graphical objects hasn't turned out so well. Essentially I was making graphical objects a pair of (representation, properties) where representation is say a list of points for a polygon and properties are line width, fill colour etc. But this mandates a horrible tower of aliased selector functions (through type classes) to manipulate them.
I've committed the initial changes to use this idiom, but it already seems like a dead end.
A side note, unlike Clastic and Pan I'm not considering the graphical objects to be functions 'from Point to ...', my graphical objects are first-order (points, lists-of-points, etc). Maybe this is my real problem - that I'm not getting the heart of my (co)-domain.
Monday, May 25, 2009
Wumpus
Copperbox revision 615.
An experiment adding properties (lineWidth, fillColour, strokeColour) to polygon drawing.
I think these properties are probably better as part of a polygon datatype - so they can be transformed more uniformly. However this was an interesting attempt and worth check-pointing.
An experiment adding properties (lineWidth, fillColour, strokeColour) to polygon drawing.
I think these properties are probably better as part of a polygon datatype - so they can be transformed more uniformly. However this was an interesting attempt and worth check-pointing.
Wumpus
Copperbox revision 614.
I've changed the module namespace for Wumpus.
It looks like Wumpus is developing into a tool to draw PostScript graphics rather than a library, so seems preferable to have Wumpus under its own namespace rather than Graphics.Wumpus.etc
I've changed the module namespace for Wumpus.
It looks like Wumpus is developing into a tool to draw PostScript graphics rather than a library, so seems preferable to have Wumpus under its own namespace rather than Graphics.Wumpus.etc
Sunday, May 24, 2009
Wumpus
Copperbox revision 613.
I've re-implemented the basic operation diamond to use affine transformations.
The code isn't particularly neat yet, but the result is okay. This version translates points then draws the polygon the form so it has the correct line width. The previous attempt drew a square then transformed it - changing the line width as it scaled.
It looks like I'm going to have to work out my types sooner rather than later - e.g. do I want to use the Point2 etc. types that are currently internal for user functions?
I've re-implemented the basic operation diamond to use affine transformations.
The code isn't particularly neat yet, but the result is okay. This version translates points then draws the polygon the form so it has the correct line width. The previous attempt drew a square then transformed it - changing the line width as it scaled.
It looks like I'm going to have to work out my types sooner rather than later - e.g. do I want to use the Point2 etc. types that are currently internal for user functions?
Saturday, May 23, 2009
Friday, May 22, 2009
Thursday, May 21, 2009
Wednesday, May 20, 2009
Wumpus
Copperbox revision 609.
Experiments drawing basic shapes - polygons, ellipses etc.
Wumpus's writer monad style does feel a bit uncomfortable for this as the shapes aren't graphical objects but series of commands; they can only be transformed by more commands rather than, well functions.
Experiments drawing basic shapes - polygons, ellipses etc.
Wumpus's writer monad style does feel a bit uncomfortable for this as the shapes aren't graphical objects but series of commands; they can only be transformed by more commands rather than, well functions.
Wumpus
Copperbox revisions 607 & 608.
Changed Wumpus to use a handmade matrix datatype. For my own learning point of view I feel that its going to be more useful to write my own than use a readymade library. Also the Matrix module which implements a shadow of PostScript's CTM had been missing from the repository - I added it in revision 608.
Changed Wumpus to use a handmade matrix datatype. For my own learning point of view I feel that its going to be more useful to write my own than use a readymade library. Also the Matrix module which implements a shadow of PostScript's CTM had been missing from the repository - I added it in revision 608.
Tuesday, May 19, 2009
Monday, May 18, 2009
Wumpus
Copperbox revision 604.
I've added an experiment with a state tracking parameterized monad. The state is the drawing path - the pmonad enforces that you must create a path with newpath before adding lines with lineto; then you must use closepath before fill or stroke (and it enforces that you can only do one or the other).
This is very slick as it took almost no effort, unfortunately it does mean the do-notation can't be used, so I'm not sure if it has a place in Wumpus.
I've added an experiment with a state tracking parameterized monad. The state is the drawing path - the pmonad enforces that you must create a path with newpath before adding lines with lineto; then you must use closepath before fill or stroke (and it enforces that you can only do one or the other).
This is very slick as it took almost no effort, unfortunately it does mean the do-notation can't be used, so I'm not sure if it has a place in Wumpus.
Sunday, May 17, 2009
Wumpus
Copperbox revision 601.
I've added a module for colour conversion - following PiScript's example I made the CTM in Wumpus introspective, so it seems natural to make current colour introspective too (introspective here means you can query the value as well as set it). Conversion functions were the first step for this, as the current colour in PostScript's graphics state can be accessed either as HSB or RGB.
I found writing the conversion formulas quite tricky - perhaps PostScript has a different representation of HSB to the first algorithms I tried. Certainly converting the equations from Gonzalez and Woods 'Digital Image Processing' didn't work for me. The best reference I found in the end was Dr. Uwe Kern's manual for the xcolor LaTeX package.
I've added a module for colour conversion - following PiScript's example I made the CTM in Wumpus introspective, so it seems natural to make current colour introspective too (introspective here means you can query the value as well as set it). Conversion functions were the first step for this, as the current colour in PostScript's graphics state can be accessed either as HSB or RGB.
I found writing the conversion formulas quite tricky - perhaps PostScript has a different representation of HSB to the first algorithms I tried. Certainly converting the equations from Gonzalez and Woods 'Digital Image Processing' didn't work for me. The best reference I found in the end was Dr. Uwe Kern's manual for the xcolor LaTeX package.
Friday, May 15, 2009
Thursday, May 14, 2009
Wumpus
Copperbox revision 599.
Another attempt at a PostScript output library. Wumpus uses a writer monad to emit output as it goes along, rather than tries to build a syntax tree. Emitting output rather than building a tree to pretty print is the approach used by PiScript and the OCaml library postscript.ml. Hawa my previous attempt had tried to build a syntax tree, but I was never sure it was a viable way.
Incidentally, Wumpus gets its name from w(riter) m(onad) p(ost) s(cript).
Another attempt at a PostScript output library. Wumpus uses a writer monad to emit output as it goes along, rather than tries to build a syntax tree. Emitting output rather than building a tree to pretty print is the approach used by PiScript and the OCaml library postscript.ml. Hawa my previous attempt had tried to build a syntax tree, but I was never sure it was a viable way.
Incidentally, Wumpus gets its name from w(riter) m(onad) p(ost) s(cript).
Tuesday, May 12, 2009
Mullein Release 0.1
Copperbox revision 598.
I've marked this revision as a release and added a download to the Copperbox googlecode page.
While the code is too rough for Hackage, all the examples run as I expect [1] so it seems worthwhile make a snapshot of the current code and package it as a release.
[1] NewResolutions.lhs doesn't produce good output but that is a known limitation.
I've marked this revision as a release and added a download to the Copperbox googlecode page.
While the code is too rough for Hackage, all the examples run as I expect [1] so it seems worthwhile make a snapshot of the current code and package it as a release.
[1] NewResolutions.lhs doesn't produce good output but that is a known limitation.
Mullein
Copperbox revision 595.
I'm now reasonably happy with Mullein's functionality. I can generate 'good' LilyPond for simple Haskore scores, which at various times I thought would be all but impossible. 'Good' in this context means the output resembles LilyPond that might have been handwritten, it is quite possible that there are still some bugs in the output rendering.
Also, as developing Mullein and its predecessor Haskore has been so long winded, I've got no energy at present to consider writing a Haskore-like score language that is closer to LilyPond and ABC than MIDI. So I've decided to package up Mullein as a Haskore post-processor. This revision is the first step towards that - I've put both Mullein and MulleinHaskore in the same source package. The next round of work will be giving the modules proper interfaces that export only the public functions.
I'm now reasonably happy with Mullein's functionality. I can generate 'good' LilyPond for simple Haskore scores, which at various times I thought would be all but impossible. 'Good' in this context means the output resembles LilyPond that might have been handwritten, it is quite possible that there are still some bugs in the output rendering.
Also, as developing Mullein and its predecessor Haskore has been so long winded, I've got no energy at present to consider writing a Haskore-like score language that is closer to LilyPond and ABC than MIDI. So I've decided to package up Mullein as a Haskore post-processor. This revision is the first step towards that - I've put both Mullein and MulleinHaskore in the same source package. The next round of work will be giving the modules proper interfaces that export only the public functions.
Monday, May 11, 2009
Mullein
Copperbox revision 592.
The last commit had a bug in beaming - the function beamGroup1 would consume notes greater than or equal to a quarter note if they notionally fit in the beam group. This has been corrected. Now ChildSong6 renders the treble part without LilyPond warnings.
The last commit had a bug in beaming - the function beamGroup1 would consume notes greater than or equal to a quarter note if they notionally fit in the beam group. This has been corrected. Now ChildSong6 renders the treble part without LilyPond warnings.
Mullein
Copperbox revision 591.
I've re-implemented the beam grouping algorithm. I did this for aesthetic reasons - I could no longer understand the original version. As it happens the original version had a bug where it was dropping notes after a beam group. This bug was one reason ChildSong6.lhs was printing so badly (I only know the recording, so I'm not too adept at spotting errors in the output). Now ChildSong6 only has 2 metrical warnings from LilyPond and will generate a seemingly reasonable score.
I've re-implemented the beam grouping algorithm. I did this for aesthetic reasons - I could no longer understand the original version. As it happens the original version had a bug where it was dropping notes after a beam group. This bug was one reason ChildSong6.lhs was printing so badly (I only know the recording, so I'm not too adept at spotting errors in the output). Now ChildSong6 only has 2 metrical warnings from LilyPond and will generate a seemingly reasonable score.
Sunday, May 10, 2009
Mullein
Copperbox revision 590.
Changes to the beaming code so that beam groups must start and end with notes or chords (and not graces or rests). Beam groups with grace notes at the start or the end were causing LilyPond to throw an error on the output from ChildSong6. Now LilyPond will run on Mullein's output.
Note, the beam grouping code has degenerated as I've had to account for these special cases. I need a better algorithm to work out beam groups.
Changes to the beaming code so that beam groups must start and end with notes or chords (and not graces or rests). Beam groups with grace notes at the start or the end were causing LilyPond to throw an error on the output from ChildSong6. Now LilyPond will run on Mullein's output.
Note, the beam grouping code has degenerated as I've had to account for these special cases. I need a better algorithm to work out beam groups.
Mullein
Copperbox revision 589.
Work on getting LilyPond output from the Haskore example - ChildSong6.
This example is a lot more challenging for Mullein than Stars and Stripes Forever. Currently Mullein generates LilyPond with syntax errors - the bracketing code is putting grace notes inside beam groups which is a problem for LilyPond.
Work on getting LilyPond output from the Haskore example - ChildSong6.
This example is a lot more challenging for Mullein than Stars and Stripes Forever. Currently Mullein generates LilyPond with syntax errors - the bracketing code is putting grace notes inside beam groups which is a problem for LilyPond.
Saturday, May 9, 2009
Friday, May 8, 2009
Mullein
Copperbox revision 586.
Preliminary work on a new Haskore translation module. The previous translation builds a system (a finite map between instrument names and tunes) from the whole score then the system is queried for a tune which is further processed to turn it into LilyPond or ABC.
The new version avoids building a system and starts by extracting an instrument's tune. This should support a more of a pipeline approach where each step refines the tune.
Preliminary work on a new Haskore translation module. The previous translation builds a system (a finite map between instrument names and tunes) from the whole score then the system is queried for a tune which is further processed to turn it into LilyPond or ABC.
The new version avoids building a system and starts by extracting an instrument's tune. This should support a more of a pipeline approach where each step refines the tune.
Thursday, May 7, 2009
Mullein
Copperbox revision 584.
Last week I got Mullein to print score for the examples in the Haskore distribution. Unfortunately the output was garbage - the LilyPond output looked more like a graphic score than conventional notation.
This is a problem due to Haskore representing durations as absolute times and scores doing arithmetic on them - this is correct for Midi where the duration of an appogiatura is taken from the next next note, but it doesn't work for LilyPond or Abc. Also I found that the metrical splitting code in Mullein isn't perfect - there is a bug somewhere that allows it to make empty beam groups.
I tried to get Mullein to reconstitute durations - its superficially easy to recognize trills and appogiatura in Haskore output. Unfortunately if you also want to consider triplets and n-plets then it becomes very difficult to recognize what an irregular duration might indicate. So that path got abandoned.
After a few false starts, I think I have a solution in string rewriting. If the notes are considered a list it is easy to traverse pairwise looking for combinations where an appogiatura is subtracted from its following note and rewrite them to be a grace and an note with regular duration. The actual implementation is more expressive as you can do traversal with arbitrary depth rather than just pairwise, so other transformations can be implemented. I've written the string rewriting implementation, but I haven't hooked it into the Haskore output yet.
This means that a Haskore score will need both a template doc to control the textual output to LilyPond and a set of rewrite rules to massage the score into something that is metrically digestible - this is quite a user burden. However, I really can't see a viable way of doing the metrical reconstitution automatically.
Last week I got Mullein to print score for the examples in the Haskore distribution. Unfortunately the output was garbage - the LilyPond output looked more like a graphic score than conventional notation.
This is a problem due to Haskore representing durations as absolute times and scores doing arithmetic on them - this is correct for Midi where the duration of an appogiatura is taken from the next next note, but it doesn't work for LilyPond or Abc. Also I found that the metrical splitting code in Mullein isn't perfect - there is a bug somewhere that allows it to make empty beam groups.
I tried to get Mullein to reconstitute durations - its superficially easy to recognize trills and appogiatura in Haskore output. Unfortunately if you also want to consider triplets and n-plets then it becomes very difficult to recognize what an irregular duration might indicate. So that path got abandoned.
After a few false starts, I think I have a solution in string rewriting. If the notes are considered a list it is easy to traverse pairwise looking for combinations where an appogiatura is subtracted from its following note and rewrite them to be a grace and an note with regular duration. The actual implementation is more expressive as you can do traversal with arbitrary depth rather than just pairwise, so other transformations can be implemented. I've written the string rewriting implementation, but I haven't hooked it into the Haskore output yet.
This means that a Haskore score will need both a template doc to control the textual output to LilyPond and a set of rewrite rules to massage the score into something that is metrically digestible - this is quite a user burden. However, I really can't see a viable way of doing the metrical reconstitution automatically.
Friday, May 1, 2009
Mullein
Copperbox revision 583.
Working with more examples from the Haskore-vintage package. Neither NewResolutions or ChildSong6 will render, the first problem is that Mullein cannot handle combined durations (e.g. hn + en, half note plus eighth note). I'll have to extended the metrical splitting code to accommodate this.
Working with more examples from the Haskore-vintage package. Neither NewResolutions or ChildSong6 will render, the first problem is that Mullein cannot handle combined durations (e.g. hn + en, half note plus eighth note). I'll have to extended the metrical splitting code to accommodate this.
Subscribe to:
Posts (Atom)
Blog Archive
About Me
- Stephen Tetley
- Disambiguating biog as there are a few Stephen Tetley's in the world. I'm neither a cage fighter or yachtsman. I studied Fine Art in the nineties (foundation Bradford 1992, degree Cheltenham 1992 - 95) then Computing part-time at Leeds Met graduating in 2003. I'm the Stephen Tetley on Haskell Cafe and Stackoverflow.