lilypond-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

"Spanner-context" GSoC project, mentor needed


From: Urs Liska
Subject: "Spanner-context" GSoC project, mentor needed
Date: Tue, 8 Mar 2016 09:07:37 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1

Hi devs,

we have a potential student looking for a GSoC project
(http://lists.gnu.org/archive/html/lilypond-devel/2016-03/msg00006.html
and following messages). He has expressed interest in the "Allow
spanners to cross voices" project where I am listed as
potential/secondary mentor. However, I have said that I can't provide
that service without at least one primary mentor who feels fully qualified.

As probably not everybody is really up to date with that project I'll
outline a few things about it below. I would be really glad if someone
steps up, if not to volunteer as mentor then at least to discuss the
project and possible implementation approaches.
It may happen that we'll have more applications than slots this year,
but it would be unacceptable to prevent an application due to lack of
mentorship.

Problem:
Spanners (dynamics, curves, text spanners etc.) have to be contained
(i.e. start and end) in one voice. This doesn't reflect musical reality
for all inherently polyphonic instruments. Additionally it is a PITA
when working with combined parts.

Solution:
We have to find a way to make LilyPond recognize spanners that cross
voices/contexts. This would make the ugly hacks with hidden voices obsolete.

Note:
This is *not* related to the engraving, as this already works properly
(when the hidden voice is applied), so it is only related to *parsing*
the input.

Possible approaches:

  * Let the beginning of the spanner specify a (named) target context
    for the end of the spanner
  * Give the spanner an ID that can be specified at the beginning and
    the end

I would suggest to implement both approaches and let the user choose
which is appropriate for the given document. In particular I would like
to see the ID approach implemented as part of this GSoC project because
we'll need that for other purposes as well: enabling the
edition-engraver to address items by ID and engraving from MusicXML/MEI.

Urs



reply via email to

[Prev in Thread] Current Thread [Next in Thread]