Re: added missing #inlude for use with g++ 4.7 (issue 6434048)

[mike]

LGTM - I'll push to staging if there are no objections in 24h.

http://codereview.appspot.com/6434048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Assertion failure

[mike]

On 28 août 2012, at 15:17, David Kastrup  wrote:

> "m...@mikesolomon.org"  writes:
> 
>> Hey all,
>> 
>> With --disable-optimisation passed to configure, Janek's score at:
>> 
>> www.mikesolomon.org/tota-pulchra.zip
>> 
>> fails with the assertion failure on line 252 of the current grob-property.cc
>> 
>> assert (value == SCM_EOL || value == marker);
>> 
>> I started a git bisect but have no clue when the first good commit is
>> - it hits this failure at least as far back as June 20th.
>> 
>> I'm a bit short on time but could someone do some snooping to try and
>> figure out what the problematic commit is?
> 
> Not sure it's not a case of historical nonsense.  Cf.
> 
> http://codereview.appspot.com/6449126/diff/1003/lily/grob-property.cc#newcode254>
> 
> 
> -- 
> David Kastrup
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

Neil's right (hey Neil!) that the property shouldn't be set in the user-defined 
function the way that it is currently set. I should have checked the file first.

Slightly changing subject, I'm of the opinion that no user input, however 
unconventional, should lead to an assertion failure.  When someone puts an 
assertion failure in the code, to me, it is saying "if this thing is ever 
triggered, every developer should stop what she is doing and figure out what is 
wrong with LilyPond and pull all nighters until it's fixed."  Otherwise a 
programming error seems more appropriate.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds octavation-eight-interface to the Beam_collision_engraver (issue 6475065)

[mike]

On 29 août 2012, at 16:13, d...@gnu.org wrote:

> 
> http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm
> File scm/define-grob-interfaces.scm (right):
> 
> http://codereview.appspot.com/6475065/diff/1/scm/define-grob-interfaces.scm#newcode223
> scm/define-grob-interfaces.scm:223: annotation."
> What about \clef "bass_8" or \clef "treble_15" ?
> 
> http://codereview.appspot.com/6475065/
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

Should be fine...it's the same grob (OctavateEight).
~Mike
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Replacement for backend function bezier-sandwich

[mike]

On 2012-09-17 05:01, ornello wrote:

James wrote



http://git.savannah.gnu.org/gitweb/?p=lilypond.git;a=commitdiff;h=35725a573e47be7c02c51964641ea534fb88be6b

Does this help?

james



Hmm... I see that in lookup.cc the call to the backend function
bezier-sandwich has been replaced by native PS commands. I don't find 
a
bezier drawing callback function that is called in the backend. I 
have
written my own HTML backend, and I need to react to bezier_sandwich 
calls
when drawing slurs and ties. So my question is: How do I draw slurs 
and ties

in backends that are not PS (e.g. SVG, socket, HTML, ...)?

Dominik




Dear Dominik,

They are actually commands to the path stencil - they look like native 
PS commands because they use the same lingo.  If your backend implements 
the path stencil, LilyPond should do the rest of the work for you, 
outputting slurs and ties as paths instead of bezier sandwiches.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: aux files to cache compilation info

[mike]

On 2012-09-19 05:40, Ramana Kumar wrote:


2) Create an ugly-lily.ly [1] file.  This file would remove
several engravers, change most callbacks to hardcoded values and
have everything spaced on one line unless breaks were forced and
would output the document to a huge page.  This could be used for
people doing mockups and then removed to get the nice score.


Is option 2 usable now? Is there an option for creating a mockup 
fast,

or would it be easy to create? I would use that, for example, for a
score I want to both edit quickly and read on screen, but only
occasionally render for printing on paper.



No, but if you run gprof or a similar utility on a LilyPond binary, you 
can see what callbacks hog the most time.  You can then set these with 
dummy values if appropriate (i.e. vertical-skylines = #'()) and then see 
if it slows stuff down.  I'm sure other people would be interested in 
this - if you have time to do it, it'd be of great value to LilyPond!


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Various clean-ups in stems and beams. (issue 6584045)

[mike]

On 5 nov. 2012, at 00:40, aleksandr.andr...@gmail.com wrote:

> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly
> File input/regression/kievan-notation.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/kievan-notation.ly#newcode12
> input/regression/kievan-notation.ly:12: c4 c4 c8 [ d8 ] c4 c2 b,\longa
> We should add an unbeamed eighth note to the regtest, since its correct
> appearance is now controlled by
> 
> note-head::calc-kievan-duration-log
> 
> Maybe something like
> 
> c4 c8 c8[ d8] c4 c2 b,\longa

Done

> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly
> File input/regression/note-head-style.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/input/regression/note-head-style.ly#newcode108
> input/regression/note-head-style.ly:108: \override Staff.Dots.style =
> #'kievan
> Why can't we use the new function here, e.g.,
> 
> \kievanOn
> 

\kievenOn only works on the voice level and the overrides happen on the staff 
level.

> http://codereview.appspot.com/6584045/diff/13014/ly/engraver-init.ly
> File ly/engraver-init.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/ly/engraver-init.ly#newcode1150
> ly/engraver-init.ly:1150: \override Stem.length = #0.0
> It seems like we also need something like:
> 
> \override Flag.stencil = ##f
> 
> Otherwise "flags" appear on Kievan eighth notes.
> 

True. Fixed.

> http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly
> File ly/property-init.ly (right):
> 
> http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly#newcode310
> ly/property-init.ly:310: \override Stem.length = #0.0
> Also need here:
> 
> \override Flag.stencil = ##f

Also fixed.

> 
> http://codereview.appspot.com/6584045/diff/13014/ly/property-init.ly#newcode323
> ly/property-init.ly:323: \revert Stem.length
> And here:
> 
> \revert Flag.stencil

Also also fixed.

Many thanks!  Will post on Rietveld tonight or tomorrow.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses single algorithm for side-position spacing. (issue 6827072)

[mike]

> Re: Uses single algorithm for side-position spacing. (issue 6827072)
> 
> {\clef bass
>  2..->
>  << r16 \\ r \\ r  \\ r \\ >> eeses'16
>  \set fingeringOrientations = #'(right)
>   8-1-4   r
>   r2 }
> 

Beautiful ugly test case.  Even with current master it is atrocious. I've fixed 
everything but the double-flat on rest collision, which'd require a separate 
patch.

> 
> http://codereview.appspot.com/6827072/diff/1/input/regression/dynamics-avoid-cross-staff-stem.ly
> 
> File input/regression/dynamics-avoid-cross-staff-stem.ly (right):
> 
> 
> http://codereview.appspot.com/6827072/diff/1/input/regression/dynamics-avoid-cross-staff-stem.ly#newcode14
> 
> input/regression/dynamics-avoid-cross-staff-stem.ly:14: a8 \p [ \change
> Staff = "PnRH" \stemDown gis'8 \fff ]
> Before your patch, the dynamics below the staff clear each other; after
> your patch, they collide.
> 

Fixed.

> 
> http://codereview.appspot.com/6827072/diff/1/lily/axis-group-interface.cc
> 
> File lily/axis-group-interface.cc (right):
> 
> 
> http://codereview.appspot.com/6827072/diff/1/lily/axis-group-interface.cc#newcode403
> 
> lily/axis-group-interface.cc:403: Axis_group_interface::cross_staff (SCM
> smob)
> For what situation?   Which object that supports axis-group-interface
> (PianoPedalSpanner, DynamicLineSpanner) should be potentially considered
> a cross-staff object?

NoteColumn

> http://codereview.appspot.com/6827072/diff/1/lily/box-quarantine.cc
> 
> File lily/box-quarantine.cc (right):
> 
> 
> http://codereview.appspot.com/6827072/diff/1/lily/box-quarantine.cc#newcode70
> 
> lily/box-quarantine.cc:70: return abs (ii0.index_ - mid) < abs
> (ii1.index_ - mid);
> gcc 4.5.1 complains that he cannot determine which version of the
> overloaded abs() should be called.  (Polymorphism is l33t, isn't it.)  I
> just removed the abs() calls to get it to compile, because index_ is an
> unsigned type so the arguments are always positive anyway.

index_ is always positive and mid_ is always positive but index_ - mid_ will be 
positive or negative depending on which one is larger. Changing to fabs.

> 
> 
> http://codereview.appspot.com/6827072/diff/1/lily/script-engraver.cc
> 
> File lily/script-engraver.cc (right):
> 
> 
> http://codereview.appspot.com/6827072/diff/1/lily/script-engraver.cc#newcode270
> 
> lily/script-engraver.cc:270: // we never want scripts to be tucked down
> next to stems
> This disagrees with   
> input/regression/finger-chords.ly

True - I mean Script grobs.  I'll make that clearer.

> 
> 
> http://codereview.appspot.com/6827072/diff/1/lily/stencil-integral.cc
> 
> File lily/stencil-integral.cc (right):
> 
> 
> http://codereview.appspot.com/6827072/diff/1/lily/stencil-integral.cc#newcode988
> 
> lily/stencil-integral.cc:988: pure = Rest::has_interface (me) ? true :
> pure;
> Worse than losing ledgers, the 'pure' extent is in the wrong position
> for those rests that might have been moved.
> 
> At this point in determining the layout, shouldn't you ensure that the
> rests are positioned, by testing 'positioning-done, before figuring
> their skylines for use in note-spacing ?
> 

Even this doesn't work.  It fails maybe every 5th time I compile, so it must be 
one of those uniq () sorting problems that I run into from time to time.  The 
solution for now is just to use ly:grob::vertical-skylines-from-stencil on the 
rests, which don't muddle with extents or positioning and just check the glyph. 
 But this is me going into problem-avoidance mode.  There are comments all over 
that part of the code base warning about RestColumn positioning, but a big fat 
"THIS IS A TICKING CIRCULAR DEPENDENCY TIME BOMB" comment somewhere in there 
wouldn't hurt.

> 
> http://codereview.appspot.com/6827072/diff/1/scm/define-grob-properties.scm
> 
> File scm/define-grob-properties.scm (right):
> 
> 
> http://codereview.appspot.com/6827072/diff/1/scm/define-grob-properties.scm#newcode668
> 
> scm/define-grob-properties.scm:668: (other-axis-padding ,number? "The
> amount to pad the axis
> traditionally called horizon-padding, which I suppose makes sense in the
> metaphor of a city skyline, as this padding is in the direction of the
> horizon.
> 
> 

Fixed.

Thanks for the review!  Will upload a new patch set in the not-too-distant 
future.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses single algorithm for side-position spacing. (issue 6827072)

[mike]

On 19 nov. 2012, at 03:46, Keith OHara  wrote:

> On Sun, 18 Nov 2012 12:21:51 -0800, m...@mikesolomon.org 
>  wrote:
> 
>> if (to_boolean (me->get_property ("add-stem-support"))
>>  && Stem::has_interface (e))
>> skyline.set_min_height (e->extent (common_y, _Y_AXIS)[dir]);
>> 
>> That's pseudo-code, but do you get the idea?  Does that seem reasonable?
> 
> Depends on where it goes, and of what 'skyline' is the skyline.
> 

Hey Keith,

This is implemented in my newest patchset.  I'd like it to go on a countdown 
soonish, so if you have time to give it a spin I'd appreciate it!

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Uses single algorithm for side-position spacing. (issue 6827072)

[mike]

On 30 nov. 2012, at 07:25, k-ohara5...@oco.net wrote:

> 'finger-chords.ly' is still in disagreement with its texidoc (therefore
> failing).  You could adjust that regtest in light of the new defaults,
> of course.
> 
> Better might be to make Fingering.add-stem-support = #only-if-beamed
> the new default.  That is in better agreement with common practice.
> Regtests come out just as good.  (Les-neréides.ly can remove a couple
> "tweaks", which seems to be how somebody was keeping score.)  Then users
> will less often want to override add-stem-support, and when they do it
> will be to the simpler ##f or ##t
> 
>>> The while(dirty) loop runs 2366 times for the last chord in
>>> 'fingering-collision.ly' but that's an extreme case.
>>> 
>> I'm not proud of this...
> 
> It is at least comprehensible; while the code it replaced was utterly
> baffling.  I simplified the loop
> 
> 

I'm OK w/ the simplification, but I'd like it in box-quarantine if possible.  
I'd like to separate the shifting algorithm from the class.  This is part of an 
effort, in general, to simplify and clarify the distinction between positioning 
algorithms and classes that use these algorithms (this is what I was doing w/ 
interval-minefield.cc as well).  Eventually, box-quarantine will be used for 
the ScriptColumn grob.

> You should at least put the filenames back to what they were, and adjust
> any tests or documentation or snippets using add-stem support, before
> pushing.
> 
> I started to test with real music.  The usual Chopin test case
> 
> has a badly broken cross-staff beam in measure 27.  I don't yet see the
> cause.
> 

Ugh...this is a really nasty cyclic dependency.  In the old algorithm, when Y 
side positioning was done, X extents weren't necessary because we just assumed 
that things had infinite X extents.  Now with the skylines, both X and Y 
extents are necessary to build the skylines.  The cyclic dependency is with 
beam directions.  The triggering chain is something to the effect of:

1) note_head_x_shift
2) stem direction
3) beam direction
4) pure y coordinates of stems to figure out auto knees
5) pure internal minimum translations via align interface
6) lots of pure heights in the axis group interface
7) pure heights of fingerings depend on new skyline side positioning algorithm
8) this algorithm needs the width of a note_head whose stem is attached to the 
same beam in (3) above, so note_head_x_shift
9) stem direction of the stem attached to that note
10) beam direction

The dependency seems breakable, but it'll require some mental gymnastics to 
figure out how.  I'm on it.

Cheers,
MS___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: For those who need new features and bug fixes...

[mike]

On 21 déc. 2012, at 14:01, Kieren MacMillan  
wrote:

> Hi Mike,
> 
>> I have two 16ish-hour flights this holiday season and I'll be filling them 
>> with composition, Sudoku, and LilyPond programming.  So, this is the time to 
>> send me:
>> 1) Features you need implemented.
>> 2) Bugs you need fixed.
>> 3) Things you need reviewed.
>> I'll get as many of them done as I can on the flight.
> 
> The big ones for me are:
> 
> 1. The completion of Janek's GSoC work on Lyrics. In particular, the feature 
> where the music is spaced evenly and the lyrics are adjusted automatically to 
> suit (rather than the current situation, which is essentially the opposite).
> 
> 2. Allowing a text markup (especially a MetronomeMark) to have a "minimum 
> measure length". This would avoid collisions, particularly where there are 
> lots of multi-measure rests (e.g., orchestral parts).

Hey Kieren,

A quick note to let you know that #2 is doable via a hack.  Minimum lengths can 
only work if you use spanners, but you can hijack the tempo print function for 
a text spanner (and suppress the line afterwards) and then create a scheme 
engraver for text spanner that uses whatever as the left bound and the next bar 
line's non-musical paper column as the right bound.  Or you could just use the 
existing engraver and use the last note in the measure as a bound, although 
this will potentially create uneven spacing in a measure.

You'll have to manually put this TextSpanner in the topmost context and/or use 
ly:side-position-interface::move-to-extremal-staff (I'd recommend the former, 
as the latter is powerful but falls in the category of LilyPond black magic).  
Make sure to use springs and rods and set a minimum-length - there's an example 
in the docs with a hairpin or glissando or something spanner-y that does this.

That's my not-so-subtle way of blowing you off :-) Not that it's not a good 
request (it is excellent and I'd use it!) but the solution is definitely within 
reach for many-a-schemers on this list (especially as there is a custom 
text-script engraver already in the docs somewhere). I'm gonna try to focus on 
things that need changing in the C++ or in difficult Scheme.

Happy holidays!

Greetings from 30,000 feet over Waltrop,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

outside-staff-placement-directive.ly

[mike]

Hey all,

The regtest outside-staff-placement-directive.ly is currently not doing what 
it's supposed to because of \textLengthOn, which masks the effects of the 
placement algorithm.  I must have inadvertently added that during a moment of 
sleeplessness...

I'll propose a patch fixing this unless someone sees a good reason to keep it 
this way.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Caches the interior skylines of vertical axis groups and systems. (issue 7185044)

[mike]

On 28 janv. 2013, at 06:33, Keith OHara  wrote:

> On Sun, 27 Jan 2013 01:45:16 -0800, m...@mikesolomon.org 
>  wrote:
> 
>> On 26 janv. 2013, at 23:21, k-ohara5...@oco.net wrote:
>> 
>>> The tracker says the overall goal is to remove a call to the function
>>> translate_axis.  In the example
>>> { g4\> g'_"pico"  g' g\! }
>>> when we decide to move the "pico" between hairpin and staff, the call to
>>> translate_axis records the new position in the TextScript grob itself.
> 
>> The broad goal is:
> [...]
>> 2) Move outside-staff-priority purely to the side-position interface.  
>> Objects with lower outside-staff-priorities (+ the interior skylines of 
>> vertical axis groups) become support objects for those with higher.  This 
>> means that all positioning information is calculatable via a Y-offset 
>> callback, so no more need for translate_axis.
> 
> So in the example
> { g4\> g'_"pico"  g' g\! }
> the text "pico" has its Y position referenced to the staff, its Y-parent.
> 
> Currently, the TextScript holding "pico" has a Y-offset property that is a 
> function computing the position to clear everything on the staff.  (Y-offset 
> considers the parent-child relationship only.)  The results of the function 
> pointed to by Y-offset are stored in the C++ data-structure representing this 
> TextScript.
> 
> Currently, the TextScript and Hairpin, both having the staff as Y-parent, are 
> then arranged relative to each other.  Any shifts required by this arranging 
> are applied, by translate_axis(), to the stored positions in the Hairpin and 
> TextScript.
> 

Yup.

> You propose (I think) to avoid collisions between Hairpin and TextScript 
> directly in the functions used to compute Y-offset.  Hairpins are placed 
> first, then TextScripts, so in this case the TextScript gets a pointer to the 
> Hairpin added to its list of side-support-elements.  We would need to walk 
> through outside-staff priorities and put these pointers in place *before* 
> computing Y-offsets, opposite to the current order of opertions, so that the 
> TextScript's Y-offset computation has the information to see and avoid the 
> Hairpin.  (Now I have a guess why you might want the skylines outlining the 
> staff and outlining Hairpin to be "cached" in Scheme objects.)

