Copperbox revision 2970.
More work porting code from Ochre. Plus I've added cabal files so I can build the Haddock docs - Haddock is the best way I've found for project browsing in Haskell.
Monday, April 29, 2013
Sunday, April 28, 2013
Wednesday, April 24, 2013
data-aviary-0.4.0
Copperbox revision 2966.
I've made a new release of data-aviary for Hackage. This improves the Haddock docs and removes the "utility" module of favoured combinators - Data.Aviary is not recommended as a linkable library.
I've made a new release of data-aviary for Hackage. This improves the Haddock docs and removes the "utility" module of favoured combinators - Data.Aviary is not recommended as a linkable library.
Tuesday, April 23, 2013
data-aviary
Copperbox revision 2965.
More work on Haddock docs. Because Arrows, Monads and Comonads and their standard operations introduce data objects Pairs, Sums, Monoids, Lists... there are lots of functions that seem to merit no more explanation than their type signatures.
More work on Haddock docs. Because Arrows, Monads and Comonads and their standard operations introduce data objects Pairs, Sums, Monoids, Lists... there are lots of functions that seem to merit no more explanation than their type signatures.
Saturday, April 20, 2013
data-aviary
Copperbox revision 2964.
I've reactivated this library thanks to a patch from Christopher Young that corrected some typos in the Haddock. It merits some further improvements to the documentation before I upload it to Hackage, but the old version on Hackage needs replacing as it doesn't indicate strongly enough that the library is for reference and not for importing.
I've reactivated this library thanks to a patch from Christopher Young that corrected some typos in the Haddock. It merits some further improvements to the documentation before I upload it to Hackage, but the old version on Hackage needs replacing as it doesn't indicate strongly enough that the library is for reference and not for importing.
Tuesday, April 9, 2013
majalan
Copperbox revision 2963.
I've implemented an event list that accumulates an impulse train.
Data.Map promotes insert rather than concatenate, so it is not a good candidate for accumulating the impulse train via a Writer hence the new event list threads it as State.
I've implemented an event list that accumulates an impulse train.
Data.Map promotes insert rather than concatenate, so it is not a good candidate for accumulating the impulse train via a Writer hence the new event list threads it as State.
Sunday, April 7, 2013
majalan
Copperbox revision 2962.
I've reworked the Score objects to use a Writer or Writer+State monad as their base.
Previously each object was written as a monad from scratch, but I wanted to add an EventList that builds an Impulse Map. Because Impulse Map is a finite map (efficient insert, bad concatenation) it doesn't make a good accumulator as a Writer - it is better to thread a single map as State. Hence I need new primitives to build accumulators.
I've reworked the Score objects to use a Writer or Writer+State monad as their base.
Previously each object was written as a monad from scratch, but I wanted to add an EventList that builds an Impulse Map. Because Impulse Map is a finite map (efficient insert, bad concatenation) it doesn't make a good accumulator as a Writer - it is better to thread a single map as State. Hence I need new primitives to build accumulators.
Tuesday, April 2, 2013
Monday, April 1, 2013
majalan
Copperbox revision 2960.
Provisional work on stretch, reverse and chains.
I've now decided that instances for Stretch and SReverse must be account for their answer type, i.e. this is no longer warranted:
instead an instances must written for all answers:
This leads to a moderate code explosion but some useful answers are not reversible with SReverse instead the need to account for their delta from the time 0. This is because geometrically SReverse would be a translation of the basis to start at 0, a reflection, and traslation back to the original start point from 0.
Chains are not looking a very promising abstraction for music (whereas they have a purpose for graphics). A Chain is a finite walk over an infinite path - the ChainScheme. This makes them the wrong mechanism to model a metronome for instance - a metronome should be an infinite series of events which is evaluated within a fixed time window to make a finite event list.
Provisional work on stretch, reverse and chains.
I've now decided that instances for Stretch and SReverse must be account for their answer type, i.e. this is no longer warranted:
instance SReverse ans => SReverse (EventList u ans) where
instead an instances must written for all answers:
instance SReverse (EventList u ()) where
This leads to a moderate code explosion but some useful answers are not reversible with SReverse instead the need to account for their delta from the time 0. This is because geometrically SReverse would be a translation of the basis to start at 0, a reflection, and traslation back to the original start point from 0.
Chains are not looking a very promising abstraction for music (whereas they have a purpose for graphics). A Chain is a finite walk over an infinite path - the ChainScheme. This makes them the wrong mechanism to model a metronome for instance - a metronome should be an infinite series of events which is evaluated within a fixed time window to make a finite event list.
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.