Urs Liska | 27 Nov 12:57 2014

Creating PDF tooltips?

Hi all,

would it seem feasible to insert tooltip-like items in the PDF file?
I am thinking about something similar to a BalloonText that doesn't get 
printed in the PDF but which appears in the viewer on hovering.
This would be great for annotating stuff in the files.

Best
Urs
lemzwerg | 27 Nov 10:33 2014

widen multimeasure rests with numbers (issue 173280043 by k-ohara5a5a <at> oco.net)

LGTM, save a small remark.

https://codereview.appspot.com/173280043/diff/40001/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):

https://codereview.appspot.com/173280043/diff/40001/scm/define-grob-properties.scm#newcode1287
scm/define-grob-properties.scm:1287: containing a multimeasure rest, per
factor of two in its duration.")
I've seen the code, so I understand this sentence.  However, I think
that other people will stumble...  Can you reformulate this to be more
verbose?

https://codereview.appspot.com/173280043/
Dan Eble | 27 Nov 04:53 2014
Picon

Part combiner: separate split state and voice names

To those familiar with the part combiner:

I would like to break the rigid link between the split states (apart, unisilence, etc.) and the names of the
voices into which the Part_combine_iterator routes events.  I would like the Scheme portion of the part
combiner to dictate the names of the voices to use at every moment.  This probably needs to be an addition to
the split state name, not a replacement of it, but I’m not sure of that.  I expect the
Part_combine_iterator to become much simpler.

I hope that the ability to route events in new ways without having to name each combination will simplify
fixing some bugs and adding features.

If you would encourage or discourage me from this, please speak up.  I expect to experiment with it as I find time.

Regards,
— 
Dan

_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
James | 26 Nov 18:41 2014
Picon

PATCHES: Countdown for November 29th 2014

Hello,

Here is the current patch countdown list. The next countdown will be on 
November 29th.

You can always view the most current countdown list here:
http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=patch

____________________

PUSH:

Dan Eble: Patch: Add \compound-meter markup command
http://code.google.com/p/lilypond/issues/detail?id=4196

____________________

COUNTDOWN:

Keith OHara: collision rest + (accidental/notehead) with beaming
http://code.google.com/p/lilypond/issues/detail?id=472

____________________

REVIEW:

Dan Eble: Part combiner shifts or omits rests
http://code.google.com/p/lilypond/issues/detail?id=4205

James Lowe: articulate.ly: documentation issues and incorrect rendering 
(Continue reading)

Urs Liska | 26 Nov 08:02 2014

Fwd: next lilypond release

Any estimates?

-------- Original-Nachricht --------
Betreff: 	next lilypond release
Datum: 	Wed, 26 Nov 2014 14:45:50 +0800
Von: 	Jan Hakenberg <jan.hakenberg <at> gmail.com>
An: 	ul <at> openlilylib.org

Hi Urs

I have been using Lilypond since Dec 2013.
https://www.youtube.com/watch?v=YSPPoTvAFbQ

I noticed that no minor release has been issued for a long time.
If possible, can you let me know if or when an update is coming next?

thank you very much!
many greetings,
Jan
lemzwerg | 24 Nov 08:25 2014

improve initial estimate of beamed-rest position; issue 472 (issue 179320043 by k-ohara5a5a <at> oco.net)

LGTM.

https://codereview.appspot.com/179320043/diff/1/lily/beam.cc
File lily/beam.cc (right):

https://codereview.appspot.com/179320043/diff/1/lily/beam.cc#newcode1357
lily/beam.cc:1357: /* Estimate the closest beam to be four positions
away from the heads.. */
I always notice the most unimportant things, e.g. two final dots... :-)

https://codereview.appspot.com/179320043/
nine.fierce.ballads | 24 Nov 06:12 2014
Picon

Issue 4205: Improve part combiner's rest analysis (issue 174610043 by nine.fierce.ballads <at> gmail.com)

Reviewers: ,

Description:
Issue 4205: Improve part combiner's rest analysis

Rests must begin and end simultaneously to be merged into the shared
voice.

Rests, skips, and multi-measure rests are kept apart even if they
begin and end simultaneously.

This does not produce ideal output in every case, but it avoids
producing musical nonsense.

Please review this at https://codereview.appspot.com/174610043/

Affected files (+131, -4 lines):
   A input/regression/part-combine-mmrest-shared.ly
   A input/regression/part-combine-silence.ly
   A input/regression/part-combine-silence-mixed.ly
   M scm/part-combiner.scm
