Wumpus

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.

Wumpus

Copperbox revision 616.

I've redone the basic shape disk to have fill properties as part of the datatype type Disk rather than its draw function.

This looks like it will be the idiom I'm going to use for all the basic shapes.

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.

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

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?

Wumpus

Copperbox revision 612.

I've changed Wumpus to use the VectorSpace library for scalar product and the like.

Wumpus

Copperbox revision 611.

I've factored out points from the Vector module.

Wumpus

Copperbox revision 610.

I've moved the CTM specific types and operations out of the Matrix module into their own CTM module.

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.

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.

Wumpus

Copperbox revision 606.

First attempt at trying to draw arrowheads, which hasn't been too successful. The code so far is stuck in turtle land (i.e. its too Logo-like).

Wumpus

Copperbox revision 605.

Added a module for the named X11 colours.

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.

Wumpus

Copperbox revision 603.

I've changed the SVG named colours to be literals in the range [0,1]. Before they were specified in the range [0,255] with a call to a conversion function to convert them to the [0,1] range.

Wumpus

Copperbox revision 602.

More work on colours - I've added a module with the SVG named colours and added current colour to the graphics state.

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.

Wumpus

Copperbox revision 600.

Initial work on the CTM - current transformation matrix - and its operations in Wumpus.

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).

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.

Mullein

Copperbox revision 597.

Apropos the last comment, I've added the export lists to the remaining modules.

Mullein

Copperbox revision 596.

First set of changes adding export lists to the modules in Mullein. I've removed some old code, but in the main I'll leave in code that provides extra functionality even if it isn't used.

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.

Mullein

Copperbox revision 594.

Mullein can now output piano scores to LilyPond - i.e. scores with both a treble and a bass part. This is now used in the ChildSong6 example.

Mullein

Copperbox revision 593.

I've removed an old module (System from the Haskore interface) and merged the modules Core and CoreTypes, tidying things up a bit.

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.

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.

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.

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.

Mullein

Copperbox revision 588.

Ssf.lhs now has rewrite rules that eliminate the trills. It now outputs "good" LilyPond.

Mullein

Copperbox revision 587.

Ssf.lhs - Stars and Stripes Forever, now uses the latest Haskore translation. The output still cannot be rendered by LilyPond unfortunately - I haven't written the string rewrite rules to change the duration of the trills.

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.

Mullein

Copperbox revision 585.

Work towards adding string rewriting to the Haskore conversion process.

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.

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.