Bala2

Copperbox revision 779.

More work on pitch and intervals, mainly improving the AdditiveGroup instance for Interval and new functions for printing the interval quality.

Bala2

Copperbox revision 778.

I've realized that the arithmetic on intervals is too simple-minded to handle the zero interval properly. This is a checkpoint commit before I attempt to tackle its shortcomings.

Bala2

Copperbox revision 777.

Some more pitch and pitch-class operations.

Bala2

Copperbox revision 776.

Work on affine operations on pitch and intervals. The AffineSpace might now work, but they aren't pretty (they're polluted by 'carrys' to handle negative intervals). This code will need some quick checking.

Bala2

Copperbox revision 775.

I've added new modules for Z12 & Z7 modular arithmetic and pitch names. Improving the vectorial operations on pitch and intervals is on going.

Bala2

Copperbox revision 774.

I've added cabal files to Bala2 so that I can run Haddock on it.

Also I corrected two errors with the interval/pitch addition and difference code (the AffineSpace instances) - but I still don't like the code. I'll have to think about how to make these instances simple enough to be obviously correct.

Bala2

Copperbox revision 773.

Initial work for representing fretboard / chord diagrams. There is some work on this in the original Bala package but it wasn't very good, so I've had to start again from scratch.

Mullein-0.2.0

Copperbox revision 772.

I've added a release binary of Mullein - marking the current version at 0.2.0.

Mullein

Copperbox revision 771.

I'm now satisfied with the beam grouping code. I'm using the SnocWriter monad again, which has simplified the accumulator (the accumulator is now just the current be group, processed beam groups are hidden collected by the SnocWriter).

Mullein

Copperbox revision 770.

I've redone beam grouping with a double accumulator (all processed beam groups, current beam group). This one handles flushing the accumulator at the end of the note list correctly but it is rather ugly. Beaming still needs some work...

Mullein

Copperbox revision 769.

Another marginal improvement to beam grouping. This one tidies up the code quite nicely but it doesn't solve the problem whereby the last accumulation of beamed elements might start or end with rests rather than notes.

Mullein

Copperbox revision 768.

An 'improvement' to beam grouping stopping beam groups beginning or ending with rests. This improvement is unsatisfactory, though. It needs some more thought.

Bala2 and Mullein

Copperbox revision 767.

I've removed the previous models of rhythm patterns from Bala.RhythmPattern that didn't capture duration. Also I've tidied up the RhythmExample making it output a two-part overlay rhythm.

'Concat-ing' overlays was missing in Mullein, so I've added a function overlayPhrases, though this is just the function longZip.

Bala2

Copperbox revision 766.

I've revised RhythmPattern to be a list of events (notes) or rests. Events and rests have a duration, this means the new RhythmPattern has more information than the previous one. The previous version tried to synthesize the duration of events (effectively by zipping a list of durations into the onset list); it is easier to have them as part of the data structure.

Bala2 and Mullein

Copperbox revision 764.

I've added a module to Bala for rhythmic patterns and a 'collective import' module for LilyPond to Mullein.

Unfortunately the RhythmPattern module doesn't really live up to the comment I made yesterday about making Bala stringent. The main datatype just captures the onsets of the rhythm which is fine (this is in accordance with definitions elsewhere), but the interpretation function needs duration as well - a scored rhythm might subdivide an onset with a note an a rest rather than a long sustained note. Currently how I handle this is unsatisfactory.


Copperbox revision 765.

Added a collective import module for ABC to Mullein.

Bala2 and Mullein

Copperbox revision 763.

I've started a new version of Bala, my library of music operations, constructions...

The previous version of Bala was tied to HNotate which is now obsolete (superseded by Mullein). I'll try to be a bit more stringent with the new version, for instance the Pitch module is built on Conal Elliott's VectorSpace so it supports reasonable subtraction of Pitches to make an Interval, addition of Pitch + Interval to make a Pitch, addition of Intervals (making an Interval).

Mullein

Copperbox revisions 760, 761 & 762.

I've deleted the original bala/Mullein (760) and renamed the new branch from bala/Mullein2 to bala/Mullein (761). Also I've added cabal files (762).

Mullein

Copperbox revision 759.

Mullein branch - the first examples now output renderable scores. There is a problem with the LilyPond score that beam groups ending with a rest beam the rest, so it looks like Bracket module will have to be improved.

Mullein

Copperbox revision 758.

More work on the ABC pretty printer in the Mullein branch.

Mullein

Copperbox revision 757.

More work on the LilyPond pretty printer. I've decided against the slightly-typed combinators that I had in Bala and HNotate a while ago to keep things simple. The new pretty printers use only Doc plus existing Mullein types like Pitch, Duration and PitchLabel.

