Vexflow: Poor horizontal spacing - Basic combinations of durations are very uneven

[Silverwolf90]

Examples:

[Silverwolf90]

Worth looking at this:

"Algorithms and Data Structures for a Music Notation System based on GUIDO Music Notation"
Specifically the section starting on page 85: "Spacing, Line Breaking, and Page Filling'
http://tuprints.ulb.tu-darmstadt.de/epda/000265/kai_renz_diss.pdf

[0xfe]

Ugh... not sure why that's happening. I'll look into it.

[0xfe]

Okay, I think I know what's going on.

[0xfe]

I've got a better formatter coming -- doesn't fix this specific issue, but does fix a lot of other ones. Also, it's much simpler.

[0xfe]

I pushed a new formatter that works much better, but there's still a fundamental issue with symmetry when you have to align voices that have overlapping odd rhythms. I have two ideas for algorithms to deal with this -- one is a simple iterative technique, but slow, and the other is quite complex, but fast. :-/

I need to think this through a bit.

[Silverwolf90]

It's quite a hard problem.

I think lilypond uses a constraint solver for horizontal spacing.

Some PDF's are available that describe algorithms:

"An Improved Algorithm for Spacing a Line of Music"
http://quod.lib.umich.edu/cgi/p/pod/dod-idx/improved-algorithm-for-spacing-a-line-of-music.pdf?c=icmc;idno=bbp2372.2002.097

"A New Algorithm for Horizontal Spacing of Printed Music"
http://quod.lib.umich.edu/cgi/p/pod/dod-idx/new-algorithm-for-horizontal-spacing-of-printed-music.pdf?c=icmc;idno=bbp2372.1995.032

Taken from earlier, same author as previous link:
"Algorithms and Data Structures for a Music Notation System based on GUIDO Music Notation"
Specifically the section starting on page 85: "Spacing, Line Breaking, and Page Filling'
http://tuprints.ulb.tu-darmstadt.de/epda/000265/kai_renz_diss.pdf

[0xfe]

Thanks, I was just reading the section from the first PDF you sent (thanks!) I noticed that the current spacing algorithm performs a little like the Sibelius example (which isn't great.)

Sibelius

Vexflow

[0xfe]

I added some code to export and plot formatter decisions, in particular the gaps between ticks, which I'm going to use this to build the iterative algorithm. This specific test has about 82 pixels of freedom in aggregate, and we should be able to redistribute those pixels to format the notation more evenly.

Also note that this is a particularly complex case -- typical cases should have more pixels of freedom.

[0xfe]

I got the iterative formatter working. It's not perfect, but it's much better:

Before

After

Progression

Here you can see how the loss is reduced through each iteration. (Higher loss = uglier.)

[Silverwolf90]

Awesome! That's way better!

[0xfe]

Latest update is even better, and I have a pretty good idea for dealing with the fine tuning. But there are some cases where the formatter makes things worse, and I'm looking into that.

[mscuthbert]

This looks very good from my perspective. Congrats!