Copperbox revision 2427.
I've generalized the RefTrace monad in Wumpus-Drawing so arbitrary connectors can be built, not just unary, binary and multiway (list) ones. This is a prelude to reworking Wumpus-Tree so that it can support references within a drawing. Currently it has monadic building which sort of supports references, but this is pending replacement.
Tuesday, May 31, 2011
Monday, May 30, 2011
wumpus-drawing
Copperbox revision 2426.
I've added support for upright text - this is text that calculates the vertical size of its orientation rectangle and bounding box from the baseline to the cap height (ignoring the descender depth).
In certain circumstances, accounting for descender depth can produce an ill-balanced drawing when none of the characters in the input string actually have descenders - e.g. drawing numbers within a rectangle frame produces a top heavy drawing as all the digits are the height of caps but none descend. To rectify this, I've extended the API's for PosChar and SimpleText with Up versions of the exported functions. Multi-line text doesn't suffer from this ill-balanced centering, so I haven't needed to extend the DocText API.
I've added support for upright text - this is text that calculates the vertical size of its orientation rectangle and bounding box from the baseline to the cap height (ignoring the descender depth).
In certain circumstances, accounting for descender depth can produce an ill-balanced drawing when none of the characters in the input string actually have descenders - e.g. drawing numbers within a rectangle frame produces a top heavy drawing as all the digits are the height of caps but none descend. To rectify this, I've extended the API's for PosChar and SimpleText with Up versions of the exported functions. Multi-line text doesn't suffer from this ill-balanced centering, so I haven't needed to extend the DocText API.
wumpus
Copperbox revision 2425.
DocText now has proper underline metrics (i.e. derived from AFM files). I'm not sure that visually the results are any better, but at least they aren't arbitrary.
DocText now has proper underline metrics (i.e. derived from AFM files). I'm not sure that visually the results are any better, but at least they aren't arbitrary.
wumpus-basic
Copperbox revision 2424.
Back to Wumpus as I'm getting nowhere with ZMidi...
I've added underline position and underline thickness to the metrics I extract from font files. This is so I can improve the underline handling for DocText in Wumpus-Drawing.
Back to Wumpus as I'm getting nowhere with ZMidi...
I've added underline position and underline thickness to the metrics I extract from font files. This is so I can improve the underline handling for DocText in Wumpus-Drawing.
Sunday, May 29, 2011
zmidi-basic
Copperbox revision 2423.
I've put rests back into the syntax and added a toy module experimenting with beat pattern construction. Unfortunately, the real work work has largely run into the sand - I've actually coded very similar beat pattern construction before but never found it pleasant to program with, and the objects that are nice to program with in Wumpus don't seem to have analogues for music after all.
As noted yesterday, building music isn't especially positional compared to graphics. Instead, musically objects seem more like strings that get combined and permuted then expanded (rendered) by adding more information to them - e.g. beats patterns are just strings of beat lengths that get zipped with strings of pitches to produce an output stream of notes. But this string view, whilst compact for the places where it works, often doesn't work - beat patterns can't handle triplets or half note subdivision and pitch sets can't handle accidental pitch changes outside the tones of the current scale. So I'm stuck at the same place that I was with Neume and Bala when I decided to punt them into the long grass and work on Wumpus.
I've put rests back into the syntax and added a toy module experimenting with beat pattern construction. Unfortunately, the real work work has largely run into the sand - I've actually coded very similar beat pattern construction before but never found it pleasant to program with, and the objects that are nice to program with in Wumpus don't seem to have analogues for music after all.
As noted yesterday, building music isn't especially positional compared to graphics. Instead, musically objects seem more like strings that get combined and permuted then expanded (rendered) by adding more information to them - e.g. beats patterns are just strings of beat lengths that get zipped with strings of pitches to produce an output stream of notes. But this string view, whilst compact for the places where it works, often doesn't work - beat patterns can't handle triplets or half note subdivision and pitch sets can't handle accidental pitch changes outside the tones of the current scale. So I'm stuck at the same place that I was with Neume and Bala when I decided to punt them into the long grass and work on Wumpus.
Saturday, May 28, 2011
zmidi-basic
Copperbox revision 2422.
More foundational work. I've got the first object in place Event which is the analogue of Image in Wumpus-Basic. Because representing music has more structure (syntax) than graphics, the work is rather tentative and may be heavily revised.
For graphics superimposition is perfectly fine - graphics can be stacked on top of each other and the renderer uses the "painter's algorithm" or similar to draw only what is on top. My feeling is that superimposition would work for music if my primitive composition was additive synthesis (this would be equivalent to rendering with transparency rather than strictly the painter's algorithm), but as I'm composing MIDI I have to be more careful about overlapping.
For MIDI, I solve overlapping by adding overlays and voices to the intermediate syntax. This extra syntax gives me the ability to be fairly careful about contention for note-on note-offs, but having more syntax naturally makes it more complicated to actually build music - it stops me writing an `at` combinator that enjoys the (near) universality it enjoys in Wumpus.
More foundational work. I've got the first object in place Event which is the analogue of Image in Wumpus-Basic. Because representing music has more structure (syntax) than graphics, the work is rather tentative and may be heavily revised.
For graphics superimposition is perfectly fine - graphics can be stacked on top of each other and the renderer uses the "painter's algorithm" or similar to draw only what is on top. My feeling is that superimposition would work for music if my primitive composition was additive synthesis (this would be equivalent to rendering with transparency rather than strictly the painter's algorithm), but as I'm composing MIDI I have to be more careful about overlapping.
For MIDI, I solve overlapping by adding overlays and voices to the intermediate syntax. This extra syntax gives me the ability to be fairly careful about contention for note-on note-offs, but having more syntax naturally makes it more complicated to actually build music - it stops me writing an `at` combinator that enjoys the (near) universality it enjoys in Wumpus.
Friday, May 27, 2011
zmidi-basic
Copperbox revision 2421.
I've added delta handling to the midi output monad so that program change events are only generated when they change. Currently though, volume is the only program change present so the improvements to the generated MIDI are somewhat underwhelming.
I've added delta handling to the midi output monad so that program change events are only generated when they change. Currently though, volume is the only program change present so the improvements to the generated MIDI are somewhat underwhelming.
Thursday, May 26, 2011
zmidi-basic
Copperbox revision 2420.
I've started a new project ZMidi-Basic, this is a more substantial effort that will replace ZMidi-Emit. As suggested by the name, it is patterned after Wumpus-Basic. The rationale for making a new project is that I want to implement analogues to the Wumpus-Basic drawing objects and as this requires quite a bit of scaffolding code making it might as well inherit the Wumpus-Basic directory structure.
I've started a new project ZMidi-Basic, this is a more substantial effort that will replace ZMidi-Emit. As suggested by the name, it is patterned after Wumpus-Basic. The rationale for making a new project is that I want to implement analogues to the Wumpus-Basic drawing objects and as this requires quite a bit of scaffolding code making it might as well inherit the Wumpus-Basic directory structure.
Wednesday, May 25, 2011
zmidi-emit
Copperbox revision 2419.
I've re-organized ZMidi-Emit so it is more like Wumpus-Core. Next I'll add delta to the output monad so I can make volume a property of note rather than have MIDI sys-ex messages as part of the syntax.
I've re-organized ZMidi-Emit so it is more like Wumpus-Core. Next I'll add delta to the output monad so I can make volume a property of note rather than have MIDI sys-ex messages as part of the syntax.
Tuesday, May 24, 2011
zmidi-emit
Copperbox revision 2418.
I've picked up work on ZMidi-Emit again as I would like to hear drum patterns, even though I don't think I'll integrate MIDI output back into Wumpus-Rhythm. This commit separates the General MIDI named instances into files for instruments and drums.
I've picked up work on ZMidi-Emit again as I would like to hear drum patterns, even though I don't think I'll integrate MIDI output back into Wumpus-Rhythm. This commit separates the General MIDI named instances into files for instruments and drums.
Monday, May 23, 2011
wumpus-rhythm
Copperbox revision 2417.
More work on the Abioueka example. All the drums are notated, but the drum vocabulary from the module GDgdPT isn't satisfactory. I think names based on the look of the notehead rather than the drum name are going to be more appropriate.
More work on the Abioueka example. All the drums are notated, but the drum vocabulary from the module GDgdPT isn't satisfactory. I think names based on the look of the notehead rather than the drum name are going to be more appropriate.
Sunday, May 22, 2011
wumpus-rhythm
Copperbox revision 2416.
I've changed the syntax to better accommodate accents. Unfortunately while the new syntax makes logical sense, it is harder to build in client code. Here is a current example with leadin accents:
I've changed the syntax to better accommodate accents. Unfortunately while the new syntax makes logical sense, it is harder to build in client code. Here is a current example with leadin accents:
wumpus
Copperbox revision 2415.
More work on Wumpus-Rhythm, plus I've improved the support for decorating PosObjects in Wumpus-Basic. I'd overlooked that BLC (baseline center) is not synonymous with the origin (start point) - origin is obliged to be on the baseline but it has no obligation to be at the center. Also the decoration function was miscalculating the displacement vector.
More work on Wumpus-Rhythm, plus I've improved the support for decorating PosObjects in Wumpus-Basic. I'd overlooked that BLC (baseline center) is not synonymous with the origin (start point) - origin is obliged to be on the baseline but it has no obligation to be at the center. Also the decoration function was miscalculating the displacement vector.
Saturday, May 21, 2011
wumpus-rhythm
Copperbox revision 2414.
I've cleaned up the parameter code so now only parameters that are actually used are defined. I've also made the naming a bit more uniform.
I've cleaned up the parameter code so now only parameters that are actually used are defined. I've also made the naming a bit more uniform.
wumpus
Copperbox revision 2413.
I've updated the demos in Wumpus-Drawing plus Wumpus-Rhythm and Wumpus-Tree to work with the type changes to the drawing objects in Wumpus-Basic.
I've updated the demos in Wumpus-Drawing plus Wumpus-Rhythm and Wumpus-Tree to work with the type changes to the drawing objects in Wumpus-Basic.
Friday, May 20, 2011
wumpus-drawing
Copperbox revision 2412.
Updates to work with the changes to start point in the LocImage and related types. So far the changes seem to work, but I haven't checked all the demos yet.
Updates to work with the changes to start point in the LocImage and related types. So far the changes seem to work, but I haven't checked all the demos yet.
wumpus-basic
Copperbox revision 2411.
I've potentially fixed the bug identified this morning where layout (start point) was incorrectly scaled for drawings with contextual units. The fix I've put in was a lot less onerous than I was expecting which is why an a bit tentative about it - though the preliminary test works (picture below). One of the problems of Wumpus is that it generally needs an awful lot of scaffold in place before I'm happy if something is working.
I've potentially fixed the bug identified this morning where layout (start point) was incorrectly scaled for drawings with contextual units. The fix I've put in was a lot less onerous than I was expecting which is why an a bit tentative about it - though the preliminary test works (picture below). One of the problems of Wumpus is that it generally needs an awful lot of scaffold in place before I'm happy if something is working.
wumpus-rhythm
Copperbox revision 2410.
Initial work on plet brackets. Unfortunately a bug seems to have surfaced with the unit conversion code where drawings using contextual units seem to scale their start points incorrectly. I'll have to investigate this as plet brackets need smaller text than character note heads.
Initial work on plet brackets. Unfortunately a bug seems to have surfaced with the unit conversion code where drawings using contextual units seem to scale their start points incorrectly. I'll have to investigate this as plet brackets need smaller text than character note heads.
Thursday, May 19, 2011
wumpus
Copperbox revision 2409.
Work on Wumpus-Rhythm and updates this has obliged to Drawing and Basic.
Bar lines and repeats are now re-implemented for djembe drawing:
Work on Wumpus-Rhythm and updates this has obliged to Drawing and Basic.
Bar lines and repeats are now re-implemented for djembe drawing:
wumpus
Copperbox revision 2408.
I've added some extra drawing primitives to Basis in Wumpus-Drawing, this is work towards reducing the need for zapQuery in client code.
I've added some extra drawing primitives to Basis in Wumpus-Drawing, this is work towards reducing the need for zapQuery in client code.
wumpus
Copperbox revision 2407.
I've tidied up the Kernel API in Wumpus-Basic so it no longer has semigroup (OPlus) and bifunctor classes. These aren't important now that the drawing objects - Image etc. - are newtype wrapped monads. I've also generalized the Decorate type class to allow for decorations in-front-of and behind in the Z-order.
Wumpus-Drawing has been updated to work with these changes.
I've tidied up the Kernel API in Wumpus-Basic so it no longer has semigroup (OPlus) and bifunctor classes. These aren't important now that the drawing objects - Image etc. - are newtype wrapped monads. I've also generalized the Decorate type class to allow for decorations in-front-of and behind in the Z-order.
Wumpus-Drawing has been updated to work with these changes.
Wednesday, May 18, 2011
wumpus-rhythm
Copperbox revision 2406.
I've updated Wumpus-Rhythm to work with the latest versions of Wumpus-Basic and Wumpus-Drawing.
Also, I've removed the old code in the project - unfortunately I'm not going to consider MIDI output as well as graphic output. That will have to be another project.
I've updated Wumpus-Rhythm to work with the latest versions of Wumpus-Basic and Wumpus-Drawing.
Also, I've removed the old code in the project - unfortunately I'm not going to consider MIDI output as well as graphic output. That will have to be another project.
wumpus
Copperbox revision 2404.
Updates to the Haddock docs in Wumpus-Core. Really the improvement to Core is just the recent pathDirection bug fix, but as Core is such a large archive I feel a certain duty to do something to it for a Hackage release.
Updates to the .cabal files of the other Wumpus projects.
Copperbox revision 2405.
New archives for Hackage:
wumpus-core-0.51.0
wumpus-basic-0.18.0
wumpus-drawing-0.4.0
wumpus-tree-0.16.0
The major change is the redesign of the graphic objects - Image, LocImage, LocThetaImage, Connector - in Wumpus-Basic. I rather hope this is the last representation change.
Updates to the Haddock docs in Wumpus-Core. Really the improvement to Core is just the recent pathDirection bug fix, but as Core is such a large archive I feel a certain duty to do something to it for a Hackage release.
Updates to the .cabal files of the other Wumpus projects.
Copperbox revision 2405.
New archives for Hackage:
wumpus-core-0.51.0
wumpus-basic-0.18.0
wumpus-drawing-0.4.0
wumpus-tree-0.16.0
The major change is the redesign of the graphic objects - Image, LocImage, LocThetaImage, Connector - in Wumpus-Basic. I rather hope this is the last representation change.
wumpus
Copperbox revision 2403.
Updates to the demos in Wumpus-Basic - they are all working again. Also updates to Wumpus-Tree so the demo works again.
Updates to the demos in Wumpus-Basic - they are all working again. Also updates to Wumpus-Tree so the demo works again.
wumpus
Copperbox revision 2402.
I've re-implemented the previously stubbed out code in DocText. This means that all of Wumpus-Drawing is now updated to work with the changes to the graphic objects in Wumpus-Basic.
I've re-implemented the previously stubbed out code in DocText. This means that all of Wumpus-Drawing is now updated to work with the changes to the graphic objects in Wumpus-Basic.
Tuesday, May 17, 2011
wumpus-drawing
Copperbox revision 2401.
I've updated all the examples in Wumpus-Drawing to compile again. The ones that use DocText throw run-time errors and do not render - DocText is the one library module that still needs updating.
I've updated all the examples in Wumpus-Drawing to compile again. The ones that use DocText throw run-time errors and do not render - DocText is the one library module that still needs updating.
wumpus-drawing
Copperbox revision 2400.
I've updated all the library code so that Haddock will render the documentation, though this isn't a complete update as at least some of the Text code is currently stubbed. Also the demos need updating.
I've updated all the library code so that Haddock will render the documentation, though this isn't a complete update as at least some of the Text code is currently stubbed. Also the demos need updating.
wumpus
Copperbox revision 2398.
First round of updating to Wumpus-Drawing to work with the new types in Wumpus-Basic. I've updated the Shapes and Dots, plus some work on Text.
Copperbox revision 2399.
More updates.
First round of updating to Wumpus-Drawing to work with the new types in Wumpus-Basic. I've updated the Shapes and Dots, plus some work on Text.
Copperbox revision 2399.
More updates.
wumpus-basic
Copperbox revision 2397.
I've re-introduced a distinction at the type level between queries - just an answer wrt. the Drawing context - and images - graphic output and an answer wrt. the Drawing context.
This introduces some overhead as the "regular" objects (Image, LocImage, Connector...) effectively now have two definitions and instances for Functor, Monad etc. but it does seem semantically clearer.
I've re-introduced a distinction at the type level between queries - just an answer wrt. the Drawing context - and images - graphic output and an answer wrt. the Drawing context.
This introduces some overhead as the "regular" objects (Image, LocImage, Connector...) effectively now have two definitions and instances for Functor, Monad etc. but it does seem semantically clearer.
Monday, May 16, 2011
wumpus-basic
Copperbox revision 2396.
Most of the functionality is now back in place and working with the new graphic types. Padding PosObjects is outstanding - I don't like the previous API, so I'll have to think about what to replace it with.
Most of the functionality is now back in place and working with the new graphic types. Padding PosObjects is outstanding - I don't like the previous API, so I'll have to think about what to replace it with.
wumpus-basic
Copperbox revision 2395.
More work updating the drawing objects to be monadic types rather than ContextFuns. I've now updated all the objects, though some code is still commented out. decorate and elaborate now have nice overloaded definitions which is a significant improvement.
More work updating the drawing objects to be monadic types rather than ContextFuns. I've now updated all the objects, though some code is still commented out. decorate and elaborate now have nice overloaded definitions which is a significant improvement.
Sunday, May 15, 2011
wumpus-basic
Copperbox revision 2394.
Major change - I've changed the representation of drawing objects - Image, LocImage, Connector etc. - to newtype wrapped monads rather than ContextFuns.
I'd thought about doing this for a while, but felt it would obscure the fact that drawing objects are functions from Drawing Context to Prim but ContextFuns hardly made this clear either. Also, I thought it would doom me to over using type classes but the change has been agreeable so far - one new simple type class and two complicated but at least "regular" ones to handle the arity of the drawing objects.
It goes without saying that lots of code is currently broken - however the VerySimple example works correctly.
Major change - I've changed the representation of drawing objects - Image, LocImage, Connector etc. - to newtype wrapped monads rather than ContextFuns.
I'd thought about doing this for a while, but felt it would obscure the fact that drawing objects are functions from Drawing Context to Prim but ContextFuns hardly made this clear either. Also, I thought it would doom me to over using type classes but the change has been agreeable so far - one new simple type class and two complicated but at least "regular" ones to handle the arity of the drawing objects.
It goes without saying that lots of code is currently broken - however the VerySimple example works correctly.
Saturday, May 14, 2011
wumpus-drawing
Copperbox revision 2393.
I've updated the Arrowheads to use the new ArrowTip type. The new type is safer than the previous type as it doesn't fork the Drawing Context.
I've updated the Arrowheads to use the new ArrowTip type. The new type is safer than the previous type as it doesn't fork the Drawing Context.
Blogger problem...
Maybe I've lost Thursday's blog posts. Friday I couldn't post, though I still made commits to Copperbox. Today I've been waiting to see if the Thursday's posts would get restored, as they haven't so far I'm now betting they are lost.
The last three days, I've been mostly working on Wumpus-Drawing, getting the demos to work again. At the moment Arrowheads are looking problematic and I've just committed an experiment where I've changed the arrowhead type.
The last three days, I've been mostly working on Wumpus-Drawing, getting the demos to work again. At the moment Arrowheads are looking problematic and I've just committed an experiment where I've changed the arrowhead type.
Wednesday, May 11, 2011
wumpus
Copperbox revision 2384.
I've reworked the PathBuilder monad so all the state is in one data type. The previous version stored the path tip and half the drawing trace in a LocTrace monad, but this division was ungainly. Also I've updated Wumpus-Tree.
I've reworked the PathBuilder monad so all the state is in one data type. The previous version stored the path tip and half the drawing trace in a LocTrace monad, but this division was ungainly. Also I've updated Wumpus-Tree.
wumpus
Copperbox revision 2383.
Minor updates.
I've added ASCII art to Wumpus-Basic to illustrate line caps and joins - this means I won't have to look at the PostScript language guide when I need to know which is which.
Wumpus-Drawing gets a new module for primitive graphics (lines, etc.) which will get fleshed out over time. This module has to be electively imported so it can be more direct about its it naming scheme than DrawingPrimitives in Wumpus-Basic. The latter is imported globally as part of Wumpus.Basic.Kernel so it uses the dc prefix to avoid name clashes.
Minor updates.
I've added ASCII art to Wumpus-Basic to illustrate line caps and joins - this means I won't have to look at the PostScript language guide when I need to know which is which.
Wumpus-Drawing gets a new module for primitive graphics (lines, etc.) which will get fleshed out over time. This module has to be electively imported so it can be more direct about its it naming scheme than DrawingPrimitives in Wumpus-Basic. The latter is imported globally as part of Wumpus.Basic.Kernel so it uses the dc prefix to avoid name clashes.
Tuesday, May 10, 2011
wumpus-rhythm
Copperbox revision 2382.
I've re-implemented note head drawing - now using the new monad. The code seems a lot cleaner than than the previous attempt, so that's another vote for imperative turtle drawing.
I've re-implemented note head drawing - now using the new monad. The code seems a lot cleaner than than the previous attempt, so that's another vote for imperative turtle drawing.
wumpus-rhythm
Copperbox revision 2381.
Work on a new formulation of Djembe drawing using a LocTrace monad. The current code is not yet readily runnable...
Work on a new formulation of Djembe drawing using a LocTrace monad. The current code is not yet readily runnable...
Monday, May 9, 2011
slac
Copperbox revision 2380.
Work on IEEE 754 single precision floats. The previous code (copied from Kangaroo) had serious errors. It now seems to be mostly working but I need to look at NaN and infinity. Also I don't know how to get hold of the sign of signed zero...
For the task at hand, SC synthdefs seem to have padding though I'll have to investigate this. Padding excepted, I think I can now round-trip them.
Work on IEEE 754 single precision floats. The previous code (copied from Kangaroo) had serious errors. It now seems to be mostly working but I need to look at NaN and infinity. Also I don't know how to get hold of the sign of signed zero...
For the task at hand, SC synthdefs seem to have padding though I'll have to investigate this. Padding excepted, I think I can now round-trip them.
slac
Copperbox revision 2379.
Initial work on writing binary SynthDefs. Writing IEEE 754 floats seems to be failing at the moment. I've also fixed two bugs in the reader, so parsing SynthDefs seems to work.
Initial work on writing binary SynthDefs. Writing IEEE 754 floats seems to be failing at the moment. I've also fixed two bugs in the reader, so parsing SynthDefs seems to work.
Sunday, May 8, 2011
slac
Copperbox revision 2378.
I've started a new project slac - a library for communicating with Supercollider.
I don't think I can get much further with ZSyn as I'm adrift when it comes to DSP, so working with an existing synthesizer seems a more productive option. As I've just ordered the new Supercollider book, SC seems to be the natural choice for a synthesizer engine. The initial code only covers the datatypes and reading synthdef files - currently the synthdef parser has a fatal bug.
I've started a new project slac - a library for communicating with Supercollider.
I don't think I can get much further with ZSyn as I'm adrift when it comes to DSP, so working with an existing synthesizer seems a more productive option. As I've just ordered the new Supercollider book, SC seems to be the natural choice for a synthesizer engine. The initial code only covers the datatypes and reading synthdef files - currently the synthdef parser has a fatal bug.
wumpus-core
Copperbox revision 2377.
I've fixed yesterday's bamboozling bug. It was a continuity problem in the function lineDirection in Wumpus-Core. I've added special cases to handle continuity, but really the function should have a simpler formulation with just trigonometry.
I've fixed yesterday's bamboozling bug. It was a continuity problem in the function lineDirection in Wumpus-Core. I've added special cases to handle continuity, but really the function should have a simpler formulation with just trigonometry.
Saturday, May 7, 2011
wumpus
No update tody...
I haven't made an update today as I've found the strangest bug I've ever seen - Wumpus is calculating vdirection in Wumpus.Core.Geometry differently if it gets negative zero or positive zero. This is no doubt my fault for not taking enough care when using signum with floating points, but I still find it bizarre and haven't managed to fix it yet.
I haven't made an update today as I've found the strangest bug I've ever seen - Wumpus is calculating vdirection in Wumpus.Core.Geometry differently if it gets negative zero or positive zero. This is no doubt my fault for not taking enough care when using signum with floating points, but I still find it bizarre and haven't managed to fix it yet.
Friday, May 6, 2011
wumpus
Copperbox revision 2376.
I've improved the drawing of pivot paths. Previously, the drawing could produce a glitch at the pivot join if the join should have been mitred. This was because the drawing didn't actually join the two sides - now it does.
Also I've added the go vectors mentioned in the last post to Wumpus-Basic and updated Djembe drawing in Wumpus-Rhythm.
I've improved the drawing of pivot paths. Previously, the drawing could produce a glitch at the pivot join if the join should have been mitred. This was because the drawing didn't actually join the two sides - now it does.
Also I've added the go vectors mentioned in the last post to Wumpus-Basic and updated Djembe drawing in Wumpus-Rhythm.
wumpus
Copperbox revision 2375.
I've re-enabled pivot paths in Wumpus-Drawing and added some comments and deleted some commented out code in Wumpus-Basic. Also, I think I've found a more satisfying idiom for encoding path moves:
lines [go_up 20, up_right 20, go_down 60]
This encodes the moves in vector constructors once, rather than encoding them each time in Displacements, Paths etc. I don't know why I didn't spot this sooner. The only downside is that some names ("up", "down") are too valuable to be taken this library, but other names are already long enough without a go_ prefix.
I've re-enabled pivot paths in Wumpus-Drawing and added some comments and deleted some commented out code in Wumpus-Basic. Also, I think I've found a more satisfying idiom for encoding path moves:
lines [go_up 20, up_right 20, go_down 60]
This encodes the moves in vector constructors once, rather than encoding them each time in Displacements, Paths etc. I don't know why I didn't spot this sooner. The only downside is that some names ("up", "down") are too valuable to be taken this library, but other names are already long enough without a go_ prefix.
Thursday, May 5, 2011
wumpus-basic
Copperbox revision 2374.
I've re-implemented path vamps and fixed some bugs in the Path builder code.
I've re-implemented path vamps and fixed some bugs in the Path builder code.
wumpus-drawing
Copperbox revision 2373.
I've revised monadic Path building up to vamps - which I've still to work out.
All path building is now relative - though I expect to add run functions to build absolute paths. There is both a plain monad and a transformer this time.
I've revised monadic Path building up to vamps - which I've still to work out.
All path building is now relative - though I expect to add run functions to build absolute paths. There is both a plain monad and a transformer this time.
Wednesday, May 4, 2011
wumpus
Copperbox revision 2372.
I've moved the recent TraceGraphic and TraceLocGraphic modules from Wumpus-Basic to Wumpus-Drawing. Although these modules are not high-level, it seems better to have them separate from the Wumpus.Basic.Kernel modules so they can be imported individually. This limits them from polluting the global name space.
I've moved the recent TraceGraphic and TraceLocGraphic modules from Wumpus-Basic to Wumpus-Drawing. Although these modules are not high-level, it seems better to have them separate from the Wumpus.Basic.Kernel modules so they can be imported individually. This limits them from polluting the global name space.
wumpus-drawing
Copperbox revision 2371.
I've updating library code in Wumpus-Drawing to work with the API changes to Displacement in Wumpus-Basic. I haven't updated the examples yet.
I've updating library code in Wumpus-Drawing to work with the API changes to Displacement in Wumpus-Basic. I haven't updated the examples yet.
wumpus-basic
Copperbox revision 2370.
I've tidied up the Displacement API. Having multitudes of shorthand functions (move_up, etc.) wasn't actually very pleasing in client code, so they've all been removed. They are superseded by displacements parametrized by enumerations - Direction (UP, DOWN, ...) or Cardinal (NORTH, NORTH_EAST, ...).
I've tidied up the Displacement API. Having multitudes of shorthand functions (move_up, etc.) wasn't actually very pleasing in client code, so they've all been removed. They are superseded by displacements parametrized by enumerations - Direction (UP, DOWN, ...) or Cardinal (NORTH, NORTH_EAST, ...).
Tuesday, May 3, 2011
wumpus-rhythm
Copperbox revision 2369.
I've reworked the note heads again. This time the revision is major improvement, as I've implemented them as "descriptions" which are a lot more transparent. Descriptions are just records containing all the information about how to build them, which are then interpreted at runtime to build the drawing functions for note heads, flams etc.. While this is a somewhat inefficient the improvements in clarity are compelling.
I've reworked the note heads again. This time the revision is major improvement, as I've implemented them as "descriptions" which are a lot more transparent. Descriptions are just records containing all the information about how to build them, which are then interpreted at runtime to build the drawing functions for note heads, flams etc.. While this is a somewhat inefficient the improvements in clarity are compelling.
wumpus-basic
Copperbox revision 2368.
I've added the TraceGraphic writer monad to Wumpus-Basic, it was provisionally in Wumpus-Tree whilst I worked it out.
Also, I've renamed LocTrace to TraceLocGraphic. This is for consistency now that there are two similar writer style tracers plus TraceDrawing, of course.
I've added the TraceGraphic writer monad to Wumpus-Basic, it was provisionally in Wumpus-Tree whilst I worked it out.
Also, I've renamed LocTrace to TraceLocGraphic. This is for consistency now that there are two similar writer style tracers plus TraceDrawing, of course.
Monday, May 2, 2011
wumpus-tree
Copperbox revision 2367.
I've re-instated monadic drawing which allows graph links as well as tree links. The new monadic drawing is run inside a TraceDrawing, so it is more compatible with other drawing objects than the previous attempt, which itself was a TraceDrawing (and hence could only be composed with the picture operators). The new type cannot be a Graphic, so it is a special case, but it is equivalent.
A caveat - the new code is very hacky. Realizing that I needed to thread the DrawingContext without "forking" it took a lot of working out. I will clean it up tomorrow.
I've re-instated monadic drawing which allows graph links as well as tree links. The new monadic drawing is run inside a TraceDrawing, so it is more compatible with other drawing objects than the previous attempt, which itself was a TraceDrawing (and hence could only be composed with the picture operators). The new type cannot be a Graphic, so it is a special case, but it is equivalent.
A caveat - the new code is very hacky. Realizing that I needed to thread the DrawingContext without "forking" it took a lot of working out. I will clean it up tomorrow.
wumpus-tree
Copperbox revision 2366.
More re-factoring.
I've tidied up the scaling of the tree according to sibling and level distances - previously I called these parameters sx and sy but this actually caused a bug where I was taking the wrongly swapping them around for horizontally growing trees. Also, it looks like I will need two tree renderers - one for LocGraphic and one for Graphic (which allows more capabilities) - so I've done some tidying up towards this.
More re-factoring.
I've tidied up the scaling of the tree according to sibling and level distances - previously I called these parameters sx and sy but this actually caused a bug where I was taking the wrongly swapping them around for horizontally growing trees. Also, it looks like I will need two tree renderers - one for LocGraphic and one for Graphic (which allows more capabilities) - so I've done some tidying up towards this.
Sunday, May 1, 2011
wumpus-tree
Copperbox revision 2364.
I've done re-factored the Design and Base modules quite a bit, so I that they don't "leak" so many internal types. This is a prelude to looking at a better API for the top level Tree module.
Copperbox revision 2365.
More refactoring - I've unrolled the previous changes to Design and put them in Draw instead. With the previous revision Design was exporting a function where the tree design was in an intermediate form that shouldn't have been exposed.
I've done re-factored the Design and Base modules quite a bit, so I that they don't "leak" so many internal types. This is a prelude to looking at a better API for the top level Tree module.
Copperbox revision 2365.
More refactoring - I've unrolled the previous changes to Design and put them in Draw instead. With the previous revision Design was exporting a function where the tree design was in an intermediate form that shouldn't have been exposed.
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.