Yup, except that in the new patch I proposed, instead of adding it to this 
list, I use the vertical-skyline-elements array of the vertical axis group to 
which the grob belongs.  That is because outside-staff-placement is 
conceptually different from normal side placement, as outside-staff objects can 
slide under other outside-staff objects whereas we don't want this for normal 
side placement.

> 
> This would change Y-offset to be the position relative to parent, from all 
> causes, rather than just the offset *due* to the parent.  Some care would be 
> required to avoid circular dependencies, but it should be possible because 
> the data dependencies are already there in the current method.

Everything should be fine in the patchset I just uploaded.

> 
> The change to remove the call to translate_axis() in 
> axis-group-interface.cc::avoid_outside_staff_collisions(), plus whatever 
> preparation is necessary for that change, would be conceptually easier to 
> review all at once.

Done.

> 
> I have a glimmer understading of your plan for cross-staff items.  If the 
> Hairpin in the example was instead a cross-staff Slur, I see that you hope to 
> (re)-position the "pico" by computing the Y-offset, which will use whatever 
> position information is available at the time.  It seems you would need two 
> passes of positioning "pico": one to compute staff skylines (conservatively) 
> so LilyPond can space the staves, and then one to position the "pico" around 
> the slur.  It do not yet have more than glimmer of hope that it will actually 
> be possible.
> 

I have a conceptual roadmap in my head and, so far, the elimination of the 
translate_axis call proposed in the most recent patchset has gone OK (it passes 
regtests).  Now, we just need to implement better pure skylines, use them for 
vertical axis group spacing with the most robust information possible (i.e. 
real beam placement can be used after X positioning is done - no need to be 
pure), and then we should be set...

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Caches the interior skylines of vertical axis groups and systems. (issue 7185044)

[mike]

On 1 févr. 2013, at 16:04, d...@gnu.org wrote:

> As previously, there are no comments whatsoever putting the code into
> perspective.  This is an amorphous heap of code without an attempt of
> explaining its design or inner logic.  There is a single function
> comment giving a glimpse of what that function is supposed to do.
> However, there is no explanation of the context this function is
> supposed to be used in or for, the function naming bears no relation to
> its return value, the comment is unclear, half of the named entities
> don't exist in the function interface, and half of the existing entities
> are not mentioned.

Thanks for the review - comments are addressed below.
The code exists in order to use Y-offsets of grobs, via the side position 
interface, to do outside staff placement instead of translate axis.

> 
> 
> https://codereview.appspot.com/7185044/diff/17001/lily/directional-element-interface.cc
> File lily/directional-element-interface.cc (right):
> 
> https://codereview.appspot.com/7185044/diff/17001/lily/directional-element-interface.cc#newcode25
> lily/directional-element-interface.cc:25: recursive_get_grob_direction
> (Grob *me)
> Why is not direction-source used instead?  This code seems like being
> intended to replace proper information by heuristics that mask a problem
> most of the time.

direction-source, if anything, seems like a work-around for the more logical 
recursive_get_grob_direction.  If a Grob foo has direction UP and it has 
children (or grandchildren), the assumption is that these grobs should have the 
same direction as foo unless otherwise specified.  I don't think that's 
replacing proper information.

> 
> https://codereview.appspot.com/7185044/diff/17001/lily/script-interface.cc
> File lily/script-interface.cc (right):
> 
> https://codereview.appspot.com/7185044/diff/17001/lily/script-interface.cc#newcode81
> lily/script-interface.cc:81: // ie DynamicText takes direction from
> DynamicLineSpanner
> Why then would DynamicLineSpanner not be the direction-source of
> DynamicText?  I applaud that you are bucking the trend of making the
> entire patch without comments, but it looks like the code is intended to
> mask a bug by sometimes doing the right thing by accident.

Same logic as above - when all else fails, take the direction of the Y parent.  
It seems to me that a reasonable default is "if no direction property is set, 
assume that the grob has the same direction as its Y-parent."  This type of 
logic is all over lilypond - for example, if a grob does not have a Y-offset, 
its Y-offset is the same as that of its parent.  I'm just reimplementing the 
"if no information given, use parents' information" with the direction property.

> 
> https://codereview.appspot.com/7185044/diff/17001/lily/side-position-interface.cc
> File lily/side-position-interface.cc (right):
> 
> https://codereview.appspot.com/7185044/diff/17001/lily/side-position-interface.cc#newcode185
> lily/side-position-interface.cc:185: // or with anything in
> other_v_skylines.
> Congrats.  This is actually the first comment that actually gives _any_
> information for the actual intent of a function.  Unfortunately, there
> is no indication _what_ is being returned.
> "avoid_outside_staff_collisions" does not sound like it would return any
> value.  And what information do we get?  "Returns the value for the grob
> elt" (there is no grob elt in the arguments) "whose skylines are given
> by h_skyline..." (there is no h_skyline in the arguments) "so that it
> doesn't intersect with staff_skyline" (there is no staff_skyline in the
> arguments).
> 

Fixed.

> And what is the grob going to do with that value to stop intersecting?
> Scale itself by that value?  Buy itself a hoverboard worth the value in
> order to ride the skylines?

I like the second option!  Comment expanded...

> 
> Please give the function a name making any sense in connection with its
> return value, and if you bother writing a comment, please make sure that
> it refers to actually involved variables and arguments.  And what's with
> padding, horizon_padding, other_padding, and other_horizon_padding?
> What's with dir?

More explination added

> 
> https://codereview.appspot.com/7185044/diff/17001/lily/side-position-interface.cc#newcode296
> lily/side-position-interface.cc:296: //printf ("Q %s\n", e->name
> ().c_str ());
> What's this supposed to be?
> 

Erased.

> https://codereview.appspot.com/7185044/diff/17001/lily/side-position-interface.cc#newcode461
> lily/side-position-interface.cc:461: MAKE_SCHEME_CALLBACK
> (Side_position_interface, outside_staff_aligned_side, 1);
> Sure, something called "

Re: Allows slurs to break at barlines. (issue 7424049)

[mike]

On 8 mars 2013, at 13:54, d...@gnu.org wrote:

> 
> https://codereview.appspot.com/7424049/diff/19022/ly/spanners-init.ly
> File ly/spanners-init.ly (right):
> 
> https://codereview.appspot.com/7424049/diff/19022/ly/spanners-init.ly#newcode114
> ly/spanners-init.ly:114: breakSlur = #(make-music 'BreakSlurEvent)
> I am not happy with a new event type here.  Can't this become an
> additional property on the existing events?  That way, we could do make
> with a single command \broken used like
> c\broken(
> and similar.
> 
> That's one new user interface rather than half a dozen and growing.
> 

I like the idea of using BreakSlurEvent and BreakPhrasingSlurEvent because they 
function like BreakDynamicSpanEvent.  Essentially, each event that creates a 
spanner can have a Break*Event to break said spanner.

This also allows the event to not be a post event, which is important when you 
want to start a score with a broken slur.

https://codereview.appspot.com/7424049/


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Freezing for 2.18

[mike]

On 10 mars 2013, at 18:54, David Kastrup  wrote:

> "m...@mikesolomon.org"  writes:
> 
>> On 10 mars 2013, at 18:32, David Kastrup  wrote:
>> 
>>   Ok folks, it is this time of the year again: I am trying to make
>>   myself
>>   unpopular.
>> 
>> There's a time of the year for that?
>> 
>>   It also means that commits of the "this really does nothing, but
>>   it
>>   prepares the ground for $xxx, and I don't know just where this is
>>   going,
>>   so quite a bit of it might be changed into something different
>>   yet"
>>   should happen in a branch. Actually, I am of the opinion that most
>>   of
>>   these changes should happen in a branch anyway. A "commit" implies
>>   commitment, and if one has taken a bad path, redoing it is much
>>   harder
>>   if the dead end has already ended in the main code base.
>> 
>> As the world champion of this style of coding, I can conclusively say
>> that I have no problem freezing all my experiments except the large
>> translate_axis call patch, as I am sure that I know where its going
>> and I almost have it wrapped up after many rounds of revision and
>> review.
> 
> What's it good for with regard to the current feature set?  It does not
> matter how good it is going to be for future tasks for the question of
> whether one wants to see it in 2.18.  What ends up in 2.18 is something
> that people can expect to depend on in 2.20 as well.  If it is
> preparation for future work, it is unlikely that it will stay identical
> once the future work is getting tackled.

I _completely_ agree with you that it is high time for 2.18.  I also think it 
is important to not start big projects after a freeze date is announced.

Given that the translate_axis patch is fresh on my and other's minds (i.e. the 
reviewers on Rietveld, the most recent being Keith), I'd rather push it in the 
next couple weeks and then fix any bugs in the next 4-6 weeks rather than 
waiting.  Not only will it save time for me and reviewers, but it will also 
help me start doing the brainwork for the next big thing.  Perfect timing, for 
me, would be like what we did for 2.16 in Waltorp.  If I know when a freeze is 
arriving, I can coordinate my work so that, again, I can make my next large 
change ready right after the stable release comes out.

So, to resume, I agree that a freeze is important.  When the freeze kicks in, 
I'd rather that we say something like "no new big projects starting on date X 
will be part of 2.18" so that developers can plan out their next few months 
accordingly.

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Removes outside-staff-priority from dynamic-related objects in Dynamic context (issue 7655045)

[mike]

On 29 mars 2013, at 12:57, janek.lilyp...@gmail.com wrote:

> On 2013/03/29 04:52:29, MikeSol wrote:
>> On 2013/03/27 21:50:02, janek wrote:
>>> I see that these overrides solve the problem, but it would be nice
> to know why
>>> this works.  Can you write an explanation?  What was wrong with the
> skylines
>>> that caused this bug?  Maybe this is just one instance of a more
> general
>>> problem.
> 
>> Objects that are placed inside the staff were being placed outside the
> staff.
>> Conceptually, dynamics are "inside" a staff in Dynamics contexts, even
> if there
>> is no staff.
> 
> Interesting.  Why the skylines weren't completely empty,
> but only cropped?
> (please let me know if i'm bothering you too much - my
> goal is to understand the issue and ensure good commit
> message, not to get you annoyed :) )
> 

Not sure - I haven't had a chance to investigate why it was wrong.  I just 
spotted the problem and fixed it.

It is true that knowing what's going on internally would help, but that's worth 
filing another issue for to the tune perhaps of "outside-staff positining above 
empty inside-staff skylines leads to inconsistent results."

That said, if we are positioning above an empty element, it is difficult to 
know what expected behavior would/should be.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: the latest convert-ly fiasco

[mike]

On Tue, 25 Oct 2011 12:25:56 +0100, Graham Percival wrote:

I've lost track of where we are with convert-ly.

I have just ran update-with-convert-ly.  I saw a flag change from
2.15.10.  I have pushed that.

I know that there are other syntax changes that people want to
make.  Somebody make a patch with all those changes, for version
2.15.16.  Once that patch is pushed, I'll release 2.15.16, so that
we can start with a clean slate from 2.15.17 onwards.


I am not going to try to make any general guidelines for
convert-ly at the present time.  When I am feeling better, we will
resume GOP, and we'll get a definite set of instructions for
syntax changes.  Until then, just do whatever works, and if it's
useful to have a couple of extra releases just to avoid combining
multiple syntax changes in the same version number, so be it.

- Graham



Graham,

Thanks for adding this to GOP.  I have some ideas for how to avoid 
convert-ly problems, and I'm looking forward to airing them.
I'll have some time later this afternoon to take care of the current 
convert-ly shenanigans.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: convert-ly rules to destencil Flags

[mike]

On Tue, 25 Oct 2011 11:49:58 +0200, David Kastrup wrote:

Graham Percival  writes:


On Tue, Oct 25, 2011 at 10:56:23AM +0200, David Kastrup wrote:

"m...@apollinemike.com"  writes:

> git mikesol@mikesol-laptop:~/lilypond-git$ git rebase 
origin/dev/staging

> fatal: Needed a single revision
> invalid upstream origin/dev/staging

git branch -r lists nothing?  Anyhow: I tried rebasing, deleting 
and

pushing the branch about an hour ago, and pushing did not work.


I just (well, 30-90 minute ago, can't remember) merged dev/staging
to master using your formula.  That may have impacted things.


Don't think so: I think I rebased dev/staging before that.  
Afterwards,
the merge should have just been a painless fast-forward.  Weird, all 
in

all.


Mike: try the old instructions here to get the branch:

http://lilypond.org/doc/v2.15/Documentation/contributor/downloading-remote-branches

I will work at simplifying these, since we're suggesting that
people go with git clone and those instructions were written in
the pre-clone era.


I see that my git config contains
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = ssh://git.sv.gnu.org/srv/git/lilypond.git
fetch = +refs/heads/dev/staging:refs/remotes/origin/dev/staging

Maybe references in a subdirectory don't get found automagically?  On
the other hand, git branch -r lists a whole lot here.  No idea.


Hey all,

I tried:

git remote add -ft dev/staging -m dev/staging staging 
git://git.sv.gnu.org/lilypond.git/


And then

git branch foo staging/dev/staging
git checkout foo
git apply foo.diff (where foo.diff are all of my changes)
git commit -a (with the appropriate commit message)
git push

and I get


fatal: The remote end hung up unexpectedly

Any ideas what I did wrong?

Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: dev/staging fail: illegal entry in bfrange

[mike]

On Oct 29, 2011, at 9:51 AM, David Kastrup wrote:

> Graham Percival  writes:
> 
>> sorry about losing track of this.
> 
> No need to apologize: _my_ computer is far too slow to be useful for
> bisection, anyway.  It looks like we will have a bit of bijection
> flakiness for a while until we get the staging business sorted out.
> 
> -- 
> David Kastrup
> 
> 

Hey all,

I'm on holiday this weekend - sorry for missing this series of e-mails & sorry 
for the missing @code.
I'll be able to get on this in a bit.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds some info about pure properties to the CG. (issue 5364048)

[mike]

On Sun, 20 Nov 2011 15:19:03 -0800, Joe Neeman wrote:

Bah, I just wrote out a nice reply on the codereview site and it got
eaten...

On Fri, Nov 18, 2011 at 12:03 AM, m...@apollinemike.com [3]  wrote:


On Nov 16, 2011, at 2:19 AM, joenee...@gmail.com [1] wrote:

>



http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1888

[2]
> Documentation/contributor/programming-work.itexi:1888: taken
from the
> stencil.
> Actually, the requirement is different: the print function must
not have
> any side effects. The print function doesn't necessarily have to
deliver
> the same result at all stages in the compilation process. For
example,
> if some side-effect modifies the font size of a grob
mid-compilation,
> then note-head::print will deliver a stencil of a different
height.
>

Then I misunderstood what pure means in lily-speak.  I thought
that a pure function had the dual condition that it (a) always
return the same value for a given begin and end range; and (b) not
trigger any side effects.

Are there any cases where pure functions do deliver different
results for the same range before line breaking?  And, if not,
would this even be conceivable/desirable?


I can't think of a situation where it's desirable, but it's certainly
conceivable. If I write lily code that, for whatever reason, has a
callback which changes Slur 'height-limit then Slur::calc_pure_height
will also change. We tend to avoid the use of set_property after the
translation step, so this sort of thing is unlikely; the point is,
though, that the pure callback itself doesn't worry about such 
things.

It just tries to avoid side-effects, and if something else with side
effects messes with grob properties then the pure callback can change
its value accordingly.


Lastly, the idea of "not trigger any side effects" is something

that

I grok more than I understand.  Is there any way to communicate
what it means to "not trigger side effects" (i.e. never calls (or
results in the calling of) set_property on another property with a
pure estimation, etc.) to someone who doesn't know what these side
effects are?


The main side effects in lilypond are set_property, set_object and
suicide. These are easy to avoid; the trickier part is that any call
to get_property could conceivably trigger a callback that will itself
have side effects.


OK, will write some more prose.


 >  xi#newcode1901

> Documentation/contributor/programming-work.itexi:1901: @end
itemize
> I think the preceding four lists can be understood as follows:
if you
> have a Grob and you want to estimate its height, what can you
do?
>
> - If its Y-extent callback is pure, just use it (pure-functions)
> - If its Y-extent callback is ly:grob::stencil-height and the
stencil
> callback is pure, then it's safe to use ly:grob::stencil-height
> (pure-print-functions)
> - If we have a manually-created pure version of its Y-extent
callback,
> use that (pure-conversions-alist and
pure-print-to-height-conversions)

I agree, but is this not clear from the document as it stands and,
if not, how should it be modified so that it is clear?  My biggest
worry is clarity, as I often don't understand what I'm saying, so
I'd imagine that others will have an even harder time.

I'm not sure which version is better for new readers. It's just
that you're explaining these lists in terms of what they contain,
while I find it easier to think of them in terms of their role in
call-pure-f

h also helps to explain why we would bother to have these lists in
the first place).


I'm going to leave it this way if that's all right with you for the 
purely selfish reason that I grasp these lists better in terms of what 
they contain.
This then can be edited later by anyone who wants to improve the ease 
of reading of the document (which I'm sure can benefit from other 
changes as well - I hope that someone who has no clue about pure 
properties actually takes the time to read this thing so that I can 
learn what is graspable on a first read and what is not).


The AMSTERDAM AIRPORT is currently blocking me from uploading the patch 
set (Han-Wen...Jan...do something...), but I'll get it up on Rietveld 
once I'm back in a civilized country.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Fixes NoteColumn vs SpanBar collisions. (issue 5323062)

[mike]

On Mon, 21 Nov 2011 07:06:53 +, k-ohara5...@oco.net wrote:

Looks okay to me.

The ghost of the SpanBar (left over from the issue 910 patch) 
sometimes

has an effect
  \new GrandStaff <<