Mullein

Copperbox revision 756.

I've started adding some output pretty printers.

Mullein

Copperbox revision 755.

I've tidied up the last two modules on the Mullein branch - LilyPondOutput and AbcOutput.

Mullein

Copperbox revision 754.

More tidying up - Bracket, Utils and Core modules done this time.

Mullein

Copperbox revision 753.

I've tidied up the Pitch and Duration modules adding modules sigs, some haddock docs and removing no longer needed functions.

Mullein

Copperbox revision 752.

I've added a note type with fingering annotations on the Mullein branch. I had to added an extra type class and change some signatures for the LilyPond rewrite functions, so the types I came up with yesterday weren't quite adequate. The changes aren't too bad though, I think I still manage to be flexible and (not too far from) simple.

Mullein

Copperbox revision 751.

I've simplified the type classes in AbcOutput and LilyPondOutput and as a whole the types and their type classes obligations now seem right. Tomorrow I'll add a note type with fingering annotations, this should go a good way to seeing if I've hit a sweet spot where the types are right and flexible enough to handle extensions.

Mullein

Copperbox revision 750.

I've revised the types for the rewrite functions so that they are now polymorphic on glyph / element type on the Mullein branch.

This means I've been able to get rid of the PitchMap class which gave fmap like access to the pitch component in glyphs etc.

Mullein

Copperbox revision 749.

This is a checkpoint commit before I change the code that works on the glyph types again. I think I can now the rewriteDuration and rewritePitch functions usefully polymorphic by following the example of monad transformer constructor classes.

The monad transformers have there arguments carefully ordered so they have made instances of the important classes - the answer type of the transformer is always the last argument (satisfying the signature of Monad) and the monad parameter m is always the next to last (satisfying the signature of MonadTrans).

Mullein

Copperbox revision 748.

I've added LilyPond percussion output to the Mullein branch.

Mullein

Copperbox revision 747.

I've changed ABC output making it a two stage process, with the first stage being a duration transformation. This now matches how the LilyPond output works.

Mullein

Copperbox revision 746.

More work on LilyPond output. Also removed setDuration from the HasDuration type class as bracketing now works without trying to split (and therefore change) durations.

Mullein

Copperbox revision 745.

I've reimplemented the LilyPond duration transformation. Unfortunately, while the new version descends into grace notes properly it is type specific on the Glyph type. I'm not sure at the moment how to make it polymorphic.

Mullein

Copperbox revision 744.

I've implemented the relative pitch transformation for LilyPond in the Mullein2 branch - though the initial octave calculation seems wrong.

Mullein

Copperbox revision 743.

I've changed the order of parameters in the glyph type to be note-duration rather than duration-note.

Mullein

Copperbox revision 742.

Changed LilyPondOutput to use MonadLib.

Mullein

Copperbox revision 741.

I've implemented new beam grouping and bar splitting functions. These versions don't attempt to split and tie a note if it is too long, though they do run in a arbitrary monad that could throw an error or log a message when metric fitting fails.

Mullein

Copperbox revision 740.

I've removed the dependency on Data-Obscura, making concrete types for Bars and Pulsations (i.e. single notes or beam groups).

Mullein

Copperbox revision 739.

Wumpus - while this weeks changes make sense, they've added up to make Wumpus too complicated. I'm taking a break from it while I think of how to simplify things.

Back to Mullein then, where I've simplified the duration data type by putting the obligation to handle tied notes on the glyph type (previously durations could be composite to represent tied notes).

Wumpus

Copperbox revision 738.

I've changed the polygon creation functions in Core.Polygon so they create the polygon at the origin rather than at a passed in point.

Wumpus

Copperbox revision 737.

Matrix transformations are working again thanks to heavy use of Type Families, it makes me wonder how I managed without them.

Wumpus

Copperbox revision 736.

I've renamed the Transformations module Transform. I'm about to make it work again and thought a shorter name would be better.

Also I've cleaned up a few more type signatures.

Wumpus

Copperbox revision 735.

I've removed the Num instances for Vec2 and Vec3 as vectors don't seem have a natural multiplication (i.e. one where vec * vec -> vec, rather dot product which produces a scalar).

Also I've improved the polar coordinate conversion code so that the range is [0,2pi).

Wumpus

Copperbox revision 734.

Big changes. I've made the geometric objects - polygon, curve, line, bounding box - parametric on point type. Previously they were parametric on unit type - i.e. the point type was fixed at Point2 a where the a was some unit - usually Double. This means it's possible to create geometric objects with polar coordinates. Maybe this isn't a massive advantage in practice but it does seem conceptually better for polygon etc. to be parametric on point rather than unit.

