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.
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.