Copperbox revision 1211.
I've reimplemented the repeat / repeat-alternative code for ABC. I'm working towards replacing the typeclass version of repeat syntax with one that uses concrete data types. This is the first step.
Copperbox revision 1212.
Seemingly I'd missed committing the changes to two files in revision 1211 - this commit corrects that mistake.
Wednesday, March 31, 2010
Monday, March 29, 2010
Sunday, March 28, 2010
Neume
Copperbox revision 1209.
I've simplified the beam reconstitution code by making the StaffBar and StaffPhrase types use Seq rather than lists.
I've simplified the beam reconstitution code by making the StaffBar and StaffPhrase types use Seq rather than lists.
Neume
Copperbox revision 1208.
The new beam splitting code is now in use. Unfortunately, I don't like the beam 'reconstitution' code - this has to check the beam extremities from the left and right - and I'll have to think about it some more.
Probably the StaffBar type should be a sequence rather than a list - then I have access to both ends to check the extremities and I can avoid the current complicated use of Hughes lists to avoid appends.
The new beam splitting code is now in use. Unfortunately, I don't like the beam 'reconstitution' code - this has to check the beam extremities from the left and right - and I'll have to think about it some more.
Probably the StaffBar type should be a sequence rather than a list - then I have access to both ends to check the extremities and I can avoid the current complicated use of Hughes lists to avoid appends.
Neume
Copperbox revision 1207.
I've implemented a new beam group splitting algorithm using a Data.Sequence for snoc-ing accumulator. The code seems a good bit tidier than the last attempt - though the new implementation isn't hooked up into the old code yet.
I've implemented a new beam group splitting algorithm using a Data.Sequence for snoc-ing accumulator. The code seems a good bit tidier than the last attempt - though the new implementation isn't hooked up into the old code yet.
Neume
Copperbox revision 1206.
I've slightly simplified one of the beaming codes - more simplification to follow.
I've slightly simplified one of the beaming codes - more simplification to follow.
Saturday, March 27, 2010
Friday, March 26, 2010
Thursday, March 25, 2010
Neume
Copperbox revision 1200.
Some work simplifying the Staff syntax data types (removing unnecessary newtype wrappers).
I also coded up the flat - TaggedStream - representation to where I could start experimenting with it. I didn't like it for beam grouping, so maybe a way forward is more work tidying up the beam grouping functionality, rather than a new representation.
Some work simplifying the Staff syntax data types (removing unnecessary newtype wrappers).
I also coded up the flat - TaggedStream - representation to where I could start experimenting with it. I didn't like it for beam grouping, so maybe a way forward is more work tidying up the beam grouping functionality, rather than a new representation.
Wednesday, March 24, 2010
Neume
Copperbox revision 1199.
I've changed the Core.Utils 'export' module so it doesn't export OneList. This was causing some name clashes and TaggedStream adds another list like data type.
I've changed the Core.Utils 'export' module so it doesn't export OneList. This was causing some name clashes and TaggedStream adds another list like data type.
Neume
Copperbox revision 1198.
I've changed the TaggedStream (flat tree) data type to have its shape encoded in an Element type rather than have inductive constructors. This means I can base the TaggedStream on a join list and so get cheap concatenation.
I've changed the TaggedStream (flat tree) data type to have its shape encoded in an Element type rather than have inductive constructors. This means I can base the TaggedStream on a join list and so get cheap concatenation.
Tuesday, March 23, 2010
Neume
Copperbox revision 1197.
I've added a flat representation of rose trees - TaggedStream - new levels are started with a tag like in XML but the are represented as a flat sequence of tokens with an end tag. A processing function must maintain some kind of stack to materialize the tree shape.
I'm going to see if this is easier to work with than then Staff and Markup syntax trees, which aren't working well.
I've added a flat representation of rose trees - TaggedStream - new levels are started with a tag like in XML but the are represented as a flat sequence of tokens with an end tag. A processing function must maintain some kind of stack to materialize the tree shape.
I'm going to see if this is easier to work with than then Staff and Markup syntax trees, which aren't working well.
Monday, March 22, 2010
Neume
Copperbox revision 1196.
Bar splitting for markup syntax. Unfortunately Neume is starting to look very ad hoc and bedraggled now - code is very disjoint between the full syntax (with beam groups and tuplets) and the markup syntax with just glyphs.
Bar splitting for markup syntax. Unfortunately Neume is starting to look very ad hoc and bedraggled now - code is very disjoint between the full syntax (with beam groups and tuplets) and the markup syntax with just glyphs.
Sunday, March 21, 2010
Neume
Copperbox revision 1195.
Preliminary work on fret diagrams in LilyPond output. Fret diagrams are due to be rendered as markup syntax - i.e. invisible spaces with above the staff markup annotations. This uses a simpler 'syntax' than standard staff notation - no graces, chords or beam groups - but quite a lot of the code to work with the simpler syntax is missing (e.g. bar splitting).
Preliminary work on fret diagrams in LilyPond output. Fret diagrams are due to be rendered as markup syntax - i.e. invisible spaces with above the staff markup annotations. This uses a simpler 'syntax' than standard staff notation - no graces, chords or beam groups - but quite a lot of the code to work with the simpler syntax is missing (e.g. bar splitting).
Neume
Copperbox revision 1194.
Some trivial refactorings... How I planned to handle overlays is starting to look unworkable, but I think it will be wise to clean up the code first before I try to solve that problem.
Some trivial refactorings... How I planned to handle overlays is starting to look unworkable, but I think it will be wise to clean up the code first before I try to solve that problem.
Saturday, March 20, 2010
Neume
Copperbox revision 1193.
I've changed the argument ordering for the stmap classes to what I think is a more natural style.
I've changed the argument ordering for the stmap classes to what I think is a more natural style.
Friday, March 19, 2010
Neume
Copperbox revision 1192.
I've changed the tagless style Score class to use type families rather than have repr as a functor. This should hopefully allow me to implement overlays at the same type as normal bars.
I've changed the tagless style Score class to use type families rather than have repr as a functor. This should hopefully allow me to implement overlays at the same type as normal bars.
Neume
Copperbox revision 1191.
I've renamed Core.SyntaxDoc to Core.SyntaxScore (not Core.SyntaxStaff as the commit log says).
I've renamed Core.SyntaxDoc to Core.SyntaxScore (not Core.SyntaxStaff as the commit log says).
Thursday, March 18, 2010
Neume
Copperbox revision 1190.
I'm concerned that to handle overlays, I'm going to have to make an overlay evaluator for every 'simple' evaluator as I can't see how to compose two tagless evaluators.
As a precaution, I've had a round of golf shortening all the definitions of the current tagless evaluators. So if evaluators are duplicated at least the code will be short.
I'm concerned that to handle overlays, I'm going to have to make an overlay evaluator for every 'simple' evaluator as I can't see how to compose two tagless evaluators.
As a precaution, I've had a round of golf shortening all the definitions of the current tagless evaluators. So if evaluators are duplicated at least the code will be short.
Neume
Copperbox revision 1188.
I've now implemented a tagless evaluator for outputting LilyPond from the score language.
I've now implemented a tagless evaluator for outputting LilyPond from the score language.
Wednesday, March 17, 2010
Neume
Copperbox revision 1187.
A better tagless evaluation for ABC that doesn't need the leaves of the "tree" to be pre-processed.
The code is a bit messy as I've left the old ABC evaluation machinery in place - I'll remove the redundant code in the next commit. Also I haven't looked at overlays or LilyPond yet.
A better tagless evaluation for ABC that doesn't need the leaves of the "tree" to be pre-processed.
The code is a bit messy as I've left the old ABC evaluation machinery in place - I'll remove the redundant code in the next commit. Also I haven't looked at overlays or LilyPond yet.
Tuesday, March 16, 2010
Neume
Copperbox revision 1186.
Another minor change - scores now use joinlists rather than the regular list type as joinlists allow snoc-ing (which better matches how the list was being used).
Another minor change - scores now use joinlists rather than the regular list type as joinlists allow snoc-ing (which better matches how the list was being used).
Neume
Copperbox revision 1185.
I've renamed the Score data types to reflect that they are 'images' of Bars etc. (i.e. Docs) rather than manipulatable entities. This has meant quite a lot of changes though none are significant.
I've renamed the Score data types to reflect that they are 'images' of Bars etc. (i.e. Docs) rather than manipulatable entities. This has meant quite a lot of changes though none are significant.
Neume
Copperbox revision 1184.
The examples compile again, though they don't make good use of the tagless score description yet.
The examples compile again, though they don't make good use of the tagless score description yet.
Monday, March 15, 2010
Neume
Copperbox revision 1183.
Initial work changing the score syntax into a tagless style. This has broken all the LilyPond code so all the examples except ABC_B6 have stopped compiling. The tagless style seems like the best bet to be able to perform the LilyPond relative pitch transformation across a score.
Initial work changing the score syntax into a tagless style. This has broken all the LilyPond code so all the examples except ABC_B6 have stopped compiling. The tagless style seems like the best bet to be able to perform the LilyPond relative pitch transformation across a score.
Sunday, March 14, 2010
Neume
Copperbox revision 1181.
Some work cleaning up - I need to be able to build a score that threads the last pitch form the relative pitch transformation, but the code base is a a bit too disjointed at the moment as is stopping me doing it.
Some work cleaning up - I need to be able to build a score that threads the last pitch form the relative pitch transformation, but the code base is a a bit too disjointed at the moment as is stopping me doing it.
Saturday, March 13, 2010
Neume
Copperbox revision 1180.
Repeats are implemented in LilyPond. The Bulgarian6 example doesn't perform the relative pitch transformation adequately for tunes with multiple sections, so that has to be looked at next.
Repeats are implemented in LilyPond. The Bulgarian6 example doesn't perform the relative pitch transformation adequately for tunes with multiple sections, so that has to be looked at next.
Neume
Copperbox revision 1178.
I've changed the Score types to phantom types - previously they had too much wrapping in and out of the newtypes.
I've changed the Score types to phantom types - previously they had too much wrapping in and out of the newtypes.
Friday, March 12, 2010
Neume
Copperbox revision 1177.
Finally, I think I've created a workable algorithm to output repeats in ABC. I can't yet create the syntax tree to test it though...
Finally, I think I've created a workable algorithm to output repeats in ABC. I can't yet create the syntax tree to test it though...
Neume
Copperbox revision 1176.
Another attempt at formatting repeats in ABC. Its wrong again though, as it doesn't account for tunes made from a single phrase within repeats (I've committed it for checkpoint posterity).
Another attempt at formatting repeats in ABC. Its wrong again though, as it doesn't account for tunes made from a single phrase within repeats (I've committed it for checkpoint posterity).
Thursday, March 11, 2010
Neume
Copperbox revision 1175.
Work on printing repeats in ABC. Unfortunately this work is rather complicated - whether or not some marks should be generated in the output is index sensitive - i.e. if the first bar is the start of a repeated section the begin repeat symbol should be omitted.
This commit isn't correct but its been quite a lot of work to get so far, so it bears check pointing.
Work on printing repeats in ABC. Unfortunately this work is rather complicated - whether or not some marks should be generated in the output is index sensitive - i.e. if the first bar is the start of a repeated section the begin repeat symbol should be omitted.
This commit isn't correct but its been quite a lot of work to get so far, so it bears check pointing.
Wednesday, March 10, 2010
Neume
Copperbox revision 1173.
Potential new way of dealing with overlays - concatenated Doc's.
I'm not sure overlays need to be manipulated after all, so it seems that, rather than make them a list of one-or-more "bars" then print them interspersing the overlay separator (&), I can concatenate them as docs with the overlay separator instead.
Note - LilyPond is a bit more convoluted as overlays must form a proper 2D matrix, with the same number of overlays in each bar even if the overlay is empty.
Potential new way of dealing with overlays - concatenated Doc's.
I'm not sure overlays need to be manipulated after all, so it seems that, rather than make them a list of one-or-more "bars" then print them interspersing the overlay separator (&), I can concatenate them as docs with the overlay separator instead.
Note - LilyPond is a bit more convoluted as overlays must form a proper 2D matrix, with the same number of overlays in each bar even if the overlay is empty.
Monday, March 8, 2010
Neume
Copperbox revision 1172.
I've added a datatype to represent One-or-Many. I think I'm going to need this structure when I amalgamate bars to produce either One bar or Many voice overlays.
I've added a datatype to represent One-or-Many. I think I'm going to need this structure when I amalgamate bars to produce either One bar or Many voice overlays.
Saturday, March 6, 2010
Friday, March 5, 2010
Neume
Copperbox revisions 1166, 1167, 1168 & 1169.
More revisions to the module hierarchy - moving more code into Extras (most of the 'document' generating pretty printers for LilyPond and ABC), and moving utility code into Core.Utils.
More revisions to the module hierarchy - moving more code into Extras (most of the 'document' generating pretty printers for LilyPond and ABC), and moving utility code into Core.Utils.
Neume
Copperbox revisions 1163, 1164 & 1165,
I've split Neume into two file hierarchies Core and Extra - and at some point I'll split it into two projects like Wumpus-Core and Wumpus-Extra, it was getting too big as a single project.
I've split Neume into two file hierarchies Core and Extra - and at some point I'll split it into two projects like Wumpus-Core and Wumpus-Extra, it was getting too big as a single project.
Neume
Copperbox revision 1162.
I've added a class for BeamExtremity to Neume. Mullein had a similar class, which applicable to glyph representations. Glyphs for notes or chords are allowed to start and end a beam group, glyphs for rests cannot.
I've added a class for BeamExtremity to Neume. Mullein had a similar class, which applicable to glyph representations. Glyphs for notes or chords are allowed to start and end a beam group, glyphs for rests cannot.
Thursday, March 4, 2010
Wednesday, March 3, 2010
Neume
Copperbox revision 1159.
I've moved some code out of Bracket into a new module TreeOps (for PletTree utility functions).
I've moved some code out of Bracket into a new module TreeOps (for PletTree utility functions).
Neume
Copperbox revision 1158.
I've sorted the LilyPond relative pitch problem - it was a minor error in the stmap transformation step. Also I've added document construction code to the B6 example so it now outputs renderable LilyPond and ABC scores.
I've sorted the LilyPond relative pitch problem - it was a minor error in the stmap transformation step. Also I've added document construction code to the B6 example so it now outputs renderable LilyPond and ABC scores.
Tuesday, March 2, 2010
Neume
Copperbox revision 1157.
I can get output from Neume at last!
Unfortunately the generated LilyPond is wrong - the relative pitch transformation is not working. So still a lot to be done...
I can get output from Neume at last!
Unfortunately the generated LilyPond is wrong - the relative pitch transformation is not working. So still a lot to be done...
Neume
Copperbox revision 1156.
I've added a prototype of the new beam algorithm. Because note-lists are now a fairly unwieldy shape to handle tuplets (a forest - i.e. a list of trees), it is not as precise as previous versions of the algorithm - e.g. its possible to have rests ending a beam group in some cases. But I think it is good enough.
Unfortunately the new beaming uses different data types to the CExpr (context expressions) that I had previously implemented so adding beaming fully will mean changing the all the LilyPond and ABC pretty print code.
I've added a prototype of the new beam algorithm. Because note-lists are now a fairly unwieldy shape to handle tuplets (a forest - i.e. a list of trees), it is not as precise as previous versions of the algorithm - e.g. its possible to have rests ending a beam group in some cases. But I think it is good enough.
Unfortunately the new beaming uses different data types to the CExpr (context expressions) that I had previously implemented so adding beaming fully will mean changing the all the LilyPond and ABC pretty print code.
Monday, March 1, 2010
Neume
Copperbox revision 1155.
I've added pretty printers for many of the data structures - with the wrapped lists / forests making the new note list data type, it was getting hard to see the elements inside it.
I've added pretty printers for many of the data structures - with the wrapped lists / forests making the new note list data type, it was getting hard to see the elements inside it.
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.