uliska/collaborative-lilypond-editing

Proof-of-concept project on collaborative music editing using LilyPond

collaborative-lilypond-editing's Issues

Coding style

What do we do about coding style conventions?

While it seems overly complex to agree upon coding styles for such a small project, this is in general of course very useful.

While not wanting to interfere too much, there are a few things that should be defined especially in the context of git collaboration:
Basic requirement is to have as much as possible in single code lines (for the versioning to work smoothly). I think this is also a good coding convention in general.
So I suggest the following conventions:

• Each measure starts on a new line with no extra indent
• Each measure should be preceded by a one line comment with the measure number (I find it extremely problematic reading sources by others which don't contain enough measure numbers)
• If it is necessary to deviate from the one-measure-one-line rule (e.g. with polyphonic or tuplet constructs that span more than one measure) all following lines should be indented by at least four spaces. If possible insert one line measure number comments anyway.
• barNumberChecks should also be in a single line (maybe with a zero indent to make them stand out)
• complex tweaks (e.g. function calls with parameters) should be placed in single lines. This means: start the measure on a new line, insert a newline and additional indentation, write the tweak, add a newline and continue the measure with the extra indentation.

This is a set of general coding rules that doesn't interfere with concrete coding preferences.
What do you think?
Of course in bigger projects it would be useful to add further specifications

Define a set of Labels

The default Issue Labels that github offers aren't very suitable for our purpose which seems to differ from software development in this respect.
So we should think about a set of Labels that seem to make sense for us.

• I added a todo Label, meant for smaller things that just have to be done and that aren't real "issues". The issue tracker then can be used to assign/track these task to specific people.
• Is duplicate really useful for LilyPond work (contrasting software development)?
• bug is too generic, I think. But as one can combine different Labels it should do.
• As for more fine-grained bug categories I suggest:
  • musicalcontent for anything relating to musical errors (like wrong notes, bad voice assignment etc.)
  • engraving for anything related to issues with LilyPond's output, i.e. things that have to be tweaked manually
  • Should these be represented by even more Labels or should one keep the number of Labels lower?
• Issue Labels can be relevant for different things:
  • musical input
  • problems with LilyPond's output
  • arrangement of the source tree as a whole

I think there are more useful Labels to find.
For now we should agree upon a set, but stay free to add more in later stages of the project.

Write Project Description

The project description has practically been agreed upon in an email thread.
It should however be put explicitely in the README file of this github project

Sum up coding conventions and include it in README

Sum up the discussion in #9 (and maybe the referenced email discussion)

Complete header

Complete the header information.

I'll do this because I'm probably the one who is most 'into' these issues

Next plan

Next time we'll 'meet' I suggest doing the following:

• Editor A enters music (with errors) and pushes every few measures
• Editor B cleans up immediately after that
• If there is an editor C around he/she can 'amend' this music with arbitrary dynamics/articulations (as a romantic editor would have done)

A and B should work smoothly, C could cause conflicts ...

Complete entering of vocal line

Complete the entering of the vocal line.
Please switch to heidenroeslein.ly and edit in the respective variable in the master file.

I suggest putting stanzas 2 and 3 in separate markup blocks at the end of the score.

Enter Piano left hand

Enter the music of piano left hand (directly into heidenroeslein.ly)

Correct vocal line

The vocal line and the lyrics have severe typos ATM ;-)

Prepare and enter piano-centered dynamics

Enter the (very few) piano-centered dynamics.

To be able to do so the assignee has to adapt the \score block and also add a variable definition.

Octavation of piano left hand bars 1 to 4

Bars 1 to 4 of the piano left hand are an octave too low.

Enter Piano right hand

Enter the music of the Piano right hand (directly into heidenroeslein.ly)