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.

payasan

I've been working steadily on Payasan and I've now got chord note and fret diagram output working for fret diagrams.

As GitHub counts successive commits and helpfully tells you how long your current streak is I haven't felt the need to blog here about each commit. Also while I'm happy with the progress of Payasan, I think it is going to be a highly idiomatic system (i.e. it will make sense for me, but it will be too "special case" for other users) so publicly blogging about it is not a priority.

Payasan

I've implemented "chordmode" for Payasan patterned after LilyPond's chordmode.

Chordmode is intended as an intermediate layer for working with chords - LilyPond's chordmode is a bit inscrutable at some points and I believe I have a simpler representation for building and manipulating chords.

The implementation points to quite a few horrors in the module organization of Payasan that I will need to address. I already have 70 modules in the src directory which is excessive and I'll have to do something about combining some of them.

Payasan

Most of the work is now in place for LilyPond percussion notelists. Some work on rendering is still outstanding.

Payasan

I've started to add support for LilyPond drum pitches. This work should point out what bits of Payasan need parameterizing on Pitch. The syntax is already polymorphic on pitch and duration, but so far I haven't treated the parsers and renderers systematically.

Payasan

I've implemented "full score" output for ABC and LilyPond rather than just output of note list fragments.

It is an expectation of Payasan that the output will be hand-edited after generation if the user wants to create proper scores. However, to "debug" note lists after they have been built, transformed, etc. a user needs to generate a "full score" that can be automatically rendered by LilyPond or ABC to see their work.

Payasan

I've added transformations for augmentation and diminution to the monophonic note list.

It is a key goal that Payasan should support musical transformations so having these two implemented is a nod in favour of the utility of this version of Payasan.

Payasan

I'm working towards adding debugging to the translation steps (LilyPond pitch conversion has had a bug for the best part of a week). I'm not sure what the API should be, but at least with the current temporary implementation I can see where the pitch conversion bug occurs.

Payasan

I'm working towards translating to ABC and LilyPond output via generic traversals over the Beam Syntax. This opens the door to special notations in LilyPond output like drum notes.

Payasan

I've added a very rough implementation of Humdrum-like output printing. The output is for debugging purposes (there is a problem with pitch conversion to or from LilyPond) and so doesn't attempt to properly match Humdrum: the output has to be readable (obviously) and decipherable i.e. it has to preserve information so it works for showing bugs.

Strictly following Humdrum would impede the second goal.

Payasan

I've added interval addition and subtraction as per the algorithm in Francois Pachet's "An Object-Oriented Rerpresentation of Pitch-Classes, Intervals, Scales and Chords: The basic MusES" (page 9).

Both are a bit untested, I really should write Quick Check properties and tests at some point.

Payasan

I've worked on Pitch and Intervals as a prelude to sorting out the LilyPond relative pitch transformation.

A proper set of functions to manipulate pitches and intervals should provide the tools to encode the relative pitch transformation fairly simply. My previous ad hoc attempts were just confusing.

Payasan

I've commit the initial work on supporting quasiquoted LilyPond fragments as input syntax.

Outputting LilyPond is still to do.

Payasan

I've pushed a new set of modules that implement a simpler, monophonic notelist - just notes and rests (and tuplets), no chords or grace notes.

This notelist should be able to support transformations like transposition.