Copperbox revision 2635.
I've added explicit combinators for monadic concatenation-with-spacing rather than use Conal Elliott's context monoid pattern implicitly within the Score and Note List monads.
Monday, October 31, 2011
Sunday, October 30, 2011
Saturday, October 29, 2011
new-neume
Copperbox revision 2632.
I've added a monad for top level scores, this will get a run function for the note list monad so it can accumulate its results. This means Neume will follow the nested monad pattern that I used for FMSS (FM synthesizer synthesizer) in the summer.
I've added a monad for top level scores, this will get a run function for the note list monad so it can accumulate its results. This means Neume will follow the nested monad pattern that I used for FMSS (FM synthesizer synthesizer) in the summer.
Thursday, October 27, 2011
new-neume
Copperbox revision 2631.
I've added preliminary support for beam grouping. This has forced a change of representation as beam groups in LilyPond don't enclose the whole group instead the first note of the group is outside the bracket. e.g a [c d e]
I've added preliminary support for beam grouping. This has forced a change of representation as beam groups in LilyPond don't enclose the whole group instead the first note of the group is outside the bracket. e.g a [c d e]
Wednesday, October 26, 2011
new-neume
Copperbox revision 2630.
I've extended the LilyPond monad so it can handle printing absolute or relative pitches. In the old version of Neume, this was a transformation mapped over the input notelist. In the new version this is a change to the rendering environment cf. local in the Reader monad.
Note - not enough code is in place at the moment to actually demonstrate the above.
I've extended the LilyPond monad so it can handle printing absolute or relative pitches. In the old version of Neume, this was a transformation mapped over the input notelist. In the new version this is a change to the rendering environment cf. local in the Reader monad.
Note - not enough code is in place at the moment to actually demonstrate the above.
Tuesday, October 25, 2011
neume
Copperbox revision 2629.
I've started a new revision of Neume - I was going to wait until I had more time at the Christmas holidays to do this but I got itchy feet...
Instead of building a syntax tree, transforming it and printing it; I'm going to see if I can use only monadic building (no transformation). This means that you have to be very cognisant of what you are building (you can easily build junk) but it may be less brittle than previous versions which struggled to cope with LilyPond's wild syntax. LilyPond's syntax is not at fault - music notation has had a thousand years to develop a truly unwieldy grammar.
I've started a new revision of Neume - I was going to wait until I had more time at the Christmas holidays to do this but I got itchy feet...
Instead of building a syntax tree, transforming it and printing it; I'm going to see if I can use only monadic building (no transformation). This means that you have to be very cognisant of what you are building (you can easily build junk) but it may be less brittle than previous versions which struggled to cope with LilyPond's wild syntax. LilyPond's syntax is not at fault - music notation has had a thousand years to develop a truly unwieldy grammar.
Monday, October 24, 2011
wumpus-basic
Copperbox revision 2628.
I've now removed the Wumpus.Basic.Geometry modules.
In a nutshell, I don't want to be in the business of developing a geometry kernel - when I need geometric operations I can define them where they are used (as I'm doing now in Wumpus-Drawing). Also, the actual code in Basic.Geometry was often of a low standard - not providing such code as a public API is sensible.
I've now removed the Wumpus.Basic.Geometry modules.
In a nutshell, I don't want to be in the business of developing a geometry kernel - when I need geometric operations I can define them where they are used (as I'm doing now in Wumpus-Drawing). Also, the actual code in Basic.Geometry was often of a low standard - not providing such code as a public API is sensible.
Sunday, October 23, 2011
wumpus-drawing
Copperbox revision 2627.
I've removed the last dependency on Wumpus.Basic.Geomoetry - from the anchor dots.
Note - Anchor dots will need reworking at some point as they aren't very good.
I've removed the last dependency on Wumpus.Basic.Geomoetry - from the anchor dots.
Note - Anchor dots will need reworking at some point as they aren't very good.
wumpus-drawing
Copperbox revision 2626.
More work towards deprecating Wumpus.Basic.Geometry - now none of the shapes depend on it.
I've found another bug in the intersection code. This time it is with straight line / path intersection, which I thought was working (yesterdays problem was with Beziers which I was already dubious about). Both problems are still unresolved.
More work towards deprecating Wumpus.Basic.Geometry - now none of the shapes depend on it.
I've found another bug in the intersection code. This time it is with straight line / path intersection, which I thought was working (yesterdays problem was with Beziers which I was already dubious about). Both problems are still unresolved.
Saturday, October 22, 2011
wumpus-drawing
Copperbox revision 2625.
More work deprecating Wumpus.Basic.Geometry from the Shapes.
Unfortunately I've found another bug in the Path intersection code, specifically in the intersection of a ray and and a Bezier curve. I'll have to resolve this tomorrow.
More work deprecating Wumpus.Basic.Geometry from the Shapes.
Unfortunately I've found another bug in the Path intersection code, specifically in the intersection of a ray and and a Bezier curve. I'll have to resolve this tomorrow.
Friday, October 21, 2011
wumpus-drawing
Copperbox revision 2624.
I've added a module to illustrate AbsPaths so that the Bezier control points can be printed, for instance.
At the moment it is very primitive with just one illustration function.
I've added a module to illustrate AbsPaths so that the Bezier control points can be printed, for instance.
At the moment it is very primitive with just one illustration function.
Thursday, October 20, 2011
wumpus
Copperbox revision 2623.
I've properly implemented ellipse trails - as cw or ccw semi-ellipse trails in Wumpus-Basic and then as incline and shape trails in Wumpus-Drawing.
I've properly implemented ellipse trails - as cw or ccw semi-ellipse trails in Wumpus-Basic and then as incline and shape trails in Wumpus-Drawing.
Wednesday, October 19, 2011
wumpus-drawing
Copperbox revision 2622.
I've implemented a preliminary version of an ellipse trail. To follow other trails it will have to be spilt so it can produce CW and CCW semi-ellipse trails... but this will have to wait until tomorrow.
I've implemented a preliminary version of an ellipse trail. To follow other trails it will have to be spilt so it can produce CW and CCW semi-ellipse trails... but this will have to wait until tomorrow.
Tuesday, October 18, 2011
wumpus-drawing
Copperbox revision 2621.
More work removing uses of Basic.Geometry.
I've fixed the bug noted yesterday, but I still think the Paths.Intersection module needs re-working (certainly better naming would be good).
More work removing uses of Basic.Geometry.
I've fixed the bug noted yesterday, but I still think the Paths.Intersection module needs re-working (certainly better naming would be good).
Monday, October 17, 2011
wumpus-drawing
Copperbox revision 2620.
Work on Shapes - changed Triangle and Diamond to use new intersection code for radial anchors.
The new intersection code has another bug (it had one yesterday that caused the same error in drawing). I think I'll need to rewrite it - it isn't nice code and clearly it doesn't work well, though this may have to wait until the weekend.
Work on Shapes - changed Triangle and Diamond to use new intersection code for radial anchors.
The new intersection code has another bug (it had one yesterday that caused the same error in drawing). I think I'll need to rewrite it - it isn't nice code and clearly it doesn't work well, though this may have to wait until the weekend.
Sunday, October 16, 2011
wumpus-drawing
Copperbox revision 2619.
I've re-worked the Rectangle shape so it no longer depends on Basic.Geometry.
In some ways this is not a improvement - I expect the new code is a wee bit slower and radial anchors are now found by a sweep which can fail (failure is made total by substituting the center as a fall back anchor); but, the old quadrant code is just too esoteric and needs replacing.
I've re-worked the Rectangle shape so it no longer depends on Basic.Geometry.
In some ways this is not a improvement - I expect the new code is a wee bit slower and radial anchors are now found by a sweep which can fail (failure is made total by substituting the center as a fall back anchor); but, the old quadrant code is just too esoteric and needs replacing.
wumpus
Copperbox revision 2618.
More work towards deprecating Basic.Geometry.
I've started a new module ShapeTrails with trail building functions for each shape (only circles and rectangles so far). Shapes will be able to turn these trails into paths then use the new Path.Intersection code to find border anchors.
More work towards deprecating Basic.Geometry.
I've started a new module ShapeTrails with trail building functions for each shape (only circles and rectangles so far). Shapes will be able to turn these trails into paths then use the new Path.Intersection code to find border anchors.
Saturday, October 15, 2011
wumpus-drawing
Copperbox revision 2617.
I've added a module for finding the intersection of an infinite line with a Path. This is a preliminary for removing the Geometry modules from Wumpus-Basic which only serve to find intersections but add a lot of size to the API in doing so.
I've added a module for finding the intersection of an infinite line with a Path. This is a preliminary for removing the Geometry modules from Wumpus-Basic which only serve to find intersections but add a lot of size to the API in doing so.
Friday, October 14, 2011
wumpus-drawing
Copperbox revision 2616.
Following yesterday's comment, I've implemented an adaptor function so BoxConnectors can use InclineTrails and changed the existing box connectors to use it.
Following yesterday's comment, I've implemented an adaptor function so BoxConnectors can use InclineTrails and changed the existing box connectors to use it.
Thursday, October 13, 2011
wumpus-drawing
Copperbox revision 2615.
I've changed the BoxConnector API so it follows the same instantiation pattern as path connectors (the instantiation is modelled after Parsec's Token module though it is a bit different).
Doing this, I realized box connectors cannot reuse the library of "box" incline trails as the incline trails don't account for spacing (rightfully so). I'll have to write an adaptor function for box connectors to overcome this.
I've changed the BoxConnector API so it follows the same instantiation pattern as path connectors (the instantiation is modelled after Parsec's Token module though it is a bit different).
Doing this, I realized box connectors cannot reuse the library of "box" incline trails as the incline trails don't account for spacing (rightfully so). I'll have to write an adaptor function for box connectors to overcome this.
Wednesday, October 12, 2011
wumpus-drawing
Copperbox revision 2614.
I've reformulated above and below connectors.
Whereas CatTrails have to heed clock direction (as a CatTrail can be continued), I think connectors are free to maintain natural notions of above and below. The code isn't well tested at the moment so this is only a supposition...
I've reformulated above and below connectors.
Whereas CatTrails have to heed clock direction (as a CatTrail can be continued), I think connectors are free to maintain natural notions of above and below. The code isn't well tested at the moment so this is only a supposition...
Tuesday, October 11, 2011
wumpus-drawing
Copperbox revision 2613.
I've wrapped Connector paths in a newtype - ConnectorPathSpec. This means they can be uniformly seeded with a single ConnectorProps record - previously they could be seeded with properties for the rendering and the building.
I've wrapped Connector paths in a newtype - ConnectorPathSpec. This means they can be uniformly seeded with a single ConnectorProps record - previously they could be seeded with properties for the rendering and the building.
Monday, October 10, 2011
wumpus-drawing
Copperbox revision 2612.
I've added orthonormal horizontal and vertical bar connectors - there absence had been the cause of a long standing bug in one of the examples.
The ConnectorPaths module will need its naming scheme improving; the names are now getting rather silly e.g. connaorthohbar.
I've added orthonormal horizontal and vertical bar connectors - there absence had been the cause of a long standing bug in one of the examples.
The ConnectorPaths module will need its naming scheme improving; the names are now getting rather silly e.g. connaorthohbar.
Sunday, October 9, 2011
wumpus
Copperbox revision 2611.
I've finally sorted out connectors so they draw properly with respect to arms and initial spacers.
I've finally sorted out connectors so they draw properly with respect to arms and initial spacers.
Saturday, October 8, 2011
wumpus
Copperbox revision 2610.
I've tidied up the API of the Trail module in Wumpus-Basic so how it handles clock directions is now more uniform.
I've tidied up the API of the Trail module in Wumpus-Basic so how it handles clock directions is now more uniform.
Friday, October 7, 2011
wumpus-drawing
Copperbox revision 2609.
I've gone back to the simpler ConnectorPath representation of revisions 2606 and 2607. I think I can represent ConnectorPaths quite a bit simpler than yesterday's work if I account for spacing and arm length in the path building function rather than tie in the SpacingProjection functions.
Note - all the connectors in the ConnectorPath module will need re-implementing to match this intuition.
I've gone back to the simpler ConnectorPath representation of revisions 2606 and 2607. I think I can represent ConnectorPaths quite a bit simpler than yesterday's work if I account for spacing and arm length in the path building function rather than tie in the SpacingProjection functions.
Note - all the connectors in the ConnectorPath module will need re-implementing to match this intuition.
Thursday, October 6, 2011
wumpus-drawing
Copperbox revision 2608.
More work on connector spacing.
Some connectors are now drawn correctly (for the first time) regarding source and destination spacing. Some connectors are still drawn incorrectly. The new code is rather complicated... so I think all this code needs a rethink.
More work on connector spacing.
Some connectors are now drawn correctly (for the first time) regarding source and destination spacing. Some connectors are still drawn incorrectly. The new code is rather complicated... so I think all this code needs a rethink.
Wednesday, October 5, 2011
wumpus-drawing
Copperbox revision 2607.
I've fixed the bug mention yesterday with path end-points. Actually the problem was with shortening the path from the right, after this the wrong end-point was cached so querying the end point would always produce a bad result.
There are still some design issues with the new connector code - I haven't decided if "spacing" should eat into the arm length of jointed connectors; or whether arms should be measured after the spacing has been accounted for.
I've fixed the bug mention yesterday with path end-points. Actually the problem was with shortening the path from the right, after this the wrong end-point was cached so querying the end point would always produce a bad result.
There are still some design issues with the new connector code - I haven't decided if "spacing" should eat into the arm length of jointed connectors; or whether arms should be measured after the spacing has been accounted for.
Tuesday, October 4, 2011
wumpus-drawing
Copperbox revision 2606.
Work simplifying connector paths and drawing them with arrowheads.
Currently there is a bug with finding the end point of an AbsPath, I'll have to track this down tomorrow.
Work simplifying connector paths and drawing them with arrowheads.
Currently there is a bug with finding the end point of an AbsPath, I'll have to track this down tomorrow.
Monday, October 3, 2011
wumpus
Copperbox revision 2605.
I've added new enumerated types for horizontal and vertical directions. Previously code was using the Quadrant enumeration which meant cases in pattern match were being repeated if I just wanted UPWARDS or RIGHTWARDS.
I've added new enumerated types for horizontal and vertical directions. Previously code was using the Quadrant enumeration which meant cases in pattern match were being repeated if I just wanted UPWARDS or RIGHTWARDS.
Sunday, October 2, 2011
wumpus
Copperbox revision 2604.
I've reworked Drawing.Extras.Loop so it generates a Trail rather than a Point list.
This has uncovered a bug where path labels are not drawn properly - in the Automata example they seem to get drawn at the start. Any fix for this ought to address the fact that the labelling API isn't very good for starters...
I've reworked Drawing.Extras.Loop so it generates a Trail rather than a Point list.
This has uncovered a bug where path labels are not drawn properly - in the Automata example they seem to get drawn at the start. Any fix for this ought to address the fact that the labelling API isn't very good for starters...
wumpus
Copperbox revision 2603.
Work deprecating Basic.Geometry and cleaning up Drawing.Basis.DrawingPrimitives.
Basic.Geometry doesn't merit its place in Basic as it is only adding code which is used by Shapes in Drawing. As Shapes are quite difficult to implement, Basic.Geometry will probably stick around for a while but at least I'll know not to use it...
Drawing.Basis.DrawingPrimitives is adding quite a few drawing functions that aren't really merited - minor short-hands for functions that exist elsewhere. They are likely to be better off in a more expansive short-hand module that can also provide short-hands for the shapes (for example) and so won't be particularly primitive.
Work deprecating Basic.Geometry and cleaning up Drawing.Basis.DrawingPrimitives.
Basic.Geometry doesn't merit its place in Basic as it is only adding code which is used by Shapes in Drawing. As Shapes are quite difficult to implement, Basic.Geometry will probably stick around for a while but at least I'll know not to use it...
Drawing.Basis.DrawingPrimitives is adding quite a few drawing functions that aren't really merited - minor short-hands for functions that exist elsewhere. They are likely to be better off in a more expansive short-hand module that can also provide short-hands for the shapes (for example) and so won't be particularly primitive.
wumpus
Copperbox revision 2602.
I've reworked arrowheads so they use the primitive trails from InclineTrails rather than define their own drawing operations.
I've reworked arrowheads so they use the primitive trails from InclineTrails rather than define their own drawing operations.
Saturday, October 1, 2011
wumpus
Copperbox revision 2601.
Work on renovating arrowheads. I haven't made any big changes yet to tip drawing (though this needs to be done), but I've improved the look of the tips with respect to corner mitring / bevelling.
Also I've stopped retract distance being dependent on line width - while it is true that retract distance is dependent on line width it can also be dependent on bevelling, mitring etc. It seems better to handle the nuances within the drawing function for each tip.
Work on renovating arrowheads. I haven't made any big changes yet to tip drawing (though this needs to be done), but I've improved the look of the tips with respect to corner mitring / bevelling.
Also I've stopped retract distance being dependent on line width - while it is true that retract distance is dependent on line width it can also be dependent on bevelling, mitring etc. It seems better to handle the nuances within the drawing function for each tip.
Subscribe to:
Posts (Atom)
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.