James Lowe | 23 Nov 16:14 2014
Picon

PATCHES: Countdown for November 26th 2014

Hello,

Here is the current patch countdown list. The next countdown will be on
November 26th.

You can always view the most current countdown list here:
http://code.google.com/p/lilypond/issues/list?q=Patch%3Apush%2Ccountdown%2Creview%2Cnew%2Cwaiting&colspec=Patch%20Owner%20ID%20Summary&sort=patch

____________________

PUSH:

Keith OHara: give partcombine an option to control merging of chords
http://code.google.com/p/lilypond/issues/detail?id=4198

David Kastrup: Partcombine warning about simultaneous breathing
http://code.google.com/p/lilypond/issues/detail?id=4099

Keith OHara: put NullVoice in Staff by default
http://code.google.com/p/lilypond/issues/detail?id=4093

Keith OHara: padding from accidental to neighbor note should be larger
than from accidental to parent note
http://code.google.com/p/lilypond/issues/detail?id=3869

Keith OHara: Issue 1798 not completely fixed
http://code.google.com/p/lilypond/issues/detail?id=3135

Keith OHara: This natural stem is too short
http://code.google.com/p/lilypond/issues/detail?id=2724
(Continue reading)

pkx166h | 23 Nov 12:24 2014
Picon

Re: Doc: NR section 3.5.x MIDI file creation tidy up (issue 120480043 by pkx166h <at> gmail.com)

On 2014/10/26 22:00:14, Trevor Daniels wrote:
> I still have a couple of difficulties with this.  It is very difficult
to see
> what articulations are represented in basic Midi output and what are
not.  Clear
> lists are needed, ideally quite early rather than buried in the
detail.  And
> information about the articulate script should not be placed in the
middle of
> sections describing basic LilyPond features.  The articulate script is
an
> optional add-on, and needs to be kept quite separate from the basic
LilyPond
> facilities and features so users not including the articulate script
(probably
> most of them) are not confused by it.  Both these changes can be
achieved quite
> easily and then your patch would be a great improvement!

> Trevor

Yes I agree. In fact the whole reason for me starting this task and it
slightly getting out of hand in terms of the amount of changes, was
because I realised we needed to re-organize this and unpick the
articulate information out of the main 'default MIDI' explanation. The
goal with regard to articulate was to inlclude the 'lists' in the ly
file itself (i.e. it is its own documentation).

Heikki has helped improve the distinctions in the last few rounds of
patch reviews (for which I am very grateful), and it seems that we are
(Continue reading)

Dan Eble | 23 Nov 05:26 2014
Picon

Alternative Quarter Rest

If I wanted a quarter rests that looks like a reversed Z, would it be acceptable to add a glyph to the Feta font,
or would I need to create my own personal font for that?

I wouldn't need it to look exactly like the attached picture, just not as conspicuously different as the
default quarter rest is.  I’d want it to look like it belongs with all the other Feta rests.

Thanks,
— 
Dan
_______________________________________________
lilypond-devel mailing list
lilypond-devel <at> gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
David Kastrup | 22 Nov 17:35 2014
Picon
Picon

Chord pipelines


Hi together,

I am currently contemplating our chord support and it appears rather
badly modularized to me.

Chords are typically generated in \chordmode.  \chordmode generates
music that basically can serve directly in staves for keyboard.

Then we have the ChordNames context.  It uses some internal functions
called via procedures stored in context properties to figure out root
and extensions of such chords.  Then there are several
language/convention dependent chord naming functions building chords.
Which components can be changed in what manner is rather hardwired.

Then we have the Fretboards context which takes a keyboard chord,
associates it with predefined guitar chords, and outputs a translated
fret diagram.  Of course, the same translation would make sense in order
to generate a score for classical guitar players (who tend to be great
at reading scores and soso at actually knowing all those chords by
name).  We don't have _any_ way to wire this chord mapping into score
typesetting, only into fret diagrams.

Now shiver me timbers, I am interested in doing chords for accordions.
Accordions have an x:7 button that is actually x:7^5 and they have a
x:dim button that is actually x:dim7^5.

Now what input would one want for those?  Arguably, x:7 and x:dim since
accordion players generally don't take the fifth regarding those chords.
To make things more confusing, there are accordions with only three
(Continue reading)


Gmane