\new Staff { e'1 | eses'''4 r2. | e'1 }
\new Staff { e'1 | e'1 | eses4 r2. } >>
Something like
  \override Score.SpanBar #'extra-spacing-height
 = #'(+inf.0 . -inf.0)
takes care of that problem.


Fixed.


On 2011/11/10 18:49:48, mike_apollinemike.com wrote:

On Nov 10, 2011, at 10:38 AM, mailto:k-ohara5...@oco.net wrote:



> I was talking about custom heights for every bar along the Staff,



I think the problem that this'd cause is that the overestimation may

block
lyrics/dynamics/what-have-you from sliding to the left as much as 
they

could.

Well, any overestimation in your blocking heights also becomes an
overestimation in the tentative space between Staves/Lyrics/Dynamics 
at

the horizontal spacing step.

For example, the notoriously-bad pure-height estimates for slurs 
cause
the tentative-spacing to be looser.  Thus a slur (even on a later 
line

or later page) will cause Lily to think the Lyrics might have to move
away, and thus avoid the sticky lyrics effect:
  \paper {ragged-right = ##t}
  \relative c''' { c2 c c c \break c( g,) }
  \addlyrics { foo bar f bar }

Use of custom locally-determined heights for each bar line seems
unnecessarily complicated (but not as bad as the grace_fixup_list so 
I

won't complain).


I think that you're right for most cases, but for a piece with lots of 
accidentals that could potentially hang over barlines, this complexity 
in estimation seems to help.  As for the extra spacing, I'd be curious 
to see if a gimungous score gets looser with this patch applied.  If 
anyone has a many-page piano or chamber music score with SpanBars, 
please give it a spin with this patch (and the workaround above that 
Keith suggests, which will be in my next patch set).



Run fixcc.py on the changed .cc files to clean up some whitespace
problems.


Will do.




http://codereview.appspot.com/5323062/diff/53040/input/regression/lyrics-pass-under-bar.ly
File input/regression/lyrics-pass-under-bar.ly (right):


http://codereview.appspot.com/5323062/diff/53040/input/regression/lyrics-pass-under-bar.ly#newcode4
input/regression/lyrics-pass-under-bar.ly:4: texidoc = "Long lyrics
should be allowed to pass under
Probably you want this test to be pushed in the same commit where you
fix issue 1955.


You're right.  Removed.



http://codereview.appspot.com/5323062/diff/53040/scm/define-grob-properties.scm
File scm/define-grob-properties.scm (right):


http://codereview.appspot.com/5323062/diff/53040/scm/define-grob-properties.scm#newcode1040
scm/define-grob-properties.scm:1040: to this side of the boolean.")
.. indicating whether a a span bar is drawn above, or respectively
below, this staff.


Rewritten.

Thanks for the feedback!  I think we're almost over the hill with this 
one...


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Adds some info about pure properties to the CG. (issue 5364048)

[mike]

On Mon, 21 Nov 2011 08:02:00 +, k-ohara5...@oco.net wrote:


http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi
File Documentation/contributor/programming-work.itexi (right):


http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1832
Documentation/contributor/programming-work.itexi:1832: a @emph{prima
face}.  If you write a pure-function, you are promising
What does 'prima face' mean?



oops, I meant `a priori'



http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1858
Documentation/contributor/programming-work.itexi:1858: @var{start} 
and

@var{end} is facultative, as items only occupy one
'facultative' is an odd word here.  I guess you mean it in the sense 
of

'optional', where the user of the optional thing can turn to a
substitute if it is not provided.
Then just say start and end are optional parameters where the 
function

provides the defaults.


ok.  i'll say that the values are thrown away.



http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1861
Documentation/contributor/programming-work.itexi:1861: @var{end} are
important, as we may can get a `purer' estimation of a
I'm getting confused.  "pure(lilypond)" generally means 'crappy' in 
the
sense of pure-height of a slur being the crappy estimate of height 
one
can get without triggering the line-breaking and note-spacing.  When 
you

say 'purer' above, you seem to be using the superlative of
"pure(English)" rather than "pure(LilyPond)".


i'll change it to "better pure estimation"



http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1913
Documentation/contributor/programming-work.itexi:1913: LilyPond is 
smart

enough to know if a series of chained functions are
So if one function in the series has no pure equivalent, but you call
the first function at a time when only pure functions may be called,
what is LilyPond smart enough to do?


it gives up and returns a dummy value (something like #f or '()).  one 
(untested) way to see this is take one of the chained callbacks (like 
rest offset) and append a function:


(lambda (grob) (return 0))

LilyPond will ignore all of the previous work because it can't find a 
pure equivalent for the anonymous function.




http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1959
Documentation/contributor/programming-work.itexi:1959: Pure Y values
should be used in any functions that are called before
should or must?


must



http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1996
Documentation/contributor/programming-work.itexi:1996: overly-distort
the Y-extent of an system, which could result in a very
extra-spacing-height does not distort the Y-extent


true, will change.



http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode1997
Documentation/contributor/programming-work.itexi:1997: @q{loose} 
looking

score with lots of space between systems.  So, to
Prove it.


http://codereview.appspot.com/5364048/diff/4001/Documentation/contributor/programming-work.itexi#newcode2041
Documentation/contributor/programming-work.itexi:2041: not be changed
later in the compiling process due to other changes?
This sounds like "pure(ComputerScience)" in the sense of a function 
that

depends only on its arguments, not on any other program state.  Does
"pure(LilyPond)" include this concept.


no.  the only air tight definition of `pure' in lilypond is "a series 
of behaviors and coding conventions about which one can think 
spontaneously, extemporaneously and intuitively after having read 
through all pure-property-handling code for at least one year."


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Better pure heights for slurs (issue 5431065)

[mike]

On Thu, 24 Nov 2011 19:16:46 +, k-ohara5...@oco.net wrote:

I like the direction of this change.


Does it actually work?


The code has your trademark incomprehensibility,


Thank you, Keith.  You know, sometimes, people think that it comes 
naturally to be so incomprehensible, but it's actually hard work.  
Usually, before writing LilyPond code, I'll read a passage from either 
Finnegans Wake or Waiting for Godot and then recite some Gertrude Stein 
poetry.  It helps me get my head in the right place.  Of course, one 
likes to believe that one can always find room for improvement, but I 
actually think that I hit my zenith with one of my first commits via 
path-min-max in stencil.scm.  The US government is working on its 
inverse function in hopes that it will help decrypt Chinese telegrams.



so I don't know if it
does what you want based on your introduction.  Maybe just decide 
that

you want what it does.


It basically finds a horrendous approximation for the slope of the slur 
and then ret holds the y component of this height.  I could have used 
arctans, but I decided to solve for y using the Pythagorian theorem 
instead.  The only danger is that my estimate of the slope is likely too 
steep in most cases (thus yielding a smaller height than desirable), but 
this is offset by the fact that the height is tacked onto the highest 
point of the slur.




http://codereview.appspot.com/5431065/diff/1/lily/slur.cc
File lily/slur.cc (right):

http://codereview.appspot.com/5431065/diff/1/lily/slur.cc#newcode102
lily/slur.cc:102: height *= 0.5;
Not too harmful here, but in general redefining variables with
meaningful names causes other programmers to scan lines 77 through 
101
for use of the original height, and then lines 103 through 118 for 
the
new use of height, to try to determine why it changed halfway 
through.


If the conceptual "height" didn't change, just leave 'height' alone.

Oh, the concept is actually "height-limit". Maybe the original 
variable

name wasn't perfect.  Since ret.length() is also an estimate of the
actual height of the slur, I'd take the time to change the variable
names.


Doable.


http://codereview.appspot.com/5431065/diff/1/lily/slur.cc#newcode107
lily/slur.cc:107: between two columns
Trop de mots,
und ein, dass ich nicht in meinem Wörterbuch gefunden haben.

http://codereview.appspot.com/5431065/diff/1/lily/slur.cc#newcode115
lily/slur.cc:115: ret[dir] += dir * (sqrt (height * height / ((s * s) 
+

1)) + 0.5);
Reduces to abs(0.5*height_limit) / sqrt(s²+1).
Simplifying the math, it looks like the result is nearly this:
 Real encompassing_height = max(1.0, ret.length());
 // Coarse estimate of how far the slur will bow upwards
 ret[dir] += dir * no_elts * height_limit / encompassing_height;
 ret += 0.5 * dir;


Yup - this'll come in slightly larger than the result in the patch, but 
still smaller than the original estimate.  I can use it instead.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: OT: Vocal music

[mike]

On Fri, 25 Nov 2011 10:52:26 +0100 (CET), Werner LEMBERG wrote:

I'm working on a book of madrigals right now and some of it is
recorded.  The YouTube excerpt has affinities w/ mm. 21-30 of the
attached PDF & audio file (it's an excerpt from the 3rd madrigal in
the book, called "Lucky Wok (star!)").


Your sample sounds really amazing!  However, the notation is 
extremely

complicated: I've listened five times to it, but I still wasn't able
to follow the score...


There's the rub...

Obviously, if I gave this score to 10 highly-skilled amateur chamber 
choirs and said "have at it," I would get 10 very different versions of 
the piece and probably none of them would resemble the recording 
(whether or not they'd be better is another question).  However, if I 
put more vague indications like "freak out in the style of Mike 
Solomon," while this would probably get a better initial result 
(assuming the person took the time to research how I freak out), it 
would max out at a lower level of interesting nuance and unexpected 
concord.


If you listen to each voice solo-ed out with a click track, you'll see 
that the recording is pretty much a sonic carbon copy of the notation.  
The best way to learn the piece, then, is to learn it by ear as you read 
it on a beat-by-beat basis.  After rehearsing it this way, the score the 
acts as a timeline with various landmarks to jog your muscle memory.




Any chance to make it more simple?  Obviously,
you know far too much about lilypond to produce such well looking
scores :-)



I <3 LilyPond (that's why I try to break it so often), and I shudder to 
think what putting this together would have been like with any other 
notation program.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Summary of markup-related ideas

[mike]

Plan for revising markups ::

NAMESPACE MANGLING OF GROB PROPERTIES

--) function

All grob properties will be associated with their interface.  So, `Y-extent' 
will no longer be internally represented as `Y-extent' but rather 
`Y-extent@grob-interface'.  When someone does:

\override Stem #'Y-extent = #'(0 . 0)

or

(ly:grob-property stem 'Y-extent)

or

(ly:grob-set-property! stem 'Y-extent '(0 . 0))

LilyPond will automatically mangle the property to the right name by searching 
all of the grob's interfaces and attaching the correct one.

If the user writes in the mangling, like:

\override Stem #'Y-extent@grob-interface = #'(0 . 0)

LilyPond will be smart enough not to do the automatic mangling.

--) rationale

Eventually, in the model elaborated below, advanced users will be creating 
their own grobs on the fly with custom properties and interfaces.  Most of 
these definitions will need to be basic, on the order of:

#(define-markup-command (foo layout props bottom top)
  ...)

#(define-markup-command (bar layout props bottom top)
  ...)

LilyPond will do some magic (through functions...ideally not through macros) to 
create the "Foo" grob with properties bottom@foo-markup-interface and 
top@foo-markup-interface that implements markup-interface and 
foo-markup-interface.  Ditto for the Bar grob. This type of namespace mangling 
assures that no properties are double-defined.  It is a sort of namespacing of 
properties.

REWRITE OF define-markup-command

--) function

All markup commands should do either two things.

1) The creation of a Grob.
2) The overriding of a Grob.

So:

\markup "foo"

Will create a `MarkupText' grob that has as its #'text property "foo"

\markup \raise #0.5 \note #"4" #UP

Will create a `NoteColumn' grob that has its Y-offset property chained to a 
callback that raises it by 0.5.

\markup \column { foo bar }

Will create a `Container' grob that has in its element list two MarkupText 
grobs and a layout-manager property of column-layout-manager (see below).

\markup \concat { foo bar }

Will create a `Container' grob that has in its element list two MarkupText 
grobs and a layout-manager property of concat-layout-manager.

Somehow, define-markup-command will have to do the on-the-fly creation of grob 
definitions if they don't already exist and create the corresponding grobs.

--) rationale

Currently, all markups are evaluated @ compile time save certain esoteric 
situations.  This means that they cannot communicate with scores at all.  It 
makes their layout possibilities rather limited and requires kludgy functions 
to deal with retrieving page numbers and footnotes for markups.  If every 
graphical object in LilyPond has the internal representation of a grob, it'll 
make handling them much more uniform and extensible.

CREATION OF THE LayoutManager CLASS

--) function

SpacingSpanner, Page_layout_manager, and other things that take care of the 
positioning of other grobs will inherit fro the layout manager class.  In 
theory, any layout manager should be able to take a group of grobs and lay them 
out according to their rules (i.e. Java).

--) rationale

Currently, there are a lot of aspects of LilyPond with shared functionality 
(i.e. \justify in markup-speak and the SpacingSpanner) that are not grouped 
together in class inheritance mechanisms.  By doing this, we'll provide an 
easier template for future development.

ELIMINATION OF THE Prob CLASS

--) function

Everything is a grob.  A System is a grob that can be split up into several 
systems and put into a Container grob with a MarkupText.
A Page is a spanner that is split into several broken_intos_ on which various 
other grobs are put.
A Book is an object that contains several pages in a given orientation 
(vertical, horizontal, etc.).

--) rationale

With this addition, a cross-staff Beam can theoretically connect beams from two 
different scores on the same Page (or even the same Book) because there will 
always be a common-Y.

EXTENSIBILITY

--) function

LayoutManagers and grobs should be easy to define on the fly through various 
channels.  define-markup-command should, in theory, be able to define both 
(depending on what the markup command does).

--) rationale

This is in keeping with developments in LilyPond like Scheme engravers.

*

That's a lot of text!  But, it may be worth it to go down this road now.  At 
the coding partaaa, Nicolas Sceaux told me that the idea was kicked around 
before I was born to do some serious overhaul on markups, but it was then 
decided that this was more trouble than it was worth, so markups kinda stay put 
in their conceptual advancement while grobs took many great leaps forward.  
It'd be great to get markups to this level of sophistication as well, mostly so 
I could typeset the contemporary music example on the SCORE webpage using 
LilyPond.

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists

Re: Segfault 2.15.23 Span_bar_stub_engraver

[mike]

On Jan 5, 2012, at 7:51 AM, David Kastrup wrote:

> Grob::get_vertical_axis_group is not protected against the case where g
> has an axis group interface but no Y_AXIs parent.

I thought it was.  If g has no Y_AXIS parent, then when get_vertical_axis_group 
(g->get_parent (Y_AXIS)); is called, the first test if (!g) will return 0, no?

> 
> The second if in Grob::vertical_less has a test that can obviously not
> be true.
> 

This is true - fix pushed to staging.

Cheers,
MS




___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gets rid of PostScript inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 5529048)

[mike]

On Mon, 9 Jan 2012 14:24:45 -, Phil Holmes wrote:

- Original Message - From: 
To: 
Cc: ; 
Sent: Monday, January 09, 2012 5:14 AM
Subject: Re: Gets rid of PostScript
inbar-chords-notation-for-guitar--with-text-spanner.ly (issue 
5529048)




LGTM

I'm vaguely curious as to what's the difference between this 
postscript

and the regtest for postscript, but that's no reason to hold up
development.  Besides, the lilypond markup is easier to understand 
than

the postscript, so this is a good change to make even if it wasn't a
build problem.

http://codereview.appspot.com/5529048/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel



Whoah.  This is changes to snippets in the snippet directory.  It
actually looks like the only substantive change if with the

Documentation/snippets/bar-chords-notation-for-guitar--with-text-spanner.ly
which is duplicated in snippets/new.  Mike - you only need to edit
the one in snippets/new - the other should be updated in the LSR, and
it will appear in snippets/ when an LSR import is run.  However, the
snippets/new one takes priority so it shouldn't make ant difference
when this is done.


Hey Phil,

I only changed the one in snippets new and then ran 
scripts/auxiliar/makelsr.py (this is the procedure specified in the CG).


Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Build help

[mike]

Hey all,

I'm trying to design a regtest for the DOM-id property.  Ideally, I'd 
like to generate an svg file that is then checked by a python script to 
make sure that the property has been correctly set.


I have sketches of the files in question (see attached) and I'm 
wondering how I could design a GNUmakefile that:


-) compiles the lilypond file with -dbackend=svg
-) runs the python script on the result

The script raises a ValueError if the result is incorrect which (I 
think) would be enough to make `make check' fail.


I'm guessing that the GNUmakefile along with the .ly and .py file would 
go in a new folder input/regression/svg.


Could someone whose adept at build please give me some pointers on what 
this makefile would looklike and how to get it (and the new svg folder) 
integrated into the regtest process?


Thanks!

Cheers,
MS<>import xml.dom.minidom

dom = xml.dom.minidom.parse('quarter.svg')

def has_quarter(n) :
  if not isinstance(n, xml.dom.minidom.Element) : return False
  if 'quarternote' in n.getAttribute('id') : return True
  return False

def get_quarter(n) :
  return list(filter(has_quarter, n.childNodes)) + sum([get_quarter(x) for x in n.childNodes],[])

ds = set([
  filter(lambda y : y.tagName == 'path',
filter(lambda y : isinstance(y, xml.dom.minidom.Element), x.childNodes))[0].getAttribute('d')
  for x in get_quarter(dom.documentElement)])

if len(ds) != 1 : raise ValueError('bad')




quarter.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Regtests for 2.15.24

[mike]

On Tue, 10 Jan 2012 11:07:35 -, Phil Holmes wrote:


A large number of changes in tests with slurs: see
lyric-extender-completion.png for example.  Assume these are Mike's
changes to make slur bounding boxes lass rectangular.



Are there any changes that result in collisions?  The gamble with 
making smaller pure-height estimations was that it would result in 
snugger spacing whilst avoiding collisions.  I didn't see any badness 
when I made the original change, but the pixel comparator sometimes 
reveals things that I miss in the regtest comparisons.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Let \footnote do the job of \footnote, \footnoteGrob, \autoFootnote and \autoFootnoteGrob (issue 5527058)

[mike]

On Tue, 10 Jan 2012 13:28:46 +, d...@gnu.org wrote:

On 2012/01/10 13:18:03, dak wrote:

On 2012/01/10 12:59:21, Reinhold wrote:
> LGTM.
>
> From a lazy user's POV, I don't like that I now have to use 
\default

for

> auto-numbering (which is th typical case)...



It is the same as with \mark (we don't have \autoMark either).  One

might

consider moving the footnote mark argument to last position


Actually, one could juggle the order of arguments around such that 
the

optional arguments can't be confused with the next argument.  Like
putting the footnote mark first, position next, Grob spec next, 
footnote

text last.  In that manner, you could leave off either Grob spec or
footnote mark without needing to say \default.  And even if one 
writes

\default for autonumbering, having it directly after the command will
look more like \mark.



This is a good idea - I should have done it this way from the get-go, 
but I had no clue about the whats/whys/wheres of \default.


Is there any chance that this type of change could be written as a 
smart convert-ly rule?  Assuming that people don't use # for purposes 
other than indicating Scheme arguments in their footnote making, 
scanning a string for "#" should show where the arguments are and then 
they can be swapped around.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: somebody needs to run staging before 29 Jan

[mike]

1. more people need to know how to run the script.
  (it's not hard; far easier than setting up apache)


I can do this if...


2. it would be good to have something in the CG about Patchy.


...you can do this.

I also think that Patchy needs to be part of the LilyPond source.

Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bounties

[mike]

Moving to devel:

I think this bounty slush fund needs to happen soon-ish - there's been 
two rounds of talking about it, which is great, but it will remain talk 
unless someone does something.  I also understand that David is in the 
position of not wanting to do a full court press for organizing the €€ 
thing because he wants to be earning some of it, which I respect.  So I 
am going to do something - if people have a problem with it, then speak 
up, but I'm throwing this out there as a solution.


1)  Create an e-mail address "contrib...@lilypond.org" (this I can't do 
- can someone please do this).
2)  Create a PayPal account for said address with one and only one 
person, the € czar, who has access to it.  This should be someone 
responsible and respectable .  In my life, I have drank, lied and 
listened to a lot of ABBA, so I am out, but there are several people on 
the list who seem like upstanding individuals who could fill this role.
3)  Propositions come in on the devel list from developers in the form 
of "I have project X and I would like Y€ from the slush fund to do it."  
This will then go up for a private vote (like patch review) where anyone 
who has git push access can send a vote email to the € czar.  If there 
are more yeas than nays, the person gets the € for doing thing X (in 
advance of doing it - it'll be a trust system).  The € czar has the 
final say over whether or not to approve the project in order to prevent 
abuse, and the € czar needs to agree to not be allowed to tap into this 
fund, lest she give up her role as € czar.


Seems simple, effective, and startable in the next two weeks.  I'm sure 
it is not perfect, but LilyPond is not perfect, and it seems better to 
start something and change it as need be than to not do anything.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Bounties

[mike]

On Wed, 25 Jan 2012 11:24:40 +, Graham Percival wrote:
On Wed, Jan 25, 2012 at 03:01:50AM -0800, m...@apollinemike.com 
wrote:

1)  Create an e-mail address "contrib...@lilypond.org" (this I can't
do - can someone please do this).


Can't do.


Seems simple, effective, and startable in the next two weeks.  I'm
sure it is not perfect, but LilyPond is not perfect, and it seems
better to start something and change it as need be than to not do
anything.


Check your email archives for our discussion on 2011 Dec 2 for all
the reasons I think this is a bad idea.

- Graham



Given that several users have already expressed the desire to give 
money this way and at least one developer has expressed the desire to 
take money this way, it seems that the only thing missing is the 
clearinghouse through which the exchange happens.  I'll propose a patch 
in a bit that does this: I think the best way to decide as a community 
if we want this is to read over a patch, see if we like it, and then 
either put it on a countdown or not.  In the meantime, I think people 
should take a gander at:


http://audacity.sourceforge.net/?lang=fr
http://ardour.org/
http://musescore.org/fr

They're all music related projects that have a donation system 
implemented.  Especially with MuseScore, we could just ask them how if 
it has proven to be effective for them.


Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Gets vertical skylines from grob stencils (issue 5626052)

[mike]

On Feb 10, 2012, at 3:05 PM, David Kastrup wrote:

> "m...@apollinemike.com"  writes:
> 
>> On Feb 10, 2012, at 1:51 PM, David Kastrup wrote:
>> 
>>> David Kastrup  writes:
>>> 
 David Kastrup  writes:
 
> Han-Wen Nienhuys  writes:
> 
>> Just a very quick look: I notice you're creating affine transform
>> matrices in Scheme. IMO, this seems an excellent candidate to
>> implement in C++ and expose through bindings, as the C++ matrices will
>> be better packed in memory, and should probably only be manipulated by
>> operations involving multiple floating point ops (add, multiply, etc.)
> 
> Stupid question: wasn't Cairo a dependency of LilyPond?  It should
> offer affine transforms as a builtin entity anyway, and it is
> conceivable that using those will play together smoothly with other
> rendering operations.
 
 Cancel that: I was confusing this with Pango.
>>> 
>>> Well, uncancel the idea in itself: seems like it applies to Pango as
>>> well:
>> 
>> I've implemented all of the affine transformations in
>> stencil-integral.cc.  They're pretty simple, but they work and are
>> fast.
> 
> No disrespect intended, but if we do our text stencilling in Pango
> anyway,

The affine transformation code handles all stencils, including paths, shapes, 
arcs, named-glyphs (which use open type fonts), etc..

> it seems like we don't buy us any advantages by maintaining our
> own code for transformations, possibly needing to convert them into the
> Pango form when passing them on.

They do not currently do this.  I am of course open to using pango for these 
transformations if it can do them reliably for generic matrices (i.e. something 
not wedded to text) and you're sure that their API is stable.  However, for the 
purposes of this patch, they are very simple and straightforward (copied 
straight out of the svg specification) and they get the job done.  Check out 
line 120 of stencil-integral.cc.  That's the extent of the complexity.

> I immediately agree that it is a
> nuisance to first do the work of coding this, then do the work of
> replacing it again, then check that the replacement also works.  It
> would have been nicer if I had thought of this earlier.
> 

There is absolutely no problem at all - I would much rather use a stable and 
robust library if it's available.  However, the operations are so minimal and 
simple that the thought didn't even occur to me not to implement them myself 
(it's taking me longer to write this e-mail than it took me to write the code). 
 If you think that Pango can do the job of what's in stencil-integrate.cc, 
lemme know.  I don't see anything in the library that seems designed for this, 
but I of course could have missed something.

> But things like using SSE instruction sets for transforms have a place
> in Pango (where it is a fundamental operation) but would not be a
> reasonable fit of code complexity in LilyPond.  It may be a naive
> assumption without looking at the respective code, but I would at least
> hope that we can rely on the Pango stuff being in reasonable shape, and
> if it isn't, have people care about bug reports without needing to
> invest too much work of our own.

This paragraph is a bit over my head, but again, if you think I can sub in 
Pango for my affine transformations, lemme know where it is in pango & I'll get 
to it!

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: volunteer for patchy new-patches

[mike]

I'm working with the University of Paris VIII to get a computer consecrated to 
the cause.  Once that happens, we'll have a new patchy platform.  It's also 
good to have that sorta institutional alliance when it comes to applying to 
stuff like GSoC.

Cheers,
MS

On Mar 16, 2012, at 8:41 PM, Graham Percival wrote:

> I think it's high time for somebody else to run the new-patches
> test.  For this task, David is ridiculously overqualified, but his
> laptop is pretty underqualified.  That combination makes him
> almost the worst person to run this task.
> 
> I'm hoping that this won't end up with James doing it; IMO even
> James is overqualified to be running patchy new-patches.  But
> maybe that would be ok for a week or two, in order to catch some
> more "gotchas" in the script and docs, then pass it on to another
> person.  Maybe one of the bug squad members?
> 
> NB: this is *not* a review, nor does it require any knowledge of
> lilypond programming at all.  You run a script, if it finishes
> then you look at some pictures and then say "nope, no change to
> the pictures".  Once you have the script set up -- which is easier
> than the patchy staging-merge, BTW -- it's easier than being a bug
> squad member!
> 
> On a more general note, I've love it if we could start foisting
> off some more development/maintenace tasks onto the current bug
> squad members, and start recruiting some new bug squad members to
> replace the existing ones.
> 
> - Graham
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: beam.cc:pure-rest-collision-callback Place on staff lines; issue 2468 (issue 6035053)

[mike]

http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/6035053/diff/16001/lily/beam.cc#newcode1328
lily/beam.cc:1328: return scm_from_double (0.0);
On 2012/04/25 06:21:29, Keith wrote:

It would seem we do not want an early return in this case; if the beam

direction

is not yet know, we would prefer to estimate the rest position to

returning the

wrong value.
But this condition was added recently, with the fix for issue 774.


What would the "wrong value" be here?

http://codereview.appspot.com/6035053/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Brings beamed rest closer to cross staff beam. (issue 5908043)

[mike]

http://codereview.appspot.com/5908043/diff/1/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/5908043/diff/1/lily/beam.cc#newcode1326
lily/beam.cc:1326: || beam->get_property_data ("direction") ==
ly_symbol2scm ("calculation-in-progress"))
On 2012/04/25 06:21:54, Keith wrote:

Mike, any idea why you added this?
It just adds to the cases where we lie and say the beam is on the

centerline.

It causes this to go wrongly
<< {b''8[ r16. g''32] } \\ {r8 16. r } >>



Take a look at today's patchset at
http://codereview.appspot.com/6035053/


If this bit isn't there, a circular dependency could be called up later
on in the function while looking for the direction.  I forget the exact
reason for the circular dependency, but it crept up in several regtests.
 Like several other pure functions, I have it cowardly fail if a pure
estimation is not possible because of circular dependencies, which
usually has a minimal impact on the typeset result.

http://codereview.appspot.com/5908043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Brings beamed rest closer to cross staff beam. (issue 5908043)

[mike]

On 2012/04/25 11:10:40, Milimetr88 wrote:

http://codereview.appspot.com/5908043/diff/1/lily/beam.cc
File lily/beam.cc (right):



http://codereview.appspot.com/5908043/diff/1/lily/beam.cc#newcode1326
lily/beam.cc:1326: || beam->get_property_data ("direction") ==

ly_symbol2scm

("calculation-in-progress"))
On 2012/04/25 06:29:14, mike7 wrote:
> On 2012/04/25 06:21:54, Keith wrote:
> > Mike, any idea why you added this?
> > It just adds to the cases where we lie and say the beam is on the
centerline.
> > It causes this to go wrongly
> > << {b''8[ r16. g''32] } \\ {r8 16. r } >>
> >
> > Take a look at today's patchset at
> > http://codereview.appspot.com/6035053/
>
> If this bit isn't there, a circular dependency could be called up

later on in

> the function while looking for the direction.  I forget the exact

reason for

the
> circular dependency, but it crept up in several regtests.  Like

several other

> pure functions, I have it cowardly fail if a pure estimation is not

possible

> because of circular dependencies, which usually has a minimal impact

on the

> typeset result.



I'm not well-placed to say.  I try to let the code act as its own
commentary as much as possible.  Here, I think that a person who knows
the code base knows that if the function exits because a property's
calculation is in progress, it is to avoid triggering that calculation.
However, if anyone feels that this is not pick-upable upon reading,
please add the comment!

http://codereview.appspot.com/5908043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 30 day webathon for kickstarter support (issue 6068045)

[mike]

On 2012/04/25 11:25:02, Graham Percival wrote:

First, editing embedded javascript is not a general solution.



Second, I'm not at all certain we want to have commercial

announcements in that

area.  I'm sorry if I gave the impression that this was to be a green

light for

any kind of announcement.


Why wouldn't this be a general solution?  I think that anyone who wants
to add an announcement would have to:

a) Add an entry to the array.
b) Build the website and make sure that their entry fits.

Also, in the most recent patchset I've changed my text to get rid of the
kickstarter bit.  I'll change the issue names as well.

http://codereview.appspot.com/6068045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Better pure height approximations for beamed rests. (issue 4860043)

[mike]

http://codereview.appspot.com/4860043/diff/4/lily/beam.cc
File lily/beam.cc (right):

http://codereview.appspot.com/4860043/diff/4/lily/beam.cc#newcode1743
lily/beam.cc:1743: Beam::pure_rest_collision_callback (SCM smob, SCM
prev_offset,
On 2012/04/27 06:06:21, Keith wrote:

Mike, Based on their contents, the arguments appear to be in a

different order:

grob, start, end, prev_offset
which is different than what you wrote in CG 10.13.2


You're right - this is an error.  Do you want me to fix it or are you
working on a patch into which the fix could be incorporated?

http://codereview.appspot.com/4860043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add announcements to the upper right corner of the website (issue 6068045)

[mike]

Hey all,

The new patchset puts the tweets in a separate xml file.  I use xml
instead of txt to avoid parsing annoyances.  The only problem is that,
because the xml is in a DOM structure, the individual tweets can't
contain sub-nodes, which means that if someone wants to use anchor tags
or whatever, they need to use < and > instead of < and >.

http://codereview.appspot.com/6068045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add announcements to the upper right corner of the website (issue 6068045)

[mike]

I also just realized that git-cl does not know how to play nicely with
the .xml extension, so the patch can't be tested.  I'll investigate...

http://codereview.appspot.com/6068045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add announcements to the upper right corner of the website (issue 6068045)

[mike]

Hmm...it looks like the xml mime type is defined, so I'm short on ideas
for why it's not uploading to Rietveld correctly.
Below are the contents of tweets.xml:




The Ensemble 101 is going on a European tour where they'll sing music
typeset using LilyPond.  Click here; to learn more!




http://codereview.appspot.com/6068045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add announcements to the upper right corner of the website (issue 6068045)

[mike]

On 2012/04/27 07:53:06, Graham Percival wrote:

On 2012/04/27 07:49:30, mike7 wrote:
> I also just realized that git-cl does not know how to play nicely

with the

.xml
> extension, so the patch can't be tested.  I'll investigate...



Have you tried adding it to line 26 of git-cl ?


I added:

mimetypes.add_type("application/xml", ".xml")

But to no avail :(

http://codereview.appspot.com/6068045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add announcements to the upper right corner of the website (issue 6068045)

[mike]

On 2012/04/27 07:55:54, Graham Percival wrote:

LGTM, one minor question but it's ok with me.



http://codereview.appspot.com/6068045/diff/13001/Documentation/web.texi

File Documentation/web.texi (right):



http://codereview.appspot.com/6068045/diff/13001/Documentation/web.texi#newcode172

Documentation/web.texi:172: xhttp=new

ActiveXObject("Microsoft.XMLHTTP");

My initial intuition is that there should be a simpler way to get the

contents

of a file on the same server, but I happily know almost nothing about
javascript.



If somebody else knows javascript, it would be great if they glanced

at this.

Check out http://www.w3schools.com/xml/xml_parser.asp.

http://codereview.appspot.com/6068045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Mentions separate build directory for website work (issue 6092045)

[mike]

On 2012/04/27 08:49:09, Graham Percival wrote:

http://codereview.appspot.com/6092045/diff/1/Documentation/contributor/website-work.itexi

File Documentation/contributor/website-work.itexi (right):



http://codereview.appspot.com/6092045/diff/1/Documentation/contributor/website-work.itexi#newcode81

Documentation/contributor/website-work.itexi:81: Note that the website

will fail

to build if you do not build it
Everybody *should* be building it in a separate directory, but I still

consider

it a bug that it doesn't work in the same directory.  Is it just

missing a mkdir

-p or something like that?


I think the problem is that it tries to do a blanket copy of everything
from the misc directory into the target directory, but if the build is
not in a separate build directory, then there will be "out/" in misc,
which is a directory.  If there were a sort of "lazy" copy command (i.e.
a copy that just failed silently on directories instead of crashing)
then it could be used instead.


http://codereview.appspot.com/6092045/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Potential issue 39 fix

[mike]

I've included before and after photos.

Cheers,
MS


0001-Potential-fix-for-issue-39.patch
Description: Binary data
<><>___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Quanting and issue 37

[mike]

Hey all,

I am trying to understand beam-quanting.cc better, and I think I know how I'm 
gonna tackle this.

I'm going to put my collision callback before beam quanting, and then try 
something to the effect of:

if (the beam was pushed up during the collision callback)
  impose an insanely prohibitive demerit for the beam position going down in 
the quanting
else if (the beam was pushed down during the collision callback)
  impose an insanely prohibitive demerit for the beam position going up in the 
quanting

Could anyone give me a quick primer on how to do that?

Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Potential fix for issue 1504. (issue4237057)

[mike]

On Mar 13, 2011, at 10:30 PM, hanw...@gmail.com wrote:

> 
> http://codereview.appspot.com/4237057/diff/11001/lily/beam.cc
> File lily/beam.cc (right):
> 
> http://codereview.appspot.com/4237057/diff/11001/lily/beam.cc#newcode206
> lily/beam.cc:206: orig->set_property ("feather-fraction", scm_cons
> (scm_from_double (0.0), scm_from_double (orig->spanner_length (;
> my suggestion was for fraction to be a real fraction, ie. a number from
> 0.0 to 1.0, relative to the total length of the beam. That also gives
> users a way to tune the featheriness they want from their beams (they
> could set it to 0.0 - 2.0 to exaggerate the effect for instance), in a
> scale-free way.  My idea was also to put the effect of feather-dir into
> this pair, ie. feather=LEFT =>  (1.0 . 0.0)  and RIGHT => (0.0 . 1.0)
> 
> Does that sound right? I think you would be able to do without
> feather-dir in the print callback.
> 
> http://codereview.appspot.com/4237057/diff/11001/lily/include/spanner.hh
> File lily/include/spanner.hh (right):
> 
> http://codereview.appspot.com/4237057/diff/11001/lily/include/spanner.hh#newcode76
> lily/include/spanner.hh:76: static int broken_spanner_index (Spanner
> const *sp);
> this can go now?
> 
> http://codereview.appspot.com/4237057/diff/11001/scm/define-grobs.scm
> File scm/define-grobs.scm (right):
> 
> http://codereview.appspot.com/4237057/diff/11001/scm/define-grobs.scm#newcode329
> scm/define-grobs.scm:329: (after-line-breaking .
> ,ly:beam::calc-feather-widths)
> I recommend hooking this up to feather-fraction directly, so you can be
> sure it's always calculated at the right time, namely, when needed.
> 
> Beyond setting the fractions for all beams,
> you'd have to return the fraction pair for the beam part on which the
> callback gets called

I've sketched this out using your suggestion above (calculating it once and 
returning the fraction for the called beam) - nevermind my previous question 
about redoing calculations. A new patch set is on-line.

I still need to do the math for the longer slopes - I'll have time to do that 
later today or tomorrow.

In the spirit of the one-change-per-push idea, I'd like to push the fix to 1504 
first before I push the change to feather-direction.  Does this seem like a 
good idea?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Better width functions for the current arpeggio print functions. (issue4517051)

[mike]

On May 11, 2011, at 12:02 PM, n.putt...@gmail.com wrote:

> 
> http://codereview.appspot.com/4517051/diff/1/lily/arpeggio.cc
> File lily/arpeggio.cc (right):
> 
> http://codereview.appspot.com/4517051/diff/1/lily/arpeggio.cc#newcode98
> lily/arpeggio.cc:98: MAKE_SCHEME_CALLBACK (Arpeggio, internal_print, 1);
> Why are you exporting these internal functions?
> 
> http://codereview.appspot.com/4517051/

The internal function idea is now bunk - you're right about the positions thing.

The issue is that, for the chord bracket and chord slur (and Bertrand's 
eventual chord brace, which hypothetically varies significantly in its X 
dimension as it gets larger), the width of the grob is dependent on knowing the 
extremal note head positions, which triggers a vertical alignment.  Any 
suggestions on how to get this information without triggering the vertical 
alignment?

Cheers,
MS


___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Implements multiple-line non-cross-staff glissandi (issue4527086)

[mike]

On Jun 12, 2011, at 5:49 PM, n.putt...@gmail.com wrote:

> On 2011/06/05 10:18:18, mike_apollinemike.com wrote:
>> On Jun 2, 2011, at 9:00 PM, mailto:n.putt...@gmail.com wrote:
> 
>>> 
>>> http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm
>>> File scm/output-lib.scm (right):
>>> 
>>> 
> http://codereview.appspot.com/4527086/diff/7002/scm/output-lib.scm#newcode795
>>> scm/output-lib.scm:795: (define-public
> (glissando::before-line-breaking
>>> grob)
>>> Possibly silly question: can't you fold this into callbacks for
>>> left-bound-info/right-bound-info instead?
> 
>> Sorry - I don't get what you mean :(  Could you please elaborate?
> 
> You're calculating a value for 'Y which you add back into bound-details.
> This bypasses the default calculation in calc_bound_info ().  Why not
> caculate 'Y when left-bound-info/right-bound-info is requested, either
> directly in C++ or as glissando-specific scheme versions?
> 

My goal is to bypass the default calculation and replace it with this one, and 
it is easier to harvest the information about Y placement relative to the staff 
before line breaking happens.  Currently, there is no mechanism in 
Line_spanner::calc_bound_info that can outsource the Y calculation to another 
function, and I wouldn't want to code dup all of the parts of 
Line_spanner::calc_bound_info that are worth keeping into a glissando specific 
function.  Taking that into account, does that seem like the right approach?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Need some input on a new patch for glissando-friendly stems

[mike]

Hey all,

I'm getting a patch together to implement glissandi stem (stems that link up to 
a glissando to indicate the glissando's duration to avoid awkwardness with ties 
- comes up all the time in Xenakis).
I have the C++ code working, but I'm looking for suggestions on the input 
syntax.  Currently, the input syntax is fairly hackish.  I'm looking for 
suggestions for not-too-ugly ways to input these glissandi stem (especially in 
relative contexts where the note values of the stem will have an impact on the 
next real note).

After I get some feedback, I'll put a patch on Reitveld for more formal 
reviewing.

Thanks!
~Mike



0001-Adds-glissando-stems-to-Lilypond.patch
Description: Binary data


glissando-stem.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Grobs that are their own ancestors.

[mike]

I've now gone on a quest for parental loops in the source, and I've found some:

chord-repetition.ly
chord-tremolo-articulations.ly
dynamics-alignment-breaker.ly
dynamics-alignment-no-line.ly
dynamics-glyphs.ly
dynamics-line.ly
dynamics-rest-positioning.ly
dynamics-text-right-padding.ly
dynamics-text-spanner-abs-dynamic.ly

After this I stopped checking, but in all of these, the DynamicLineSpanner is 
its own parent if you trace back its ancestry.  The culprit is line 179 of 
dynamic-align-engraver - if anyone has any intuition as to why this is the 
case, lemme know!  Otherwise, I'll be able to look into it next week.

Then, in context-die-staff.ly, in fixup_refpoint, a grob is passed a null 
pointer as its parent (the variable newparent).  Any ideas as to where this 
error may be coming from?

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

make check still failing with midis

[mike]

Hey all,

I finally got a new branch of the source up and running on my mac after 
updating fontforge, and even in the new branch, I get the following error 
during make check:

LILYPOND_VERSION=2.15.6 
/Library/Frameworks/Python.framework/Versions/2.7/bin/python 
../../../scripts/lilypond-book.py -I ./ -I ./out-test -I ../../../input -I 
/Users/mikesolomon/devel/regtests/Documentation -I 
/Users/mikesolomon/devel/regtests/Documentation/snippets -I 
../../../input/regression/ -I 
/Users/mikesolomon/devel/regtests/Documentation/included/ -I 
/Users/mikesolomon/devel/regtests/mf/out/ -I 
/Users/mikesolomon/devel/regtests/mf/out/ -I 
/Users/mikesolomon/devel/regtests/Documentation/pictures -I 
/Users/mikesolomon/devel/regtests/Documentation/pictures/./out-test 
--process='/Users/mikesolomon/devel/regtests/out/bin/lilypond -I ./ -I 
./out-test -I ../../../input -I /Users/mikesolomon/devel/regtests/Documentation 
-I /Users/mikesolomon/devel/regtests/Documentation/snippets -I 
../../../input/regression/ -I 
/Users/mikesolomon/devel/regtests/Documentation/included/ -I 
/Users/mikesolomon/devel/regtests/mf/out/ -I 
/Users/mikesolomon/devel/regtests/mf/out/ -I 
/Users/mikesolomon/devel/regtests/Documentation/pictures -I 
/Users/mikesolomon/devel/regtests/Documentation/pictures/./out-test 
-dbackend=eps --formats=ps  -dseparate-log-files -dinclude-eps-fonts 
-dgs-load-lily-fonts --header=texidoc -I 
/Users/mikesolomon/devel/regtests/Documentation/included/ -ddump-profile 
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1' 
--output=./out-test --format=texi   --skip-png-check --use-source-file-names 
--lily-output-dir /Users/mikesolomon/devel/regtests/out/lybook-testdb 
out-test/collated-files.tely
langdefs.py: warning: lilypond-doc gettext domain not found.
lilypond-book.py (GNU LilyPond) 2.15.6
Reading out-test/collated-files.tely...
Dissecting...
Writing snippets...
Processing...
Running lilypond...GNU LilyPond 2.15.6
Processing ./snippet-map--1734422213538672005
Processing 4e/lily-af17cfbb
Processing d0/lily-90de0c31
Processing 26/lily-95acd21c
Processing f4/lily-282ee984
Processing a7/lily-a015637a
Processing f5/lily-21288bb1
Processing c4/lily-8af3bc49
Processing d1/lily-09acdfae
Processing 1d/lily-2273d76e
Processing cd/lily-7f070535
Processing 0c/lily-b007ba40
Processing 6c/lily-bc46b4aa
Processing a4/lily-066676bc
Processing 70/lily-3ebc8269
Processing 1c/lily-e69a97ad
Failed files: (1c/lily-e69a97ad.ly 70/lily-3ebc8269.ly a4/lily-066676bc.ly 
6c/lily-bc46b4aa.ly 0c/lily-b007ba40.ly cd/lily-7f070535.ly 1d/lily-2273d76e.ly 
d1/lily-09acdfae.ly c4/lily-8af3bc49.ly f5/lily-21288bb1.ly a7/lily-a015637a.ly 
f4/lily-282ee984.ly 26/lily-95acd21c.ly d0/lily-90de0c31.ly 4e/lily-af17cfbb.ly)
command failed: /Users/mikesolomon/devel/regtests/out/bin/lilypond -I ./ -I 
./out-test -I ../../../input -I /Users/mikesolomon/devel/regtests/Documentation 
-I /Users/mikesolomon/devel/regtests/Documentation/snippets -I 
../../../input/regression/ -I 
/Users/mikesolomon/devel/regtests/Documentation/included/ -I 
/Users/mikesolomon/devel/regtests/mf/out/ -I 
/Users/mikesolomon/devel/regtests/mf/out/ -I 
/Users/mikesolomon/devel/regtests/Documentation/pictures -I 
/Users/mikesolomon/devel/regtests/Documentation/pictures/./out-test 
-dbackend=eps --formats=ps  -dseparate-log-files -dinclude-eps-fonts 
-dgs-load-lily-fonts --header=texidoc -I 
/Users/mikesolomon/devel/regtests/Documentation/included/ -ddump-profile 
-dcheck-internal-types -ddump-signatures -danti-alias-factor=1 -I  
"/Users/mikesolomon/devel/regtests/out/lybook-testdb"  -I  
"/Users/mikesolomon/devel/regtests/input/regression/midi"  -I  
"/Users/mikesolomon/devel/regtests/input/regression/midi"  -I  
"/Users/mikesolomon/devel/regtests/input/regression/midi/out-test"  -I  
"/Users/mikesolomon/devel/regtests/input"  -I  
"/Users/mikesolomon/devel/regtests/Documentation"  -I  
"/Users/mikesolomon/devel/regtests/Documentation/snippets"  -I  
"/Users/mikesolomon/devel/regtests/input/regression"  -I  
"/Users/mikesolomon/devel/regtests/Documentation/included"  -I  
"/Users/mikesolomon/devel/regtests/mf/out"  -I  
"/Users/mikesolomon/devel/regtests/mf/out"  -I  
"/Users/mikesolomon/devel/regtests/Documentation/pictures"  -I  
"/Users/mikesolomon/devel/regtests/Documentation/pictures/out-test" 
--formats=eps  -deps-box-padding=3.00  -dread-file-list 
-dno-strip-output-dir  
"/Users/mikesolomon/devel/regtests/out/lybook-testdb/snippet-names--1734422213538672005.ly"
Child returned 1
make[2]: *** [out-test/collated-files.texi] Error 1
rm out-test/rest-dynamic.midi out-test/quantize-duration-2.midi 
out-test/key-option-all-staves.midi out-test/quantize-duration.midi 
out-test/voice-4.midi out-test/quantize-start.midi out-test/voice-2.midi 
out-test/key-option.midi out-test/key-initial.midi out-test/partcombine.midi 
out-test/lyrics-addlyrics.midi out-test/rest.midi out-test/staff-map-voice.midi 
out-test/voice-5.midi out-test/staff-map-instrument.midi
make[1]: *

Re: \footnote 'bug' (or not?)

[mike]

On Jul 24, 2011, at 11:42 PM, Neil Puttock wrote:

> On 24 July 2011 19:51, m...@apollinemike.com  wrote:
>> On Jul 24, 2011, at 6:43 PM, James Lowe wrote:
>> 
>>> Hello,
>>> 
>>> From Neil P. explaining the finer points of footnote code, while looking at 
>>> my in-progress Doc patch for footnotes
>>> 
>>> --snip--
>>> 
>>> \footnote associates a single footnote with a particular event in the
>>> music (usually a NoteEvent); in a certain sense it behaves like
>>> \tweak, though I'd suggest to Mike that it actually be changed so its
>>> behaviour is identical.  Currently we have the situation where it's
>>> awkward to add footnotes to individual scripts and fingerings:
>>> 
>>> \relative c' {
>>> < c-1-\footnote #'(1 . 2) "foo" "bar" >
>>> }
>>> 
>> 
>> This works as such because it is within a chord.  \footnote is written to 
>> work like \tweak.
> 
> Please re-read my suggestion.  \footnote doesn't work like tweak; if
> it did, it would have music as the last argument, and apply the
> FootnoteEvent to the following music.  I suggested this precisely
> since it's not possible to add a footnote to a specific post-event
> (mainly fingerings and articulations).  The documentation is at fault
> here (it started with \balloon, since it implies it's similar to
> \tweak).

Sorry - I missed your original suggestion :(  I'll look for it!

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Makes parameters for hairpin rotation available in Scheme (issue4809051)

[mike]

On Jul 24, 2011, at 11:29 PM, Neil Puttock wrote:

> On 23 July 2011 15:48,   wrote:
> 
>> (a) is currently impossible to calculate in all circumstances, and (c)
>> would require a code dup.  I think by making these available as
>> properties, the user can then use this data to fix the problem.  In the
>> example given in Issue 36, I would personally rotate the stencil
>> downwards, and this patch would give me all the data necessary to create
>> an override for Beam #'rotation.
> 
> This is too specific to hairpins.  Most grobs collide with beams when
> they're cross-staff, so a more generic solution is required.
> 

We may want to just fix issue 36 via something in the docs- you're absolutely 
right about the many collisions, and it is easy enough to create a Scheme 
engraver that acknowledges beams and spanners and adds cross staff beam to a 
grob array of the spanner than can be subsequently accessed to rotate/move/etc. 
 Were there one obvious solution to the problem, I'd advocate incorporating it 
into LilyPond, but as there is no clear way to deal with these collisions, 
perhaps a section in the documentation "Dealing with collisions" that says 
something to the effect of "LilyPond does its best to avoid collisions between 
objects.  However, often there is more than one solution available to collision 
avoidance - white out, moving, rotating, etc..  Rather than taking any one of 
these actions automatically, LilyPond provides the user tools to make these 
decisions with respect to any given collision."  Then, show the whiteout 
solution, custom engraver solution, etc..

Cheers,
MS
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: 2.16 around the corner

[mike]

On Wed, 7 Sep 2011 11:17:59 +0100, Graham Percival wrote:

We have now reached 0 Critical issues.  It would be great if we
could verify the fixed issues, and if we could find out if
anything broke in 2.15.10.

Once that's done, I'll go ahead with release candidate 2,
hopefully in a few days.  Then we'll be into a 7-day countdown for
Critical issues; there's a decent chance of 2.16 happening in
September.



Hey all from sunny Crete !

Just a note - if 2.16.0 is around the corner, I'll need to make sure 
that all of the flags that are supposed to be transparent in the docs 
(meaning all flags that had their stems set as transparent) are in fact 
transparent.  I did my best with this, but I know I missed this in 
Trevor Baca's Cary (and perhaps other stuff as well).  idem for stroke 
style and other once-Stem-now-Flag properties.


Back to the beach!

Cheers,
MS

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Excludes grobs supported by cross-staff grobs from pure-relevant calculations (issue 12857043)

[mike]

https://codereview.appspot.com/12857043/diff/3001/lily/side-position-interface.cc
File lily/side-position-interface.cc (right):

https://codereview.appspot.com/12857043/diff/3001/lily/side-position-interface.cc#newcode283
lily/side-position-interface.cc:283: && cross_staff
On 2013/08/14 05:34:18, Keith wrote:

Under these conditions,
  trying to estimate before line-breaking  (pure)
  where an object 'me' will align vertically (Y_AXIS)
  against an object 'e' whose position depends on staff-spacing

(cross-staff)

we might want to skip this object 'e', whether 'e' is a stem or not.



If it is a stem, since we know it is cross-staff, is the test on the

next line

of the stem's direction going to be reliable ?  It seems best to skip

the stem

and estimate the alignment against the remaining objects in 'support'.


Great ideas - I like this better.  Will do.

https://codereview.appspot.com/12857043/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Remove DynamicText from script-interface (issue 14424044)

[mike]

Make sure to acknowledge dynamic text in slur-proto-engraver.cc and
tuplet-engraver.cc.

https://codereview.appspot.com/14424044/

___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel

RE: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Janek Warchoł  writes:

> Hi,
>
> śr., 5 lut 2020, 00:34 użytkownik  napisał:
>
>> What problem are we trying to solve here?
>>
>
> In short, it's been found (I think Mike will be able to give you 
> specific
> examples) that having code of conduct encourages contributions from 
> newcomers.

> I rather think that a friendly atmosphere encourages contributions from 
> newcomers.  Whether an upfront requirement to commit to a set of rules with 
> an enforcement team is perceived as a guarantee of a friendly atmosphere is 
> debatable.

I personally would feel more comfortable if there were a code of conduct, and I 
know within my company one employee will not attend a conference or participate 
in a project unless there is a code of conduct.  I don't have any hard stats to 
prove this, but have a gut feeling that a code of conduct opens more doors than 
it closes.

> So in light of my personal experiences with this kind of backroom channel 
> (and it's worth noting that even the cited Linux developer list removed the 
> corrective measures part from the CoC they are using), I would very much like 
> to see some more imminent reason of why LilyPond would stand to benefit from 
> adopting a code and accepting a corrective committee that has basically 
> proposed itself rather than being the result of a list-wide election and 
> where just one member has been a permanent fixture on the lists for a longer 
> amount of time at this moment.

A list-wide election is a good idea.

At the Salzburg meetup, one common thing a lot of people brought up was a 
slow-down in development and a shrinking pool of contributors.  IMO we should 
do several experiments to fix this. The CoC I proposed is used in over 40,000 
projects including many of the most active and diverse open source projects on 
github, so it seems like a reasonable experiment. If it proves to be a dud, we 
can get rid of it.

~Mike

RE: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Mike Solomon  writes:

> The preamble and intent is one thing; adding a corrective committee with the 
> authority to enact punishments based on anonymous reports is another.  It 
> implements hierarchies and institutions exerting coercive power based on 
> incomplete and secret information.  That is inherently an entity offering an 
> opportunity for "pulling strings".  I am not really a fan of constructs with 
> a life and dynamics of their own.

It's a big responsibility. I think the way to do it is talk to successful 
committees (ie the Facebook Open Source CoC Committee) and learn how they've 
dealt with challenging situations.

One example: in communities that are more gender balanced, I've heard of 
situations where a man starts writing inappropriate messages to a woman and she 
reports the messages to the CoC committee.  In this case, I think secrecy, 
hierarchy and coercive decision making power is important to preserve the 
dignity of all parties.  It also encourages people to come forward, which is 
much harder to do in the open.

I don't know of many communities with good gender balance that don’t have codes 
of conduct, probably for this reason.  Ultimately, I think the benefits of 
secrecy, hierarchy and possible coercion in matters of conduct outweigh the 
negatives, although I agree with you that secrecy and hierarchy should be the 
exception and not the rule. Most communication should be in the open and 
hierarchy free.

Thanks,
~Mike

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

One procedural question: what are acceptance procedures for a PR like this? 
There is good debate and a variety of opinions, but at a certain point we will 
need to make a decision - do we implement the CoC or not? I doubt that any new 
arguments will emerge on either side.  David has made several good arguments 
against it, and while the points are valid, they don't outweigh IMO the 
potential for it to improve the problem of low contribution volume and a 
shrinking pool of developers. I'm also admittedly biased in that I don't feel 
comfortable contributing unless there is a code of conduct with clear steps for 
reporting violations and consequences for repeat offenders, so I'm probably not 
the best person to make the final call.

~Mike

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

> What does "implement" mean?

Sorry, I wasn't clear. I meant merge the PR.

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

Mike Solomon  writes:

>> What does "implement" mean?
>
> Sorry, I wasn't clear. I meant merge the PR.

> Uh, words have meanings.  There would be no point of putting something
into our documentation that we are not going to follow through with.

By merging it, the idea would be that the first committee of 3 started acting 
as a CoC committee.

What are the blockers to making a decision about this patch? Does it need more 
discussion or more buy in? As I've been out of the community for so long, I no 
longer have a sense of when things are merged.

~Mike

Re: Add Code of Conduct (issue 575620043 by janek.lilyp...@gmail.com)

[Mike Solomon]

On 2020/02/05 18:17:25, c_sorensen wrote:
> I recognize that Mike Solomon has a different opinion.  I mean no
disrespect to
> Mike, Janek, Han-Wen, or any other member of the LilyPond team.  I
highly value
> the team spirit of the LilyPond team.

>Well said.  Here's the current tally as I understand it:
>For: Han-Wen, Janek, Mike, Urs, Werner
>Against: Carl, Dan, David K., Trevor
>Mixed: David N.

Mike, you asked,
> What are the blockers to making a decision about this patch?
> Does it need more discussion or more buy in?

>5-4 halfway through the first day doesn't look like buy-in to me.

That's a really good point and I see where Carl and David N are coming from. It 
seems like a Code of Conduct is not a good fit at this time. More people in the 
community would need to come around to the idea for it to work.

Maybe what I'll do is touch base in a few months and see if any opinions have 
changed, including of course my own. In the meantime, I would encourage people 
to reflect on LilyPond's shrinking number of contributions and developers and 
consider if a lack of a code of conduct could be one of the reasons it is 
difficult to grow. As a benchmark, one good place to look is the Contributors 
Covenant website. There is a list of communities that have implemented it. Ask 
the maintainers how they feel about it, cite the concerns brought up here, and 
ask if they feel it could, from their outsider perspective, be helpful for 
LilyPond. I know that, personally, I have really appreciated the code of 
conduct in projects that I have contributed to since leaving LilyPond 
development. I have also appreciated the relative ideological and demographic 
diversity of those projects, which has introduced me to perspectives about race 
and gender that are lacking in the LilyPond community.

It could of course also be the case that people are happy with the status quo 
in LilyPond, in which case it (or other things to grow the community in size 
and inclusivity) are not necessary. I personally am saddened by my own leaving, 
the leaving of others, the lack of growth and the lack of diversity, and this 
is one proposal to start changing it, but I understand the objections.

~Mike

Re: 5th anniversary conference? :)

[Mike Blackstock]

re. possible toronto conference location

I live in Toronto, in the Annex.  I'd love to help organize something here
if there's interest. I'm right
close to the  University of Toronto campus.

-Mike

On Thu, 15 Feb 2024 at 09:19, Kieren MacMillan 
wrote:

> Hey all,
>
> >> I was just waxing nostalgic about that fabulous Salzburg conference in
> 2020, and noted that in Jan 2025 — just under a year from now! — it will
> have been five years since we got together, talked music/notation, and
> raised [more than] a few pints together.
> >> Any chance for a repeat? :)
> >
> > Would be great. Count me as "will try to come if it gets organized".
>
> As I said back then, I’d be more than happy to organize a conference here
> in Toronto… but we decided that too many people would have to travel this
> direction over the Atlantic. It really does seem to be most efficient to
> hold this kind of gathering in Europe somewhere.
>
> Cheers,
> Kieren
> __
>
> My work day may look different than your work day. Please do not feel
> obligated to read or respond to this email outside of your normal working
> hours.
>
>
>

-- 
https://blackstock.media

Re: 5th anniversary conference? :)

[Mike Blackstock]

re "Let’s keep this discussion going... I teach in the Annex (Randolph
College) three times a week — we should grab lunch/tea/pints some day.  "

For sure... I live at Bloor/Albany, just a few minutes walk from Randolph;
I walk past Randolph
all the time but didn't know it was a college. Right next door is the
Centre for Social Innovation,
which I've played at a few times for Amnesty International's annual
get-together there.

I propose  a get-together at the Annex Billiards Club, just above the Bulk
Barn on Bloor... cheap pints, good
billiards tables, nice atmosphere. I live 2 minutes away... I can be there
on a moment's notice, starting next week.

This is exciting!

On Fri, 23 Feb 2024 at 07:48, Kieren MacMillan 
wrote:

> Hi Mike!
>
> > I live in Toronto, in the Annex.  I'd love to help organize something
> here if there's interest. I'm right
> > close to the  University of Toronto campus.
>
> 1. Let’s keep this discussion going, and see if it actually gains traction!
>
> 2. I teach in the Annex (Randolph College) three times a week — we should
> grab lunch/tea/pints some day.  :)
>
> Cheers,
> Kieren.
> __
>
> My work day may look different than your work day. Please do not feel
> obligated to read or respond to this email outside of your normal working
> hours.
>
>

-- 
https://blackstock.media

woodwind diagrams in lilypond (http://codereview.appspot.com/1385041)

[Mike Solomon]

Hello lilypond developers,
At http://codereview.appspot.com/1385041, you will find a patch that
implements several woodwind diagrams (piccolo, flute, oboe, clarinet, bass
clarinet, saxophone, bassoon, and contrabassoon) in Lilypond.  I would very
much appreciate any and all comments on this new feature, specifically with
respect to the following three questions:

1) Are the diagrams correct?
2) Do the diagrams look nice?
3) Is the code in the patchelegant?

Attached are two .ly files that take the patch for a spin.

Thank you all for taking this patch into consideration, and I look forward
to working with you towards its amelioration as well as the creation of
user-friendly documentation.  If there winds up being enough community
support, I would be thrilled to see this feature included in the Lilypond
source code.

Mike Solomon



woodwind-diagrams-text-graphic.ly
Description: Binary data


woodwind-diagrams-key-by-key.ly
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Calculations for spanner before its print function is called

[Mike Solomon]

Hey lilypond developers,
I am toying around with a new spanner, and before it prints, I need to
do some calculations on all of its broken_intos_.  I can easily do these
calculations in the print function by accessing the broken_into_ of
spanner->original (), but then this calculation is done for each time print
is called, which is N-1 times too many (where N is the length of
broken_into_).  The code works just fine, but it is overkill: is there a way
to perform operations on a spanner and its broken_into_'s once before the
print function is called?

Thanks!
~Mike 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Calculations for spanner before its print function is called

[Mike Solomon]

I tried setting a flag like that, but the problem is that the stencils are
drawn in parallel and not in series, so by the time I've set this flag the
other stencils are done doing their thing :-(

~Mike


On 6/2/10 1:32 PM, "Carl Sorensen"  wrote:

> On 6/2/10 5:28 AM, "Mike Solomon"  wrote:
> 
>> Hey lilypond developers,
>> I am toying around with a new spanner, and before it prints, I need to
>> do some calculations on all of its broken_intos_.  I can easily do these
>> calculations in the print function by accessing the broken_into_ of
>> spanner->original (), but then this calculation is done for each time print
>> is called, which is N-1 times too many (where N is the length of
>> broken_into_).  The code works just fine, but it is overkill: is there a way
>> to perform operations on a spanner and its broken_into_'s once before the
>> print function is called?
> 
> You could decrease the calculation time by setting a flag in the original
> spanner (e.g. calculation_done_) and skip the calculation if it had been
> done.
> 
> Somebody else will probably have a better idea.
> 
> Thanks,
> 
> Carl
> 
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Calculations for spanner before its print function is called

[Mike Solomon]

Good deal!  I used a callback - patch to be sent in the not-too-distant
future.

~Mike

On 6/2/10 4:26 PM, "Han-Wen Nienhuys"  wrote:

> On Wed, Jun 2, 2010 at 8:28 AM, Mike Solomon  wrote:
>>    I am toying around with a new spanner, and before it prints, I need to
>> do some calculations on all of its broken_intos_.  I can easily do these
>> calculations in the print function by accessing the broken_into_ of
>> spanner->original (), but then this calculation is done for each time print
>> is called, which is N-1 times too many (where N is the length of
>> broken_into_).  The code works just fine, but it is overkill: is there a way
>> to perform operations on a spanner and its broken_into_'s once before the
>> print function is called?
> 
> Use a property with an attached callback to either hold the
> computation result. The callback/property infrastructure will make
> sure it  happens only once.  What are you trying to calculate?  You
> can also have a look at some of the callbacks that attach to
> 'positioning-done, see for example the vertical alignment spanners.
> 
> Since LilyPond is single-threaded, nothing really happens in parallel.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

New patch for waveforms

[Mike Solomon]

Hey lilypond developers,

As I am not good at posting patches on Rietveld, I submit to you the 2nd of
a two-patch diptych via the following link:
  http://www.apollinemike.com/lilypond/waveform
where you'll find a patch along with several files necessary to test it out.
Please play with it, try to break it, and let me know what you think.  This,
along with woodwind-diagrams, has been very useful for me in a recent piece
I composed, and I hope it can be useful for the lilypond community as well.

The basic idea is that it draws waveforms from text-files.  All the file
needs to contain is a list of values that constitute the height of the wave.
Then, using the following syntax, you put the wave in a score.

\relative c' {
  \waveformBegin #"foobar.txt" 
  \waveformPoint #0.3  % you want the 3/10 point of the form to
hit here
   \waveformPoint #0.9  & ditto for 9/10
   \waveformEnd 
}

Note that \waveformBegin, \waveformPoint, and \waveformEnd are all music
functions, so they apply to the note AFTER the command.

If you apply the patch, dump all the attached files into a directory, and
run lilypond, it should make nice waves.  And the waves fluctuate smoothly
to hit their control points, which is why waveform.cc has a lot of code
(although it probably could be shorter...suggestions for cuts are
appreciated!).

I use it both to indicate changes in vibrato (a notable improvement over my
heinous contemporary vibrato thingee on the LSR, which can be expediently
removed once this is polished into shape) AND to put recordings of an
electroacoustic track in a score and have it visualized.

One of the patch's features is that its guts (and by guts I mean its
callback calculate_broken_wave_placements) can work, in theory, with
anything that has a sampling rate, including spectrograms and graphical
scores.

Many thanks to the first one of you who posts this on Rietveld!

Cheers,
~Mike

P.S. One thing that the code lacks is stable control of intersections w/
this grob and others - is there a standard way to take care of that?  I
cheated in the included examples and overrode spacing stuff so that you can
see the waveforms w/o them bumping into anything.

P.P.S. THIS CODE CREATES NEW FILES!  So that you don't overwrite anything,
make sure to work in a clean directory.  Specifically, if you run all of the
files on the website, you will create the following new files in your
working directory:

wave.txt.0
wave.txt.1
wave.txt.2
wave.txt.3
wave.txt.4
wave.txt.5
wave.txt.6
wave.txt.7
wave.txt.8
wavetest_downsampled100.txt.0
wavetest_downsampled100.txt.1
wavetest_downsampled100.txt.2
wavetest_downsampled100.txt.3
wavetest_downsampled100.txt.4
wavetest_downsampled100.txt.5
wavetest_downsampled100.txt.6
wavetest_downsampled100.txt.7
wavetest_downsampled100.txt.8

P.P.P.S. I know nothing about Lilypond's translation process, although word
on the street is that it is very involved.  I'd be happy to beautify my
programming_error code accordingly once I know who needs to translate what.

P.P.P.P.S. I do all my vibrato generating using scipy and all of my
audio->text-file work in SuperCollider, in case any of you want to play with
generating new files that can take the patch for a spin.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Addendum for new patch

[Mike Solomon]

Hey all,
For those who try to apply my patch, it won't apply unless you apply my
woodwind diagram patch first.  This patch, 0001-Woodwind-diagrams.patch, is
on the same site as in the previous email
(http://www.apollinemike.com/lilypond/waveform) & is bug-free (as far as I
know).  Sorry about the inconvenience, and thanks in advance for your
feedback!

~Mike






___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Patch fixed - please post on Rietveld! (Re: New patch for waveforms)

[Mike Solomon]

Patch is fixed:

http://www.apollinemike.com/lilypond/waveform/0002-Waveform.patch

Could someone please throw it up on Reitveld?

As for the translation, I'm talking about language translators.  I'm not
sure if the strings in my programming_errors are sufficiently clear to be
translateable - I read the bit online about how they should be formulated,
but I'd appreciate any comments on the subject in case I'm off the mark.

Thanks!
~Mike

On 6/7/10 12:42 AM, "Francisco Vila"  wrote:

> 2010/6/6 Mike Solomon :
>> P.P.P.S. I know nothing about Lilypond's translation process, although word
>> on the street is that it is very involved.  I'd be happy to beautify my
>> programming_error code accordingly once I know who needs to translate what.
> 
> Are we talking about those dwarfs that do things in lilypond, or
> language translators as in Spanish and the like?
> 
> Translators translate strings, not code.



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Dependencies in Lilypond

[Mike Solomon]

Hey Carl,
Your bezier curve suite is wonderful - I need the solver for an entirely
different issue in my waveforms project, which is itching to be thrown on
Reitveld by someone who is more savvy than I!  Takers?

~Mike


On 6/8/10 5:59 PM, "Carl Sorensen"  wrote:

> \On 6/8/10 7:46 AM, "Jan Nieuwenhuizen"  wrote:
> 
>> Op dinsdag 08-06-2010 om 12:55 uur [tijdzone +0200], schreef Mike
>> Solomon:
>>> 2)  If I can't, do you know of a functional reduce-row-echelon c++ or c file
>>> that I can freely copy and paste?  All of the one's I've found are buggy for
>>> certain matrices, but gsl gets it right every time.
>> 
>> I don't but you may want to have a look at boost, IWBN to use more of
>> boost, eg boost::filesystem and such.
> 
> Mike,
> 
> If you just need a row-reduced-echelon conversion for fitting bezier curves
> through a series of points, don't go that way!  It works, but it's not even
> close to computationally efficient.
> 
> I've attached a chapter of notes provided by Tom Sederberg at BYU, a world
> expert on splines.  There's a trivially simple way to get a 3rd order bezier
> to go through 4 control points, through the use of Lagrange Interpolation.
> The Lagrange Polynomials that are used are independent of the control
> points. See Section 6.2 of the attached chapter.
> 
> HTH,
> 
> Carl
> 
> P.S. If you have more stuff you want to do with Beziers, give me a shout.
> I've taken Dr. Sederberg's class, so I'm somewhat aware of clever tricks
> with splines.  That's where my bezier stuff came from earlier.
> 
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: the four Meisters of the lilypocalypse

[Mike Solomon]

I second the Frog Meister idea: Carl has been VERY kind in helping me waddle
through Scheme programming, and if there is no one w/ the assigned
responsibility to farm out tasks, then I will likely keep pestering him out
of force of habit.

~Mike

On 6/11/10 9:23 PM, "Graham Percival"  wrote:

> As we all know, we've been losing bug reports.  We're expanding
> the Bug Squad in an attempt to avoid this, but that creates other
> organizational problems: somebody needs to train the new
> volunteers, somebody needs to coordinate their activities, etc.
> 
> I'm thinking that we should have a Bug Meister, but unlike the
> previous job of the same title, this person would *not* be
> processing bugs himself -- instead, his job would be to train,
> organize, and manage the Bug Squad.  (obviously the Bug Meister
> would need to step in from time to time, but ideally the Bug
> Meister would do no "real" work himself)
> 
> 
> At the same time, we might as well standardize on the "Meister"
> title -- a "Meister" will be somebody who organizes a team.  Thus,
> 
> * Bug Meister: trains new helpers, organizes who does what, has
>   the final say on our policy for Issues, and checks to make sure
>   everything is working.  If anybody has a problem or suggestion
>   for the way that the Bug Squad is functioning (or not), take it up
>   with the Bug Meister and let him deal with it.
> 
>   This is currently me, but I don't want to do it.  I can think of
>   a few candidates who could take it over immediately.
> 
> * Doc Meister: trains new editors/writers, organizes who does
>   what, has final say over doc policy, checks to make sure
>   everything is working.
> 
>   This is currently me, but I don't want to do it.  I can think of
>   a few people who might take it over in a few months, but nobody
>   in the near future.
> 
> * Translation Meister: trains new translators, organizes who does
>   what (if necessary?), and handles merging branches.  When
>   the translators add a new file and don't add it to GNUmakefile,
>   I get to yell at this person.
> 
>   This used to be John, but I believe that we don't have a
>   dedicated, specified person for it now.  I've seen Francisco
>   doing the merging often, but IIRC I've seen a few other people
>   as well.  I think we should make Francisco the official
>   Translation Meister
> 
> * Frog Meister: is responsible for code patches from (relatively)
>   inexperienced contributors.  Keep track of them, do initial
>   reviewing of those patches, send them on to the general -devel
>   community, pester said community into actually reviewing the
>   patch(es), and finally pushing the patch once it's accepted.
> 
>   Unlike the other Meisters, the Frog Meister is not responsible
>   for training new volunteers in how to do their job (i.e.
>   program); that would be far too much of a burden.
> 
>   I think that Carl has been doing a fantastic job and there's
>   no reason to change anything, but if he wants a break, I can
>   think of a few candidates who could do this immediately.
> 
> 
> I don't think we need, or that people would accept, a Meister for
> patches from experienced developers.  If you want to propose this,
> or start some kind of discussion along those lines, please wait a
> week -- I want to get a stable, functioning Bug Squad, so that I
> can put the finishing technical touches on the new website and
> finally get it switched over.
> 
> Cheers,
> - Graham
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Call for help to those who are good at symbolic math and/or algorithm construction (especially those who work w/ filters)

[Mike Solomon]

Hey lilypond developers,
I have an algorithm I'm working on for my waveform patch and I am not
good (or patient) enough at symbolic math to make any headway w/ it.  In the
attached python file (which needs numpy to run), line 106 uses linalg.solve
to solve a system of equations with fairly regular properties (all of which
are commented in the code).  I have a hunch that there is a way to describe
the results of this algorithm (discounting the first len(B) values, which
are lagrangian multipliers) as a sequence (in open or closed form) using
array A & B 's constituent members as well as their lengths (which are the
same, meaning that len(A) = len(B)).  Knowing this would save the pain of
using traditional linear algebra solvers, which for a 23x23 matrix is ok,
but for a 10x10 matrix gets cumbersome.

Thank you in advance to any takers who want to help me with this!!!

~Mike

P.S. Extra brownie points to anybody who devises a
not-too-computationally-expensive-to-solve constraint that guarantees only
positive values for all elements of the result vector ranging from len(B) to
len(B)+len(A) (the from 0 to len(B) are lagrangian multipliers).

P.P.S. Double extra brownie points for anyone who can state the algorithm in
continuous form.  My intuition tells me that it would be some sorta
convolution between a periodic signal (see matrix IV) and several impulses
(see matrix III) with different heights (see matrix II).



system4.py
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Woodwind diagrams (issue1425041)

[Mike Solomon]

Thank you Patrick!
All of your comments have been incorporated into a new patch, which draws
the svgs a-ok (see attached).

~Mike


On 6/19/10 12:42 AM, "pnor...@gmail.com"  wrote:

> Hi Mike,
> 
> This is very impressive.  Thanks for your work on this.  I just have a
> few comments for you about the SVG-related code.
> 
> Thanks,
> Patrick
> 
> 
> http://codereview.appspot.com/1425041/diff/12001/13007
> File scm/lily-library.scm (right):
> 
> http://codereview.appspot.com/1425041/diff/12001/13007#newcode583
> scm/lily-library.scm:583:
> If you want to use these procedures in output-svg.scm, they all need to
> be `define-public'-ified.  Like so:
> 
> (define-public PI (* 4 (atan 1)))
> 
> etc.
> 
> http://codereview.appspot.com/1425041/diff/12001/13010
> File scm/output-svg.scm (right):
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode352
> scm/output-svg.scm:352: (define (partial-ellipse x-radius y-radius
> start-angle end-angle thick connect fill)
> Move the definition of `new-start-angle' to here so that this code will
> compile (`new-start-angle' is used in `make-ellipse-radius')
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode362
> scm/output-svg.scm:362: (new-end-angle (* PI-OVER-180 (angle-0-360
> end-angle)))
> PI-OVER-180 and other procedures will work once you make the changes in
> lily-library.scm.
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode399
> scm/output-svg.scm:399: (if
> Please condense this block like so:
> 
> (if connect
>  (ly:format "L~4f,~4f"
>   (* start-radius (cos new-start-angle))
>   (- (* start-radius (sin new-start-angle
>  "")))
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode418
> scm/output-svg.scm:418: ;; Hopefully will be mitigated by ~4f below.
> Uh, how is this a security risk?  PS code is not interpreted by SVG
> agents, and here we are just dealing with simple numbers and strings
> that turn into SVG markup.
> 
> http://codereview.appspot.com/1425041/diff/12001/13010#newcode421
> scm/output-svg.scm:421: (string-concatenate
> I would condense this block too, to make it more readable:
> 
> (string-concatenate
>(map (lambda (x)
> (apply
>   (if (eq? (length x) 6)
>   (lambda (x1 x2 x3 x4 x5 x6)
> (ly:format "C~4f ~4f ~4f ~4f ~4f ~4f"
>(* x1 x-scale)
>(- (* x2 y-scale))
>(* x3 x-scale)
>(- (* x4 y-scale))
>(* x5 x-scale)
>(- (* x6 y-scale
>   (lambda (x1 x2)
> (ly:format "L~4f ~4f"
>(* x-scale x1)
>(- (* y-scale x2)
>   x))
> pointlist))
> 
> http://codereview.appspot.com/1425041/show
> 



svgtest.svg
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Dependencies in Lilypond

[Mike Solomon]

Hey all,
Sorry for the silence w/ respect to this issue: I've been trying to make
due w/o dependencies on my waveform patch and, finally, it looks like I'll
need glpk to make it happen: I was able to dispense with gsl, but the linear
programming algorithms I'm using are too involved to copy and paste a chunk
of code into lilypond.
To that end, I have three questions:

1)  How would I create a separate branch?
2)  Would it be worth it simply to include glpk in my patch?  It requires no
dependencies itself to compile and it is lightweight, so it could become
"part" of lilypond, but I don't know if that's how things roll chez GNU.
3)  Would it be possible as a middleground of sorts to create an "optional"
dependency in lilypond?  That is, look for glpk and compile the waveforms
stuff only if it is found?  I figured out a way to write that bit of code in
the configure file if said maneuver is ok.

~Mike


On 6/8/10 4:08 PM, "Graham Percival"  wrote:

> On Tue, Jun 08, 2010 at 03:46:47PM +0200, Jan Nieuwenhuizen wrote:
>> Op dinsdag 08-06-2010 om 12:55 uur [tijdzone +0200], schreef Mike
>> Solomon:
>> [cc: lilypond-devel, for the archives]
>> 
>> Hi Mike,
>> 
>>> 1)  Can I add a new dependency, and if so, where would I indicate the
>>> necessity of said dependency?
>> 
>>configure.in (write/copy and paste a test)
>>Documentation/included/compile.itexi
>> and in GUB, in
>>gub/specs/lilypond.py (add as dependency)
>>gub/specs/libgsl.py (write new recipe)
> 
> However, be aware that we've frozen the dependencies (see issue
> 963), so your patch almost certainly won't be accepted for 2.14.
> That's no reason to halt work, of course; your patch could still
> be merged on to a separate branch it git.
> 
> 
> Alternatively, since this is AFAIK the first time we've tried to
> have a dependency freeze, I could unfreeze it for a week, let
> everybody update everything, and *then* call a freeze.  I would
> still be **extremely** unhappy if lilybuntu broke, but if there
> was an overwhelming desire to add new dependencies, we could
> investigate creating a cut&paste series of apt-get commands to
> add/upgrade the required packages on lilybuntu.
> 
> I don't think we should allow patches that break lilybuntu beyond
> cut&paste fixing until lilybuntu 2 is out, though.
> 
> Cheers,
> - Graham
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Add \path markup command, and use it for \eyeglasses. (issue1730044)

[Mike Solomon]

Sorry - I should have replied to this earlier, but I was away from my
computer.
In woodwinds, I believe that the "make-connected-shape-stencil" does exactly
this - I use it to draw paths and automate finding extents.  Rather than
adding two things w/ similar functionalities to Lilypond, I think it would
be intelligent to roll both of them into one.  Patrick: can you look at the
patch and let me know what you think?  I have no objection to changing my
work if you feel that there is a better way to implement it along the lines
of the patch that you've uploaded.

~Mike


On 6/26/10 2:06 AM, "pnor...@gmail.com"  wrote:

> On 2010/06/22 03:50:24, Carl wrote:
>> On 2010/06/21 22:39:53, Patrick McCarty wrote:
>>> On 2010/06/20 11:07:37, Carl wrote:
>>>> Is it possible to have the path command estimate reasonable
>>>> extents, rather than using (0 . 0) and (0 . 0)?  Since we
>>>> know the thickness of the line, and we have a list of
>>>> points, it seems we should be able to keep track of the
>>>> maximum and minimum X and Y coordinates during the path
>>>> creation.
>>> 
>>> This should be possible, but I'm not sure how to implement it,
>>> especially when relative coordinates are involved.
> 
>> My first thought would be to start with currentx=currenty=
>> xmax=xmin=ymax=ymin = 0.
> 
>> For an absolute move, set currentx = move x, currenty = move y.
> 
>> For a relative move, set currentx += movex, currenty += movey.
> 
>> If currentx > xmax, xmax=currentx.  If currenty > ymax,
>> ymax=currenty.  If currentx < xmin, xmin = currentx.  If
>> currenty < ymin, ymin = currenty.
> 
>> For curves, go one point at a time.  The control points bound
>> the curve, so you can use the control points as if they were
>> curve points.
> 
>> When you're done with all the points, add half the thickness to
>> xmax and ymax, and subtract half the thickness from xmin and
>> ymin.
> 
>> I haven't tried it, but it seems to me it should work.
> 
> Hi Carl,
> 
> Thanks for your help.
> 
> I've uploaded a new patch set that (more or less) follows your
> algorithm above, and also changes the interface again (according
> to Han-Wen's and Jan's comments).
> 
> Let me know what you think.
> 
> Thanks,
> Patrick
> 
> 
> http://codereview.appspot.com/1730044/show
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Revised version of waveform renderer on Rietveld that uses glpk

[Mike Solomon]

http://codereview.appspot.com/1720046

Hey developers,
Today I had time to finish version 2 of my waveform patch that uses glpk
to do smooth linear interpolation of waveforms.  As there is a dependency
freeze & glpk is ultimately too big & too everchanging to be part of
lilypond, this won't make it into 2.14, but I'd like to get it into a
development version ASAP.  I've already composed a piece w/ the old version
of the patch & the new version has rendered said piece even prettier.
In making it, I've learned a great deal about linear and cone
programming and I think that there are many elements of lilypond, most
notably its traffic-coppery of intersections, that could be phrased in a
constrained semi-definite optimization program.  This may be a pet project
of mine later down the line, but for now, the current patch would benefit
greatly from your opinions and usage.
The patch, which shows some (but not all) side-by-side diffs is up at:
http://codereview.appspot.com/1720046 .  Note that in it, I have a change to
include/lily-guile.hh that I needed to make for OS X to get the guile
ellipses to work (...) .  This can likely be removed w/o consequence,
although as I know next to nothing about guile, I have no clue what effect
this has - I just know that w/o it, lilypond didn't compile on my machine,
and I couldn't figure out a way to format the patch w/o picking this up.
Anyway, please let me know what you think!!!  For ideas, check out
http://www.apollinemike.com/lilypond/waveform

~Mike



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Revised version of waveform renderer on Rietveld that uses glpk

[Mike Solomon]

Responses inlined:

On 7/2/10 4:54 PM, "David Kastrup"  wrote:

> Mike Solomon  writes:
> 
>> http://codereview.appspot.com/1720046
>> 
>> Hey developers,
>> Today I had time to finish version 2 of my waveform patch that uses glpk
>> to do smooth linear interpolation of waveforms.  As there is a dependency
>> freeze & glpk is ultimately too big & too everchanging to be part of
>> lilypond, this won't make it into 2.14, but I'd like to get it into a
>> development version ASAP.  I've already composed a piece w/ the old version
>> of the patch & the new version has rendered said piece even prettier.
> 
> What musical function serves this patch/notation?

In contemporary music, I've worked with several composers that use
representations of waveforms in their scores so that players can follow
along.  Only really doable in Finale or Sibelius, the creation of said
representations is a tedious process that requires exporting an image of a
waveform and stretching it to fit with the music.  If the systems change, a
new batch of images need to be made and stretched.  As far as musicology
goes, I know of at least one project going on in France that allow for the
mixing of scores and audio representations:

The dynamic score (http://www.grame.fr/Recherche/Programmes/)

There are a few other prjects that I remember seeing at Journées
Informatique Musicale in Rennes this year that were also along this line.
It is definitely in the air (at least in certain communities).

I believe that this type of need is widespread.  And, as the algorithm in
waveforms is written to work for anything that is created from a lot of
small samples, it can be used with RGB images and SVG/PS filters as well to
create graphical notation.  I will be creating examples of this in the not
too distant future.

> There is no documentation as far as I can see, and I have the strong
> suspicion that this is exclusively an ornamentation.

I'm sorry for the lack of documentation: the patch is hot off the press.  If
I had to sum it up in a phrase, this patch allows for the smooth stretching
and relaxing of sampled images in the context of a vector-graphics based
program.
Trills are exclusively ornamentation, and I <3 trills :-)

> It seems nice to be able to add this sort of thing to Lilypond, but I
> think it rather strongly demonstrates Lilypond's lack of modularity:
> this sort of thing should sit in a separate directory and be loaded
> on-demand under user control without needing any resident code parts
> when people don't use it.

I completely agree that modularity rocks, but to be fair, I think that
lilypond is excellently modular through Scheme.  In fact, if scheme had a
linear programming library, I could have created 100% of this in scheme
using various overrides and hijackings of other spanners, although it would
have run considerably slower for certain problematic waveforms that need
many rounds of smoothing.

> It makes no sense to maintain such a subfeature in a separate _branch_,
> this should be a sub_project_ (in git terminology).  Including or not
> including such a feature in Lilypond should not be a question of merging
> some branch (with all the conflict possibilities), but rather of
> including some directory in the hierarchy.  The difference at run time,
> again, should be the presence or absence of files, preferably in a
> separate directory of the Lilypond hierarchy.

This is an interesting route to explore - it raises the question: what is
modular to lilypond and what is central?  I believe there are many elements
of the code (ie the Vaticana stuff) that could be treated this way, but they
don't bother me in lily/ simply because I think that their presence makes
lilypond more robust w/o slowing it down appreciably.

and from Graham's e-mail...

> I haven't looked at the patch, but I'm guessing that the
> non-modularized parts is the interaction with glpk.  Is there any
> way that scheme could call a natively-install glpk library (i.e.
> not the -devel version) ?  That might make this feature
> modularizable, and incidently might even allow it to get into
> 2.14.

Your evaluation is right on the money.  I can absolutely make this happen
with a call to glpsol from scheme (or something of this ilk).  But the
danger there is that I have no clue how that works on non Linux / OS X
machines.  And, there are a couple other technical advantages to using C++:
most notably the multimap that exists in the waveform class which allows a
waveform part to see the calculations of its whole.  Furthermore, given the
way lilypond is designed, I think that it makes sense to write engravers in
C++.  Perhaps I could change the name, however, to "sampled-object-engraver"
or something of the ilk to allude to its broader applicability.

T

Re: Revised version of waveform renderer on Rietveld that uses glpk

[Mike Solomon]

I completely agree that modularity is a great way to go - I think that
woodwinds could be re-integrated into lilypond this way, as could fretboard
diagrams and other similar features.

For me, the three very beneficial aspects of C++ are its ability to work
with data structures that retain information, the robust libraries that
exist, and its speed.  Waveforms uses all three, which is why I chose to do
it in C++.  But I think that, if the way lilypond interacts with Scheme were
worked on a bit (ie scheme being able to query c++ classes that stored
status variables), almost all of the engravers could be turned into modules.
But like Carl said, something of that size would take a bit of time - I for
one would be willing to work on it.  And in this case, like Han-Wen said,
C++ could be reserved for situations where its lack would be a huge time
drain (ie when libraries are important).

~Mike

On 7/2/10 8:31 PM, "Carl Sorensen"  wrote:

> On 7/2/10 12:03 PM, "Graham Percival"  wrote:
> 
>> On Fri, Jul 02, 2010 at 06:12:03PM +0200, David Kastrup wrote:
>>> Graham Percival  writes:
>>> 
>>>>> It seems nice to be able to add this sort of thing to Lilypond, but I
>>>>> think it rather strongly demonstrates Lilypond's lack of modularity:
>>>>> this sort of thing should sit in a separate directory and be loaded
>>>>> on-demand under user control without needing any resident code parts
>>>>> when people don't use it.
>>>> 
>>>> If it was all done in scheme, this would be easy.  :)
>>> 
>>> I don't think so, since properties and contexts are defined and
>>> initialized globally right now, and we don't have a system for
>>> modularizing documentation.
>> 
>> Can't new contexts be defined by the user?  I'll admit that I
>> don't think they can create new properties...
>> 
>> I was basically just thinking of things like ancient notation, or
>> the beautiful "packages" / "files" / "modules" / "whatever we
>> shoudl call them" that Reinhold and Nicholas put together, like
>> stuff for title pages or orchestralily.  As a naive ex-user, I'd
>> call those "modules", but that might be misusing a technical term.
> 
> 
> Although I'm not going to work on this right now (got to get the autobeaming
> stuff done first!), it seems like we ought to be able to define something
> that works kind of like \usepackage.
> 
> Properties are defined in Scheme, and hence, could be added to from scheme,
> at least as far as I can see without  trying it myself.
> 
> New contexts can certainly be defined in .ly files.
> 
> Interfaces are defined in scheme, and thus should be modifiable.
> 
> Music types are defined in scheme.
> 
> We now have the capability of defining engravers in Scheme.
> 
> We may be missing iterators and performers, I guess.
> 
> Documentation is *not* currently modular (as David has expressed before).
> It would be cool to have some kind of a master documentation runner that
> could be called on a module, and would know how to get the appropriate
> .itely file and turn it into a little documentation file for the feature.
> 
> I really like David's thoughts about how it would be cool to have LilyPond
> be modular like TeX/LaTeX.  But that's certainly postponed to after 2.14 as
> far as I'm concerned.
> 
> Thanks,
> 
> Carl
> 
> 
> Thanks,
> 
> Carl
> 
> 
> 
>> 
>> Cheers,
>> - Graham
>> 
>> ___
>> lilypond-devel mailing list
>> lilypond-devel@gnu.org
>> http://lists.gnu.org/mailman/listinfo/lilypond-devel
> 
> 
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/lilypond-devel
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Font metric unused variable

[Mike Solomon]

Hey all,
In compiling lilypond this morning, I saw this:

font-metric.cc:82: warning: unused parameter 'k'

Checking out the function in question, I saw this:

Box
Font_metric::get_indexed_char_dimensions (size_t k) const
{
  return Box (Interval (0, 0), Interval (0, 0));
}

Not knowing what this function is supposed to do, I am not sure if this is a
problem, but if k is not necessary, perhaps:

Box
Font_metric::get_indexed_char_dimensions (size_t) const
{
  return Box (Interval (0, 0), Interval (0, 0));
}

would be better?

~Mike



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

How the vertical layout engine correctly manages spanners' heights

[Mike Solomon]

Hey all,
I'm almost finished w/ a vector-graphic-spanner project I've been
working on in Lilypond (that I'm planning on using during the International
Composers Pyramid in Kent tomorrow...crosses fingers...), and to make it
work 100%, I have to make it so that the Y-extent of the spanner is
correctly taken into account every time the spanner breaks lines.  The
problem is that sometimes this extent is factored into the layout, and
sometimes it is disregarded.  You can see this on:

http://www.apollinemike.com/lilypond/vector1.pdf
http://www.apollinemike.com/lilypond/vector5.pdf

As the amount of code I've produced to make this happen is too big to
meaningfully summarize in an email, I'd rather solicit your help by asking:
how are spanners' (or just grobs' in general) y-extents found and taken into
account in the layout process?  Is there one place where lilypond's
vertically-oriented engraver(s) consult(s) grobs/spanners to find their
heights, and if so, where?  For example, how does lilypond know to take a
hairpin's height into account for every staff over which said hairpin is
split?  I see some candidates in the source code, but not knowing how any of
them really work, I'm not sure if any of the following are promising leads:

1) pure-height: if I created a callback with the correct extent, would that
do anything?
2) axis-group-interface: I am currently not using this interface.  Should I
be?  Does that help the correct heights to be factored into the layout?
3) are there multiple grob parameters that, when set in conjunction, sorta
cancel each other out and make lilypond disregard the Y-extent?
4) the unknown...

Currently, a slew of pacifier prints using `format' confirm that I'm using
the correct extents for the stencil and that the 'Y-extent property is
always correct when the print statement is called.  Furthermore, when I
print the grob properties (via ly:grob-properties) to the command line, the
correctly and incorrectly laid-out grobs all have the same properties.  So,
it's hard for me to track down the source of this inconsistent behavior.
Any thoughts would be appreciated!

~Mike

P.S. If any of you are particularly brave, I will send you a patch with my
source...but it's long...



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: How the vertical layout engine correctly manages spanners' heights

[Mike Solomon]

Thank you very much Joe.

An improved version is at:

http://www.apollinemike.com/lilypond/vector5.pdf

There are still some kinks: the second staff looks like it¹s moved in the
wrong direction (up instead of down) in the vertical spacing, and it seems
like the second spanner on each line is not offset correctly.  Any ideas
from any of all ya¹ll would be greatly appreciated.  However, Joe¹s
suggestion to check out Y-offset callbacks has already helped a great deal,
and stuff like the pdf online will certainly be passable for the demos I
need to do this weekend.

Cheers,
Mike


On 7/22/10 8:35 PM, "Joe Neeman"  wrote:

> Hi Mike,
> 
> On Thu, Jul 22, 2010 at 7:24 AM, Mike Solomon  wrote:
>> Hey all,
>>     I'm almost finished w/ a vector-graphic-spanner project I've been
>> working on in Lilypond (that I'm planning on using during the International
>> Composers Pyramid in Kent tomorrow...crosses fingers...), and to make it
>> work 100%, I have to make it so that the Y-extent of the spanner is
>> correctly taken into account every time the spanner breaks lines.  The
>> problem is that sometimes this extent is factored into the layout, and
>> sometimes it is disregarded.  You can see this on:
>> 
>> http://www.apollinemike.com/lilypond/vector1.pdf
>> http://www.apollinemike.com/lilypond/vector5.pdf
>> 
>> As the amount of code I've produced to make this happen is too big to
>> meaningfully summarize in an email, I'd rather solicit your help by asking:
>> how are spanners' (or just grobs' in general) y-extents found and taken into
>> account in the layout process?  Is there one place where lilypond's
>> vertically-oriented engraver(s) consult(s) grobs/spanners to find their
>> heights, and if so, where?
> That depends on the Y-parent of your grob. If it is a VerticalAlignment, then
> you should look at Align_interface to see how children of VerticalAlignment
> are laid out. Otherwise, the Y-offset property of your grob is very important,
> since it gives the offset between your grob and its Y-parent. How the Y-extent
> affects the layout depends on what Y-offset is. That is, there are some
> callbacks for Y-offset that depend on the extent and there are others that
> don't.
>  
>> For example, how does lilypond know to take a
>> hairpin's height into account for every staff over which said hairpin is
>> split?
> We split the hairpin into multiple hairpins, one for each staff. See
> Spanner::do_break_processing.
>  
>>   I see some candidates in the source code, but not knowing how any of
>> them really work, I'm not sure if any of the following are promising leads:
>> 
>> 1) pure-height: if I created a callback with the correct extent, would that
>> do anything?
> Pure height is used to doing page breaking, but not for the actual layout.
>  
>> 2) axis-group-interface: I am currently not using this interface.  Should I
>> be?  Does that help the correct heights to be factored into the layout?
> Probably not, Y-offset is more important.
>  
>> 3) are there multiple grob parameters that, when set in conjunction, sorta
>> cancel each other out and make lilypond disregard the Y-extent?
>> 4) the unknown...
>> 
>> Currently, a slew of pacifier prints using `format' confirm that I'm using
>> the correct extents for the stencil and that the 'Y-extent property is
>> always correct when the print statement is called.  Furthermore, when I
>> print the grob properties (via ly:grob-properties) to the command line, the
>> correctly and incorrectly laid-out grobs all have the same properties.  So,
>> it's hard for me to track down the source of this inconsistent behavior.
>> Any thoughts would be appreciated!
> The current extent and offsets aren't actually stored in ly:grob-properties.
> For performance reasons, they are in grob->dim_cache_ (only accessible from
> C++).
> 
> Cheers,
> Joe
> 
> 


___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Modularity in lilypond

[Mike Solomon]

Hey all,
I've almost finished moving my vector-graphic package into a module that
is usable by invoking one \include statement (it is in scheme code and .so
files importable by guile).  I decided to do this because the generation of
vector graphics readable by my code uses too much kludgery to really deserve
to be part of lilypond (currently, I can only really work with
Inkscape-generated eps files).  Plus, it makes dependencies a non-issue.
In doing this, I've realized that almost everything in Lilypond can be
made modular, which is a testament to how well it is put together.  David
had suggested modularity as an option before (perhaps others as well), and
there was a brief flurry of support for this idea: I'd now like to re-echo
it and work seriously on it to make it part of 2.14.  To me, it seems like
the following things would need to be done:

1)  A folder would be created in (ie PATH/lilypond/2.X.X/module) in which
all modules hung out so that Lilypond knew to look there.  Each module would
have its own folder and could be internally organized however one fancies.
2)  A document would be created that invoked all modules that were
perma-invoked.  That is, any module should be able to be called in a given
document, but if the user wants certain modules to be called all the time,
this document should do it.  Ideally, the document would be nothing more
than a series of \include statements.  It would have to have a standard path
that would not get overwritten from version to version (which would likely
involve some copying and pasting combined with some simlinkery).
3)  Certain current features of lilypond would need to be modularized.  This
is probably the most difficult call, as it brings up the question "what
should be part of non-modular lilypond"?  There are certain things, such as
notes, dynamics, and slurs that seem like they should be in any typesetter,
whereas woodwind fingering charts, fretboard diagrams, and harp pedals seem
more modularish.  Of course, the latter things could be shipped with
lilypond and even included as a sort of "automatic module" to make for
backwards compatibility (ie the user would have to decide to delete them
from the document in #2 instead of include them), but I think it'd be
important to modularize as much as possible.

This is likely very easy to set up and test, but as it seems like a
not-insignificant move, I'd want to see first if there is community support
and if there is a group of people willing to iron out how this change could
be orchestrated.

Cheers,
Mike

P.S. In an unrelated note, many thanks to Patrick for his work on the path
command, which will any day now replace the connected-shape stencil - I just
tested a new patch of his and it works perfectly.
P.P.S. It could be that such a modular system already exists and I am simply
not privy to it, in which case I'd appreciate any feedback!



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modularity in lilypond

[Mike Solomon]

Understood.
Does this modularity thing seem eventually includable in lilypond?  I'm
finishing a piece for October 1 and would like to be consistent about the
way that I do the coding for my graphical notation: either it'll be done in
my git repository or as a module.  Obviously I'd like not to have to change
from one form to another afterwards, so if you think modularity seems like
it could become part of lilypond, I'll tackle my project from that angle.

Thanks!
~Mike


On 7/28/10 7:39 PM, "Graham Percival"  wrote:

> On Wed, Jul 28, 2010 at 04:25:08PM +0200, Mike Solomon wrote:
>> In doing this, I've realized that almost everything in Lilypond can be
>> made modular, which is a testament to how well it is put together.  David
>> had suggested modularity as an option before (perhaps others as well), and
>> there was a brief flurry of support for this idea: I'd now like to re-echo
>> it and work seriously on it to make it part of 2.14.
> 
> I don't think we should rearrange things for 2.14.  The plan for
> 2.15 is to start about 1 month after 2.14, and to start
> stabilizing and releasing 2.16 about 2 months after that.  Expect
> to merge this work in 2.15.
> 
> Cheers,
> - Graham
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: Modularity in lilypond

[Mike Solomon]

True that.

My three.5 concerns are:
1) said code cannot use non-public scheme functions (am I right in thinking
that?).
2) changes to init.ly are not copied from one version of lilypond to the
next, nor are one person's "modules".  I do my compiling from the git
repository, so I could likely rig something like that for my own machine,
but I imagine this is even more problematic for someone downloading a
GUB-made lilypond.  I had this problem with my site-packages when I updated
from Python 2.4 to 2.6, and it took me days to get back things as I had
them.
3) There should be some sorta standard practice (ie template) for how
modules are written (I believe that's what David was referring to).
3.5) I stand by my assertion that certain features of lilypond should be
turned into modules if lilypond is to grow to be as encompassing as
something like j-edit or emacs.  Given the many amount of musics in this
world, if lilypond wants to grow to be as wide-reaching as possible, such a
move seems logical for subsequent versions.

Any ideas would be appreciated!
~Mike

On 7/29/10 7:47 PM, "Graham Percival"  wrote:

> On Wed, Jul 28, 2010 at 04:25:08PM +0200, Mike Solomon wrote:
>> 1)  A folder would be created in (ie PATH/lilypond/2.X.X/module) in which
>> all modules hung out so that Lilypond knew to look there.  Each module would
>> have its own folder and could be internally organized however one fancies.
> 
> Kind-of like the /ly/ dir?
> 
>> 2)  A document would be created that invoked all modules that were
>> perma-invoked.  That is, any module should be able to be called in a given
>> document, but if the user wants certain modules to be called all the time,
>> this document should do it.  Ideally, the document would be nothing more
>> than a series of \include statements.  It would have to have a standard path
>> that would not get overwritten from version to version (which would likely
>> involve some copying and pasting combined with some simlinkery).
> 
> Like /ly/init.ly ?
> 
>> 3)  Certain current features of lilypond would need to be modularized.  This
>> is probably the most difficult call, as it brings up the question "what
>> should be part of non-modular lilypond"?  There are certain things, such as
>> notes, dynamics, and slurs that seem like they should be in any typesetter,
>> whereas woodwind fingering charts, fretboard diagrams, and harp pedals seem
>> more modularish.
> 
> Like \include "gregorian.ly" ?
> 
>> P.P.S. It could be that such a modular system already exists and I am simply
>> not privy to it, in which case I'd appreciate any feedback!
> 
> I'm not certain if you're aware of the ly/ dir, but if not, you
> should definitely look at those.
> 
> Cheers,
> - Graham
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] ly-engraver-make-spanner (to compliment ly-engraver-make-grob)

[Mike Solomon]

Name says it all.

http://codereview.appspot.com/1869047

Disregard the changes to lily-guile.hh - all of my patches uploaded with
git-cl spit that out because of Mac OS X 10.4 powerpc modifications I had to
make to get lilypond compile-able.

To apply the patch set directly (w/o the lily-guile.hh modifications), you
can use the attached.

~Mike



0002-Add-engraver-make-spanner.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] ly-engraver-make-spanner (to compliment ly-engraver-make-grob)

[Mike Solomon]

I think that this patch is the easiest way to assure that the break
processing will happen when do_break_processing is called (although I could
be wrong), whereas creating a grob doesn't get you a spanner's break
processing.

On 7/29/10 9:14 PM, "Neil Puttock"  wrote:

> On 29 July 2010 19:22, Mike Solomon  wrote:
>> Name says it all.
> 
> Why do you need this?
> 
> Since a Spanner's parent class is Grob, ly:engraver-make-grob should
> have no problem creating spanners.
> 
> Cheers,
> Neil
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] ly-engraver-make-spanner (to compliment ly-engraver-make-grob)

[Mike Solomon]

Interesting...thank you.
I completely missed that.  Sorry for the clutter :-(


On 7/29/10 9:36 PM, "Neil Puttock"  wrote:

> On 29 July 2010 20:34, Mike Solomon  wrote:
>> I think that this patch is the easiest way to assure that the break
>> processing will happen when do_break_processing is called (although I could
>> be wrong), whereas creating a grob doesn't get you a spanner's break
>> processing.
> 
> Have you looked at the macros which creates each type of grob?  All
> they do is call the same internal function (internal_make_grob), then
> check validity using dynamic_cast.  Each type of grob gets the correct
> properties/interfaces/class initialized from the description in
> all-grob-descriptions, so I can't see why there would be any problems
> later on with break processing.
> 
> Cheers,
> Neil
> 



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] fix to issue 1173

[Mike Solomon]

This raises an error message if showLastLength is not used to show full
measures.

As I am the worst git-cl user ever, if someone could throw this up on
Reitveld, I'd appreciate it.

~Mike



0002-Fix-for-issue-1173-to-fails-when-asked-to-showLastLe.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] fix to issue 1116

[Mike Solomon]

cold week in Paris = lilypond week
my best stab at fixing 1116

This solution works for the minimal example given with the issue, and it
works in general if one accepts the assumption that there is no reason that
anything fed through stack-lines (in scm/stencil.scm) should have an X
extent whose left boundary is anything other than 0.  However, I
don'tunderstand lilypond well enough to know:

a) if this is a good assumption
b) if this assumption breaks something else.

As usual, the first person who throws this on Reitveld gets many thanks.

~Mike



0002-Fixes-issue-1116-by-regulating-X-extent-at-exit-of-s.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

Re: [PATCH] fix to issue 1173

[Mike Solomon]

On 7/30/10 10:06 PM, "Neil Puttock"  wrote:

> On 30 July 2010 14:19, Mike Solomon  wrote:
>> This raises an error message if showLastLength is not used to show full
>> measures.
> 
> Ouch. :)
> 
> We should always try to continue compilation (leaving aside syntax
> errors, of course) so I think it would be better to `round' the value
> if necessary to ensure it doesn't break full bars.
> 
> From the user's point of view, it's unlikely to matter if
> showLastLength doesn't result in exactly the specified number of bars.
> 
> BTW, you'd also need to fix showFirstLength.
> 
> Cheers,
> Neil
> 

Done :)
Please let me know what you think.
~Mike



0002-Fix-for-issue-1173-to-fails-when-asked-to-showLastLe.patch
Description: Binary data


0003-Fixes-1173-no-error-message-rounds-up-to-the-next-me.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Add scheme binding for Side_position_interface::set_axis

[Mike Solomon]

In this email & the next, I'm attaching two patches that I think I'll need
to make a fully-functional spanner engraver in Scheme.  If any of you know
of better ways to do these things than creating Scheme bindings, please let
me know!

http://codereview.appspot.com/1880050

Cheers,
Mike



0002-Provides-scheme-bindings-for-Side_position_interface.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Scheme binding for announce_end_grob

[Mike Solomon]

http://codereview.appspot.com/1914043

~Mike



0002-Adds-announce-end-grob-to-engraver-scheme.cc.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

patch-reviewing and the i-ching (was Re: sustainable development in LilyPond)

[Mike Solomon]

On 8/4/10 1:25 PM, "Trevor Daniels"  wrote:

> 
> David Kastrup wrote Wednesday, August 04, 2010 11:27 AM
> 
> 
>> "Trevor Daniels"  writes:
>> 
>>> 1) There is no architectural overview and no program logic manual
>>> to
>>> guide new developers through the early stages.
>>> This has the advantage that only experienced and expert
>>> coders able to deduce the design from the source code are
>>> able to contribute significantly, ensuring high quality.
>> 
>> I consider that reverse logic.  The problem is that you are likely
>> to
>> have people reinventing the wheel, leading to a loosely connected
>> garden
>> of code written by x, code written by y where everybody has
>> his own
>> ways and subroutines for solving particular subtasks.
> 
> Yes; I worded it badly.  I meant, "The only advantage this has
> is that ...".  You correctly point out the outweighing
> disadvantages.
> 
> It was clear, I hope, that I am advocating better documentation,
> not less.
> 
> Trevor

I am a bit lost with respect to what has to be done and who's working on
what, but I've been chipping away as best I can on issues that, to me, seem
under-commented-upon.

I think that Graham's sustainable development presentation is excellent,
especially the part about swag, as I am moving from a wine-drinking country
to a beer-drinking country in two weeks and could use a lilypond bottle
opener.  In parallel to what he says, I feel that another way to get things
done on a more short-term basis (i.e. before 2.14 and before Graham puts a
sustainable plan into place) is to randomly assign issues to willing
participants via a lottery.  Said participant would then be responsible for
stewarding the issue until resolution, which could involve anything from
coordinating efforts on an untouched problem to simply running a test on a
patch that is quite evolved and signaling to one of the developers that it
is ready to be pushed.  It would also be a great way for new folks (like me)
to learn - I chose to work on issue 1173 at pseudo-random (Python's random
library) and learned a great deal in doing so.

If there is sufficient interest in this idea, I think it would be a good way
for newcomers and experienced lilyponders alike to move forward with
outstanding issues.

~Mike



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

good news! created a successful spanning engraver entirely on the scheme end.

[Mike Solomon]

Hey lilyponders,
I was able to create a spanner that has more or less the same
functionality as TextSpanner entirely out of scheme in a ".ly" file.  I used
the newly-christened ly:announce-end-grob as well as ly:grob-chain-callback
and ly:engraver-property, both of which I've uploaded to Reitveld and are
waiting review.  As soon as they get commented upon and (hopefully) applied
to the source, I will send out a regression test.

~Mike



___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel

[PATCH] Adds ly:engraver-property to engraver-scheme.cc

[Mike Solomon]

Sorry for the slew of patches in this vein - as I run into problems while
trying to create a real engraver in scheme, I'm sending these patches along.

http://codereview.appspot.com/1878048

Cheers,
~Mike



0002-Adds-ly-engraver-property-to-engraver-scheme.patch
Description: Binary data
___
lilypond-devel mailing list
lilypond-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-devel