Re: Don't wrap EventChord around rhythmic events by default. (issue 5440084)

[dak]

Reviewers: MikeSol,

Message:
On 2011/12/02 19:50:03, MikeSol wrote:
> Hey David,

> This patch is way over my head, so I can't really comment on the
details of the
> implementation, but I just wanted to voice one concern for me (and
possibly
> other) algorithmic composers.

> I have a lot of algorithms written that comb through music streams and
finagle
> with the elements.  EventChord is the bread and butter unit that most
of these
> algorithms search for and then slice & dice.

> What I'd ask is that lilypond could have an option
> (-dwrap-single-rhythmic-events-in-event-chord) that allows for this
type of
> behavior to continue.  It'll give people in my position time to
migrate code w/o
> having it completely break on us.  I'm not sure if this is feasible
given the
> current design of the patch (again, it's over my head), but around
line 765,
> perhaps keep the old syntax but use a the results from the
> -dwarp-single-rhythmic-events-in-event-chord flag in the if statement
instead of
> !is_event?

Not feasible.  The main motivation for the patch was to be able to have
sensible semantics for music functions inside of chords.  That's
incompatible with putting EventChord around everything.

The place for a compatibility hook would likely be when stuff is
collected into a (sequential or simultanous) list.  Few people
complained or even noticed when #{ ... #} did not make a sequential list
from single events.

However, displaying music expressions will then produce chorded
expressions, and c-. will then turn into <c-.> rather than <c>-. so it
is not all that clear that this kind of mode will take you all the way.

One of the problems for any change currently simply is that Lilypond has
no sensible programmer APIs to process music.  It's all hand-coded
manipulation of raw music, without any consistency or code reuse even
between different parts of Lilypond itself.

Description:
Don't wrap EventChord around rhythmic events by default.

This changes quite a number of things and required quite a few code
changes.  It is obvious that there is a lot of code duplication in
Lilypond.

A number of regtest differences show up: most of them actually
demonstrate bugs in the preexisting code base that fails to typeset
things like <c-.> with the same carefulness as c-. is typeset.  Since
c-. is no longer treated like <c>-. this becomes obvious in a number
of cases.

The part combiner has several problems, the tablature code has a few,
relying on string numbers getting lost by default does no longer work,
the fingering engraver is affected.

Displaying music obviously is no longer working; this is not a defect
of the old code but rather needs work to match the new realities.

All in all, things could be worse.

This is merely a first sketch and should at least provide for
interesting experiments.

Please review this at http://codereview.appspot.com/5440084/

Affected files:
  M input/regression/music-map.ly
  M lily/music-scheme.cc
  M lily/parser.yy
  M ly/music-functions-init.ly
  M scm/define-music-display-methods.scm
  M scm/define-music-types.scm
  M scm/modal-transforms.scm
  M scm/music-functions.scm
  M scm/song.scm