GSoC tie formatting project (was: Google Summer of Code 2015)

[Janek Warchoł]

Hello,

2015-03-12 2:07 GMT+01:00 Janek Warchoł <address@hidden>:
> Long time ago I have collected all of my research concerning ties in a
> repository on github:
> https://github.com/janek-warchol/tie-crusade
> I suggest that you take a quick look at it (follow the first paragraph
> of the README) to get an overview of the task at hand.  It probably
> needs some cleanup - I'll review and update it over the next two days.

Sorry for delay!
Today I've cleaned the repo up a bit and thought about the problem in depth.

Overall, the repository talks about two quite separate tie issues:
- how to support cross-voice ties, enharmonic ties, ties over a
clef/staff change and other weird constructs, i.e. how to represent
these situations internally and what syntax should be used for
inputting them,
- formatting ties: given two noteheads that should be connected with a
tie, how the tie should look like.

I think that your GSoC project should be solely about the second part.


2015-03-13 20:43 GMT+01:00 Georgy Frolov <address@hidden>:
> Yes, I've built the sources from the git repository (this wasn't much
> of an achievement, it 'just worked' with automake), and have been
> fooling around a bit with parameters in tie formatting -- just to
> learn what's going on. Honestly, can't say that I love the algorithm,
> it seems somehow overcomplicated and difficult to control.

Indeed.  The more I think about it, the more I'm convinced that we
need to ditch most of the old code.  I believe that we need a
relatively simple algorithm, with more or less linear control flow,
instead of a heuristic that calculates multiple tie variants and
scores them.

I think we should start by pinning down the control flow - both inside
the tie formatting algorithm itself and between this and the rest of
LilyPond.

Concerning internal control flow: it appears to me that a tie can be
characterized by 4 parameters: direction (upward/downward), height,
tips' vertical coordinates and tips' horizontal coordinates.  We need
to find answers to the following questions:
- are there any cyclic dependencies, and what can we do to break them?
- in what order should these parameters be calculated?
- how formatting ties connecting single notes differs from formatting
ties connecting chords?
- maybe we should pick a different set of characteristics to represent a tie?

As for the global control flow, the questions I see are:
- what we need to know before calculating tie?
- what decisions we cannot make until we have decided how the ties
will look like?
- can we treat tie formatting as one operation?  Is there anything
that we must calculate after some characteristics of the ties are
determined, but before others?  In particular, what about augmentation
dots and accidentals?

I'll go over the examples in the repository asking myself these questions.

After that we'd figure out the implementation details (i.e. how to
calculate each parameter - assuming that calculating them one by one
will be possible).

What do you think?

One thing that's not clear for me yet is how much of this thinking
should be done during the preparation of the project proposal, and how
much will be part of the GSoC project itself.

> I will have
> more time now on the weekend to look at your patch and play with the
> code, and hopefully will then be ready for a more specific discussion
> :)

Did you manage to run regression test comparison with my patch?

best,
Janek