payasan

Today's commit (there will only be one) is very trivial but I want to a green mark on GitHub ticker which has otherwise been staying white.

I've mixed feelings about Score(s) being the output from Payasan. I always wanted Payasan to be flexible and be able to generate fragments of Scores but for a lot of use cases generating Scores is the thing. So I've changed the output types from ABCFile and LyFile to ABScore and LyScore. Using File as a suffix was a cop out.

payasan - towards removing SectionInfo

Today's commit was trivial because I'm working up to removing SectionInfo but I'm reluctant to do it without spending time designing a replacement with pen and paper.

SectionInfo should be removed because it is indiscriminate and labels Sections with misleading information - Sections in percussion notation always stored (but didn't write) key information. All Sections stored BPM and (ABC) Unit Note Length regardless of whether they used the MIDI or ABC backends.

I'm not sure how to do this - adding another parameter to the Section type is unattractive, it is already polymorphic on pitch, duration and (LilyPond) annotation. As Sections are named, section info could be stored in a map in the header of a Part but this "disperses" information away from where it is created. The latter may provide a means of having independent section info for multiple backends, though.

Payasan

I've added LilyPond examples generated from "version 1" - i.e. before the current refactor - to the _samples folder.

As the "domain specific" extensions to Payasan are broken (and have been for a long time), I think I should at least mark what they were capable of as their re-implementation may still be some time away.

Also, as evidenced, I've decided to reactivate this blog for commenting on commits to GitHub. I think I had lost some purpose by reducing things to single lines accompanying "git commit".

Payasan notes - breakage

I've decided to remove a number of broken modules from Payasan. Although most of the examples were a long time broken, this removal means they are unlikely to be reactivated. As part of a refactor this seems a bad thing to do (I wouldn't have done it if I wasn't Payasan's sole developer) but having them around was a hindrance to working out what the higher level pieces (Chordmode, Fret diagrams, etc.) should look like to a user.

A somewhat ambivalent detail - the current refactor of Payasan has taken longer than the development of the initial version.

Payasan notes - notelists and eventlists

Although it's non-standard and personal, I think the idea of distinguishing between notelists and eventlists is valuable. Promoting this distinction is one of the main reasons for the current (and long) refactor of Payasan.

A notelist in Payasan is tiled - remember the slogan "no gaps, no overlaps". More widely, staff notation and "time box" drum notation are tiled music representations. Tiled representations enjoy conciseness.

An eventlist explicitly features time - the onset time and duration of events. Overlaps and gaps are inherent as events have no responsibilty to be contiguous. Csound scores and MIDI are examples, as are "track views" in digital sound editing programs.

Payasan notes - Concatenation vs. Extension

Classically constructive combinator libraries favour concatenation [1] - pretty printing is the obvious example: composition operators are functions Doc -> Doc -> Doc or their many-to-one, list equivalents [Doc] -> Doc. The Monoid typeclass is a fundamental part of Glasgow Haskell's standard libraries. When things don't fit Monoid, a standard exception is that they have more than one "plus" operation; pretty printing has two obvious versions of plus - vertical and horizontal concatenation.

However concatenation is not always the the most natural way to construct things. Sometimes extension feels more appropriate. Andy Gill's Graphiz/Dot and Oleg Kiselyov's SXML combinator libraries are compelling examples. In Dot, graphs are built in a monad which enables binding of fresh node ids and the subsequent use of these ids to construct edges. XML pages follow a tree structure - adding and extending leaves is natural whereas concatenating them is unusual and would demand a novel API.


[1] "Constructive" here means combinator libraries that construct something, e.g. a Doc in pretty printing or music (MIDI) in vintage Haskore. This is a loose term and can include, for example parser combinators. Whilst parser combinators process input, a user still builds a parser by concatenating smaller ones together.

payasan notes

Clocktime representation - a representation where timing (duration, onset) is represented by some real number and could support some notion of e.g. scaling.

The clock may commonly be seconds but it could be e.g. MIDI ticks.

Metrical representation - a representation where timing (duration) is represented by a symbolic value denoting a metric unit (e.g a quarter note) possibly dotted.

A metrical representation, like staff notation, can be thought of as tiled - no gaps (rests are concrete objects within the representation), no overlaps. Onset is implicit due to tiling. A metrical representation is expected to easily support concatenation.