Unfortunately the code is now pretty messy - Picture has had the minimum changes just to get some examples working again, and transformations have stopped working. There is still quite a bit of design needs to be done on the geometric objects (deciding what can be written once and what needs type classes to accommodate different point types). More positively I'm getting the hang of type families, so some of the type signatures have been simplified.

Wumpus

Copperbox revision 733.

I've changed the internals of Picture so that it stores a list of Picture elements Paths or Labels along with there graphic attributes (colour, pen width, etc.).

This increases uniformity but creating paths and labels is somewhat cumbersome because graphic attributes have to be specified, it would perhaps be preferable if attributes could represent the change to the graphic state or no change. The later is of course what PostScript does with its graphics context and it is what Wumpus moved away from for its syntactic view of pictures. This suggests I need to find a balance between the two.

Wumpus

Copperbox revision 732.

I've changed the examples and the drawing code to use the new syntactic Picture type (Pictures are essentially lists of Paths and Labels).

Also I've done some preliminary work on grids / matrices with adressable elements. This is one of the most import features of TikZ for drawing commuting diagrams and the like.

Wumpus

Copperbox revision 731.

I've remade the Node example with a simplified Picture type where everything is a path. It looks certainly promising, although the source tree will be messy for a while as I'm having to keep around two versions of the Path module and may have to do this with other modules.

Wumpus

Copperbox revision 730.

The Path module has been moved from Core to Drawing...

I've been reading the TikZ manual and guides. In TikZ everything is a path (apart for nodes with text labels and no doubt some other exceptions that I haven't discovered yet). This is a rather profound idea as far as Wumpus is concerned. In other systems - Kamin and Hyatt's FPic, PiScript... - pictures are commands, commands that change the graphics state, extend a path etc. While paths are, of course, prominent they aren't primary, and there are a lot of commands.

Following these examples is why Wumpus is Wumpus - Writer Monad PostScript. PostScript seemed too large to work with syntactically (build an abstract syntax tree and pretty print it), so I made it a command language - write it out as you go. It was quickly apparent that working with commands is unsatisfactory for geometry, hence all the work in Wumpus.Core for points, polygons, curves etc. But I struggled to work out the vector graphics equivalent of CSG or scene graphs for 3D - how to combine elements into a larger structure.

Although the code in Drawing.Basic isn't so good, it does have a mechanism to combine elements - it uses Wumpus as is, turning geometric primitives into a stream of commands and packaging up the stream with it's bounding box as a picture. Essentially this combines elements by making them anonymous. TikZ points to another way, and one that appears to have significant advantages. Paths can be represented syntactically as algebraic types - they already are in the Core.Path module but it isn't used much. Having everything a path would make Pictures much more tangible, possibly removing the need for the Picture Reader monad that I struggled with over the last couple of days.

Wumpus

Copperbox revision 729.

I've added a quick estimator to judge em and ex sizes of PostScript fonts. Sizes are judged purely visually - there is no querying of font files.

Wumpus

Copperbox revision 728.

I've changed the Picture type to be a Reader monad (not a Writer as the commit log says).

This allows sub-pictures to be accessed as Haskell variables within a monadic action (there's a new example Node.hs which draws an arrow between two points). Points are extracted in the current frame, which can make using them rather unintuitive. I'll have to look again how I'm using frames.

Although not much code actually needed changing* to use the new Picture type, changing it was very frustrating. My first attempt tried to collapse the Wumpus PostScript writer monad into the Picture type, and I then hit a stumbling block wondering if I could only extract positions with comonads or arrows. Even the eventual solution didn't work for quite a while as I often misjudged whether or not I was within the Writer type constructor. I got pretty close to calling it a day on Wumpus.



* Now that I have the usual plethora of monad and applicative combinators plenty of code will merit changing at some point.

Wumpus

Copperbox revision 727.

I've changed to BoundingBox module as I want the bounding box of pictures to be more accessible, then I can get add functionality like TikZ's nodes.

However, because Pictures are a functional type Frame -> (WumpusM (), BoundingBox) I can't access the bounding box how I would like. I'm wondering if Picture should be a monad transformer of Writer and Reader (Reader supplies the enivronment - here a frame, and Writer supplies the output so far a string of PostScript text and the bounding box).

If I did change to a monad I could use all the tricks (applicative combinators, do notation) to get rid of some of the messy Picture $ \frm -> let ... - code in Basic.hs that has taken hold.

Wumpus

Copperbox revision 726.

The Arrow example now uses the Picture type.