Syntactical question [was: Re: Call for help with bar lines]

[Marc Hohl]

Am 26.09.2012 14:45, schrieb Thomas Morley:

[...]
Hi Marc,

an idea, don't know if it's really helpful:

>From 2.16.0-bar-line.scm, bar-glyph-alist:
The old definition of  bar "empty" was: ("empty" . (() . ()))
The old definition of  bar "" was: ("" . ("" . ""))

With regard to that, I have to make a distinction between
"" and '() in the new bar line interface.

What do you think would be better: using a symbol instead of '(),
so one can write

\defineBarLine "|" "|" 'none "|"

or using #f instead:

\defineBarLine "|" "|" #f "|"

or finally defining an "empty stencil" glyph:

\defineBarLine "|" "|" "x" "|"

(note that "" is not the same as "x", as Harm explained; "" draws a 
stencil with

zero width, "X" would draw *no* stencil at all).

I think I'll go for the second option, but lemme know what you think 
about it!


Regards,

Marc


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

Re: Adds tick mark to scripts (issue 6568055)

[lemzwerg]

LGTM.


http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):

http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf#newcode1774
mf/feta-scripts.mf:1774: set_char_box (0, 1.7 staff_space# + epsilon,
I suggest to use a tightest bounding box.  At least I don't see any
reason to not do so.  The question is whether it makes sense to give
this glyph a depth (this is, to make the glyph go below the baseline),
but this is only a matter of taste.

http://codereview.appspot.com/6568055/

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

Re: [talk] easy tuplets

[Keith OHara]

On Mon, 24 Sep 2012 15:51:43 -0700, Francisco Vila  
wrote:


2012/9/24 Janek Warchoł :

Seriously though, i think this syntax would be very useful for
algorithmic composers and computer programs manipulating Lily code.
Another advantage is code readability and ease of copying it (shall i
elaborate?)

Besides, it's not like we would loose any functionality: \times would
still be there.


This convinces me. I'm for it.


I'll be against it.  I make typos of c3 or c5 when I want to type c4

Let the algorithmic composers write c4*4/5

Let the humans use \tuplet as proposed years ago,

and which is easy to implement (attached) now that David has added the 
infrastructure to write music-functions that take fractions, and optional 
arguments (although I'm not sure if the optional argument is wise in this case).

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

Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)

[Reinhold Kainhofer]

On 2012-09-26 15:32, d...@gnu.org wrote:

Reinhold Kainhofer  writes:


On 26/09/2012 11:26, d...@gnu.org wrote:

\once does something entirely different.  It does not turn an

override

into a tweak but rather marks it at being active only at the current
timestep.  \once applies at a single time, \single applies on a

single

item.



To me as a user, \once\override is used to change the next note (or
items attached to it) and \single\tweak is used to change the next
item.


Both are only roughly equivalent when there is only one item per
timestep.  \once\override affects _everything_ happening at the same
time.


Ah, thanks for the explanation. I didn't understand that \single is 
meant to fix the case where \once applies to multiple items at the same 
timestep!


Cheers,
Reinhold

--
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com

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

Re: [GLISS] facilitate changes of the (default-) drumStyleTable

[Thomas Morley]

2012/9/26 Marc Hohl :

> I like the idea of giving the user the ability to change only parts of the
> list
> without having to rewrite the full list; I think that this concept could be
> of
> use in other parts of lilypond as well,

Hi Marc,

further testing showed a major-problem:

Using `hashq-set!' here is too much force brute and will result in an
unintended change of lily-internals.
I.e. compiling all .ly files in a folder with
lilypond *.ly
will show the changes in _all_ files, even if \changeDrumStyleTable is
_not_ used in a file.

\set DrumStaff.drumStyleTable = #(alist->hash-table )
is not that invasive.


Nevertheless, IMHO the question about an easy, less intricate method
how to change a single value in the predefined drumStyleTable stands
as a valid request.


-Harm

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

Re: Call for help with bar lines

[Marc Hohl]

Am 26.09.2012 12:34, schrieb m...@mikesolomon.org:

On 26 sept. 2012, at 12:07, Marc Hohl  wrote:


Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:

On 26 sept. 2012, at 11:01, Marc Hohl  wrote:


Can anyone with more knowledge than me give me a hint what's wrong?
IIUC correctly, lilypond draws a bar line at the beginning of each line,
but in most cases, this is an invisible one.
If you look at the results of input/regression/lyrics-spanbar.ly,
the whole stuff is shifted that much to the right that lilypond moves
the rightmost rest to a new line! I can't believe that a bar line with
zero width can be the cause for this...

Any hints are highly appreciated!

Regards,

Marc


Hey Marc,

I unfortunately don't have much time to help you out, but I can tell you that 
you are on the right track doing prints to the command line.  I would not, 
however, stash them in lambda functions used as overrides, as this can 
sometimes interfere with pure properties.

Thanks for the hint, but I assume that this is not the case here, where I wrap 
ly:bar-line::print into
a callback ...

ly:bar-line::print is a registered pure-print-callback (line 2712 of 
define-grobs.scm), so when you use a custom callback, LilyPond stops finding 
pure heights of bar lines.  To make sure that pure extents kick in, you'd need 
to do something like

\override BarLine #'print = #my-print-callback
\override BarLine #'Y-extent = #(ly:unpure-pure-container 
ly:grob::stencil-height (lambda (grob s e) (ly:grob::stencil-height grob)))

You can check on the CG subchapter on pure properties for more examples.

I'll have to do that.

On the other hand, it is the x extent that's wrong, and IIUC, this is 
not influenced by any pure/impure decision?


But that's just for the record, because I am pretty sure that Harm found 
the culprit.


Thanks for your help!

Marc




There are a couple classic things I use, most of which are in grob.cc.

In Grob::pure_relative_y_coordinate, before the last return statement, you can 
put:

if (name () == "BarLine") print ("RELATIVE COORDINATE for BARLINE at spanned rank 
%d: %4.4f\n", spanned_rank_interval ()[LEFT], out);

This can be quite handy, thanks!

But back to my original question: can someone please have a quick glimpse at 
the regtests?
Perhaps he can spot the cuprit very easily ...

I looked at them and my guess is that the pure extents (and maybe even unpure 
extents) are being changed, which is why I suggested doing prints to the 
command line for extents (both X and Y).

Cheers,
MS



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

Re: Call for help with bar lines

[Marc Hohl]

Am 26.09.2012 22:43, schrieb David Kastrup:

Marc Hohl  writes:


Am 26.09.2012 12:23, schrieb David Kastrup:

Marc Hohl  writes:


Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:


I unfortunately don't have much time to help you out, but I can tell
you that you are on the right track doing prints to the command
line.  I would not, however, stash them in lambda functions used as
overrides, as this can sometimes interfere with pure properties.

Thanks for the hint, but I assume that this is not the case here,
where I wrap ly:bar-line::print into
a callback ...

_I_ wouldn't dare competing against Mike in a purity test.  Unless you
know your way inside/out of pure/impure containers and stuff, it might
really be worth a try to check out his debugging suggestion.

Ok, ok. To be honest, the pure/impure stuff is not something I understand
in full ...

In a different vein, I have the impression that we might need to revisit
the programming model if we want to have a chance of more than 2 people
ever being able to work successfully on/with the backend.

I am not sure whether I understand your proposal correctly, but I am
working on this for quite a long time, so I don't have strong feelings
about rewriting the whole interface again

Not the backend of your patch.  The backend of LilyPond itself.  The
thing juggling and arranging grobs on paper and working with their
relations.

Sorry then, I completely misunderstood you – I just read halfway through the
"grob-parents" thread and found out that you obviously meant another backend
than me ;-)

Regards,

Marc





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

Re: Call for help with bar lines

[David Kastrup]

Marc Hohl  writes:

> Am 26.09.2012 12:23, schrieb David Kastrup:
>> Marc Hohl  writes:
>>
>>> Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:
>>>
 I unfortunately don't have much time to help you out, but I can tell
 you that you are on the right track doing prints to the command
 line.  I would not, however, stash them in lambda functions used as
 overrides, as this can sometimes interfere with pure properties.
>>> Thanks for the hint, but I assume that this is not the case here,
>>> where I wrap ly:bar-line::print into
>>> a callback ...
>> _I_ wouldn't dare competing against Mike in a purity test.  Unless you
>> know your way inside/out of pure/impure containers and stuff, it might
>> really be worth a try to check out his debugging suggestion.
> Ok, ok. To be honest, the pure/impure stuff is not something I understand
> in full ...
>>
>> In a different vein, I have the impression that we might need to revisit
>> the programming model if we want to have a chance of more than 2 people
>> ever being able to work successfully on/with the backend.
> I am not sure whether I understand your proposal correctly, but I am
> working on this for quite a long time, so I don't have strong feelings
> about rewriting the whole interface again

Not the backend of your patch.  The backend of LilyPond itself.  The
thing juggling and arranging grobs on paper and working with their
relations.

-- 
David Kastrup


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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 26 sept. 2012, at 21:51, Han-Wen Nienhuys  wrote:

> On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org
>  wrote:
> 
>> Another way to think of this is that, in general, we'd try to eliminate
>> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
>> traffic-coppery.  Or, inversely, we'd say that positioning only happens via
>> traffic-cop grobs and no grob has the right to position itself.  But it
>> seems like we need to pick one.
> 
> The reason for trafic-coppery is that for many positioning schemes,
> there is no inherent order that can determine how two objects of the
> same type (and hence, with the same set of callbacks) should be
> typeset.
> 
> A typical example of this is NoteCollision of N NoteColumns. The
> NoteColumns have to all move in a coordinated way, and the easiest way
> is to have a function (with local variables) that determines what has
> to happen. You might get around it, by having a bunch of properties
> instead, but you'd still have to store those somewhere, ie in the
> NoteCollision grob.

Not necessarily, it'd just make computation time longer.  If each note column 
had other concurrent note columns in its side-position-elements grob-array and 
we kept the same function from note-column.cc but rewrote it such that instead 
of translating axes by values it returned the offset value for a given note 
column, the function would be called N times for N note columns.  It's a 
tradeoff between efficiency and consistency - I'm not sure which one is better, 
but I'm sure it's possible to eliminate the NoteCollision grob at the cost of 
redundancy.

> 
>> Agreed, but this is just one instance of translate_axis, which is just one
>> example of a side-effect in lilypond. Is your eventual goal to remove them
>> all?
>> 
>> 
>> Yes - that'd be great.  That'll make explicit dependencies a lot easier to
>> handle - everything can be calculated in terms of callbacks.
> 
> I'm all for removing side effects, but you can pursue that separately
> without trying to rewrite the backend.

My goal is not to rewrite the backend.  My goal is to come up with a 
generalized way to do multiple passes at many places in the compilation 
process, and the best way seems to be deleting certain cached properties.  I'm 
all for other ideas, though.

> 
> 
>> To keep the main thing the main thing, the goal is to be able to wipe
>> certain caches, restore the original callbacks, and know that all grobs
>> properties that depended on the restored property will also be recalculated.
>> My idea is an idea for simplifying LilyPond so that this work is easier, but
>> there is no point in doing that if it won't help reach that goal.  I'm open
>> to any and all suggestions.
> 
> Have you thought this through?
> 
> In order to do cache invalidation, you will have to construct the
> reverse graph. If A.x depends on B.y, now A points to B. For proper
> cache invalidation, if B.y changes, then A.x becomes invalid. This
> means that A has to store a back-reference to B. Hence all pointers
> have to be stored both ways (including inverting 1-N relations into
> N-1 relations), and the both-way links have to be rewritten correctly
> during line breaking.

I'm sure this is doable - it'd just be a royal pain.  It'd meant that 
get_property would have to take the "me" grob as an argument and somehow make 
the grobs aware of each other.

Cheers,
MS


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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

Han-Wen Nienhuys  writes:

> In order to do cache invalidation, you will have to construct the
> reverse graph. If A.x depends on B.y, now A points to B. For proper
> cache invalidation, if B.y changes, then A.x becomes invalid. This
> means that A has to store a back-reference to B. Hence all pointers
> have to be stored both ways (including inverting 1-N relations into
> N-1 relations), and the both-way links have to be rewritten correctly
> during line breaking.

You can assign a generational count to properties.  If the generational
count of any dependency is higher than that of the dependent property,
it needs to get regenerated.  As long as the dependencies don't get lost
(and we use arbitrary size integers, resetting for each session), this
should be pretty straightforward and not require backwards links.  It
"just" requires double-checking your dependencies for change.

-- 
David Kastrup


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

Re: Project - Eliminating grob parents and outside-staff-priority

[Joe Neeman]

On Wed, Sep 26, 2012 at 12:17 PM, m...@mikesolomon.org  wrote:

> On 26 sept. 2012, at 17:38, Joe Neeman  wrote:
>
> On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org <
> m...@mikesolomon.org> wrote:
>
>
> To start this process, I'd like to expand the role of the
>> side-position-interface significantly.  All grobs would use this interface
>> for their X and Y offsets and they would have two different grob arrays for
>> X and Y side-position-elements.  This would allow me to eliminate two
>> things:
>>
>> 1) parents.  Grobs are X/Y aligned to parents, but these parents could be
>> elements in the side-position-elements array.  Functions like get_parent,
>> which could be kept around for legacy reasons, could return the first
>> element of these arrays for a given axis and raise a warning if there are
>> multiple elements.
>>
>
> If you get rid of unique parents, what would X-offset mean? Would it be
> relative to the System? The first element of side-position-elements array?
>
>
> Relative to the skyline of the elements of the side-position-elements
> array.
>

If you want to construct one skyline for all the elements in that array,
you need some way of finding their offsets relative to each other. How do
you propose to do that without some notion of a common refpoint?

2) outside-staff-priority.  Saying a grob has outside staff priority is the
>> same thing as saying that a grob has as its Y side support elements all
>> inside-staff grobs plus all grobs with lower outside staff priority.  A
>> callback creating the side-position-elements arrays could do the sorting
>> that takes place in Axis_group_interface::skyline_spacing.
>>
>
> I think you'll have trouble making this fully callbacky/functional. For
> example, we lay out the outside-staff grobs in a very particular order (the
> left-to-right layout thing), which we don't know ahead of time. That is,
> until we get _all_ of the outside-staff grobs together, we don't know which
> grobs have to depend on which other grobs. That means it isn't really
> possible for each grob to determine its own position; there needs to be one
> grob that lays them out simultaneously. The same issue will come up, I
> think in laying out Accidentals and VerticalAxisGroups.
>
>
> You're right that, in general, any time that a collecting grob does some
> type of organizing, this type of problem will come up.  However, there are
> ways around it.  For example, a grob can get the elements array from its
> vertical alignment or system, sort it from left to right, and trigger
> callbacks for all grobs to the left.  This avoids an overarching
> positioning grob while still achieving the same effect.
>

For outside-staff positioning, I think you could achieve the same effect.
For something more complicated, like TieColumn or AccidentalPlacement, I
think it would be much more difficult (and more obfuscated) to do it with
callbacks.


>
>> The benefits of this are twofold:
>>
>> 1) All work on a multi-pass algorithm could be done with respect to
>> side-positioning, making it simpler to find bugs and modify code.
>>
>
> Not all positioning is side-positioning.
>
>
> True - my goal is to see if all positioning can be articulated this way.
>  For example, ScriptColumn could have used translate_axis, but whoever
> wrote it made the good decision to use side-position-interface.  I think
> this grob could be eliminated entirely if all scripts in a script column
> had a function that calculated the side-position-elements grob-array using
> the sorting algorithm at the heart of script-column.cc.
>
> Another way to think of this is that, in general, we'd try to eliminate
> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
> traffic-coppery.  Or, inversely, we'd say that positioning only happens via
> traffic-cop grobs and no grob has the right to position itself.  But it
> seems like we need to pick one.
>

I gave this some thought a while ago, and concluded that it isn't possible
to get rid of the traffic cops (however, I'd be happy to be proven wrong).
My eventual decision was to have them everywhere. A grob could suggest its
own position using a callback, and if no other grob wanted to override
that, then the System grob would take the traffic cop role and set the
grob's position to whatever its suggestion was. That way you could write a
lot of the positioning code as callbacks, and the cops would only kick in
where necessary. There were also explicit dependencies so you could figure
out which grob was in charge of positioning for which other grob.

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

Re: Call for help with bar lines

[Marc Hohl]

Am 26.09.2012 12:46, schrieb Phil Holmes:

[...]

I've no idea if this will help, so feel free to ignore it. However, my 
recollection is that running lily with -ddump-signatures gives 
information on extents in the output file?
Thanks for this hint – I didn't know that such an option even exists. 
Great to know ...


Regards,

Marc


--
Phil Holmes




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

Re: Call for help with bar lines

[Marc Hohl]

Am 26.09.2012 12:23, schrieb David Kastrup:

Marc Hohl  writes:


Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:


I unfortunately don't have much time to help you out, but I can tell
you that you are on the right track doing prints to the command
line.  I would not, however, stash them in lambda functions used as
overrides, as this can sometimes interfere with pure properties.

Thanks for the hint, but I assume that this is not the case here,
where I wrap ly:bar-line::print into
a callback ...

_I_ wouldn't dare competing against Mike in a purity test.  Unless you
know your way inside/out of pure/impure containers and stuff, it might
really be worth a try to check out his debugging suggestion.

Ok, ok. To be honest, the pure/impure stuff is not something I understand
in full ...


In a different vein, I have the impression that we might need to revisit
the programming model if we want to have a chance of more than 2 people
ever being able to work successfully on/with the backend.

I am not sure whether I understand your proposal correctly, but I am
working on this for quite a long time, so I don't have strong feelings
about rewriting the whole interface again (to be honest: the first
presentation of the idea had a very lively discussion whether the thick
bar line should be represented by '.' or 'I', but nothing more – one may
this read as "the interface is ok, but not the glyph you use" and that's
how I understand it, because the other possibility is "I don't care", and
I *do* hope that people care about the bar line stuff).

Furthermore, I tried to comment the whole stuff very carefully, so
I don't think that the backend is not understandable at all.





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

Re: Call for help with bar lines

[Marc Hohl]

Am 26.09.2012 14:45, schrieb Thomas Morley:

[...]
Hi Marc,

an idea, don't know if it's really helpful:

>From 2.16.0-bar-line.scm, bar-glyph-alist:
The old definition of  bar "empty" was: ("empty" . (() . ()))
The old definition of  bar "" was: ("" . ("" . ""))

The new patch converts bar "empty" into bar ""

You are great!

I found the same possible error while being at work, teaching students ;-)
The latest patch set has indeed no difference between "empty" and "",
that's why most of the regtests are wrong.

I'll give it a try tomorrow, but I am 99.9% sure that after correcting this,
everything will be ok.

[...]



Rubbish! :)
I'm very happy that I had some ideas, you could run with. You managed
to improve the ideas and their coding in an enormous degree.
Great! :D

Thanks! I'll have to include some credits to you, anyway.

Regards,

Marc





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

Re: Project - Eliminating grob parents and outside-staff-priority

[Han-Wen Nienhuys]

On Wed, Sep 26, 2012 at 9:17 PM, m...@mikesolomon.org
 wrote:

> Another way to think of this is that, in general, we'd try to eliminate
> grobs like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do
> traffic-coppery.  Or, inversely, we'd say that positioning only happens via
> traffic-cop grobs and no grob has the right to position itself.  But it
> seems like we need to pick one.

The reason for trafic-coppery is that for many positioning schemes,
there is no inherent order that can determine how two objects of the
same type (and hence, with the same set of callbacks) should be
typeset.

A typical example of this is NoteCollision of N NoteColumns. The
NoteColumns have to all move in a coordinated way, and the easiest way
is to have a function (with local variables) that determines what has
to happen. You might get around it, by having a bunch of properties
instead, but you'd still have to store those somewhere, ie in the
NoteCollision grob.

> Agreed, but this is just one instance of translate_axis, which is just one
> example of a side-effect in lilypond. Is your eventual goal to remove them
> all?
>
>
> Yes - that'd be great.  That'll make explicit dependencies a lot easier to
> handle - everything can be calculated in terms of callbacks.

I'm all for removing side effects, but you can pursue that separately
without trying to rewrite the backend.


> To keep the main thing the main thing, the goal is to be able to wipe
> certain caches, restore the original callbacks, and know that all grobs
> properties that depended on the restored property will also be recalculated.
> My idea is an idea for simplifying LilyPond so that this work is easier, but
> there is no point in doing that if it won't help reach that goal.  I'm open
> to any and all suggestions.

Have you thought this through?

In order to do cache invalidation, you will have to construct the
reverse graph. If A.x depends on B.y, now A points to B. For proper
cache invalidation, if B.y changes, then A.x becomes invalid. This
means that A has to store a back-reference to B. Hence all pointers
have to be stored both ways (including inverting 1-N relations into
N-1 relations), and the both-way links have to be rewritten correctly
during line breaking.

-- 
Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen

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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 26 sept. 2012, at 17:38, Joe Neeman  wrote:

> On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org  
> wrote:
> Hey all,
> 
> As was the case in a few of my previous projects, before I start something 
> new I make architecture changes that facilitate my work.  Working on 2801, 
> I've realized that any multi-pass algorithm for the spacing of grobs is 
> difficult because results of callback calculations are always cached.  So 
> triggering callbacks a second time is, in the current architecture, 
> impractical and requires a fair bit of kludgery.
> 
> Are you proposing not to cache callbacks at all? That sounds like a real 
> performance killer to me; we would probably end up re-typesetting each beam 
> hundreds of times.

No, I'm proposing to find way to mark things as dirty so that they are 
recalculated.

> 
> By the way, the problem is not only in the caching of callbacks; there are 
> also many other places with side effects (calls to set_property, 
> translate_axis, suicide, etc).
> 

Exactly - the proposal here is to get rid of the call to translate_axis in 
axis-group-interface.cc, which is the biggest side effect in the code base in 
terms of the number and variety of grobs affected.  This'll make it easier to 
mark things as dirty so that multiple passes can happen.

> To start this process, I'd like to expand the role of the 
> side-position-interface significantly.  All grobs would use this interface 
> for their X and Y offsets and they would have two different grob arrays for X 
> and Y side-position-elements.  This would allow me to eliminate two things:
> 
> 1) parents.  Grobs are X/Y aligned to parents, but these parents could be 
> elements in the side-position-elements array.  Functions like get_parent, 
> which could be kept around for legacy reasons, could return the first element 
> of these arrays for a given axis and raise a warning if there are multiple 
> elements.
> 
> If you get rid of unique parents, what would X-offset mean? Would it be 
> relative to the System? The first element of side-position-elements array? 
> 

Relative to the skyline of the elements of the side-position-elements array.

> 2) outside-staff-priority.  Saying a grob has outside staff priority is the 
> same thing as saying that a grob has as its Y side support elements all 
> inside-staff grobs plus all grobs with lower outside staff priority.  A 
> callback creating the side-position-elements arrays could do the sorting that 
> takes place in Axis_group_interface::skyline_spacing.
> 
> I think you'll have trouble making this fully callbacky/functional. For 
> example, we lay out the outside-staff grobs in a very particular order (the 
> left-to-right layout thing), which we don't know ahead of time. That is, 
> until we get _all_ of the outside-staff grobs together, we don't know which 
> grobs have to depend on which other grobs. That means it isn't really 
> possible for each grob to determine its own position; there needs to be one 
> grob that lays them out simultaneously. The same issue will come up, I think 
> in laying out Accidentals and VerticalAxisGroups.
> 

You're right that, in general, any time that a collecting grob does some type 
of organizing, this type of problem will come up.  However, there are ways 
around it.  For example, a grob can get the elements array from its vertical 
alignment or system, sort it from left to right, and trigger callbacks for all 
grobs to the left.  This avoids an overarching positioning grob while still 
achieving the same effect.

> At some point, I had grand plans to formalize this problem by having two 
> distinct kinds of properties: one that is user-overridable using callbacks, 
> and one that is internal and gets set by other grobs as a side-effect. 
> Everything would have explicit dependencies so that caches could be 
> invalidated. I even started to write a proof-of-concept in scala, but I never 
> finished it...

My thinking is that in order to make dependencies easier to handle and 
maintain, we need to reduce the number of side effects like translate_axis and 
set_property.

> 
> 
> The benefits of this are twofold:
> 
> 1) All work on a multi-pass algorithm could be done with respect to 
> side-positioning, making it simpler to find bugs and modify code.
> 
> Not all positioning is side-positioning.

True - my goal is to see if all positioning can be articulated this way.  For 
example, ScriptColumn could have used translate_axis, but whoever wrote it made 
the good decision to use side-position-interface.  I think this grob could be 
eliminated entirely if all scripts in a script column had a function that 
calculated the side-position-elements grob-array using the sorting algorithm at 
the heart of script-column.cc.

Another way to think of this is that, in general, we'd try to eliminate grobs 
like NoteColumn, ScriptColumn, DynamicLineSpanner, etc that only do 
traffic-coppery.  Or, inversely, we'd say that positioning only happens via

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[Trevor Daniels]

Benkő Pál wrote Wednesday, September 26, 2012 1:31 PM


> I made some Bartók and Xenakis scans, see
> https://docs.google.com/folder/d/0B7AjGy5hUKtAeWtkdHdfN0l4bm8/edit
> such beams can be seen in 0162.jpeg and 0164.jpeg
> (the former has examples for avoiding such stems too, using flags).

Many thanks, Pál, very helpful!  I now see the point of inserting these
markers in long glissandi, and the need for beams and flags.  I'll try to 
make realistic examples to show this.

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

Re: Adds tick mark to scripts (issue 6568055)

[PhilEHolmes]

Correct.  Apologies - I did that to try an experiment and didn't reset
it.  Thanks for picking it up. Next patch set will correct that.

http://codereview.appspot.com/6568055/

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

Adds tick mark to scripts (issue 6568055)

[PhilEHolmes]

Reviewers: lemzwerg, janek, Graham Percival,

Message:
Please review

Description:
As it says. A tick mark is a very common way of indicating a breath in
vocal music, but we have no good glyph for this.  This is an attempt to
create one.

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

Affected files:
  M mf/feta-scripts.mf


Index: mf/feta-scripts.mf
diff --git a/mf/feta-scripts.mf b/mf/feta-scripts.mf
index  
83859dbe66fc2b4af51bd7bf63947d9700db6913..89ccc25370fa58c9d23e436dc4698630e2874a57  
100644

--- a/mf/feta-scripts.mf
+++ b/mf/feta-scripts.mf
@@ -1736,8 +1736,49 @@ fet_beginchar ("Straight  
caesura", "caesura.straight");

labels(1a, 1b, 2a, 2b, 3a, 3b, 4a, 4b);
 fet_endchar;

+% A tick character to use instead of a comma or caesura as a breath mark,
+% Very common in vocal notation

-fet_beginchar ("snap pizzicato (Bartok pizzicato)", "snappizzicato");
+fet_beginchar ("Tick mark", "tickmark");
+   save end_rad, bot_rad, pat, y_off;
+   end_rad = linethickness/2;
+   bot_rad = linethickness;
+   path pat;
+
+   y_off# := 0.2 staff_space#;
+   define_pixels (y_off);
+
+   pickup pencircle scaled end_rad;
+
+   lft x1 = 0;
+   y1 = 0.8 staff_space + y_off;
+
+   x2 = 0.6 staff_space;
+   y2l = 0  + y_off;
+
+   top rt z3 = (1.7 staff_space, 1.7 staff_space + y_off);
+   z4 = (0, staff_space + y_off);
+
+   penpos2(0.4 staff_space, 90);
+   penpos3(end_rad, angle(z4-z3)+90);
+   penpos1(end_rad, angle(z2-z1)+90);
+
+   pat = z1r..top z1..z1l{z2-z1}
+   ..{z2-(z1+(0.3 staff_space,0))}z2l+(-bot_rad, bot_rad)
+ ..z2l..z2l+(bot_rad, bot_rad){z3-(0.6 staff_space, 
0)-z2}
+   ..{z3-z4}z3r..rt z3..{z4-z3}z3l
+   ..{z2-(z3-(0.6 staff_space,0))}rt z2r..{z1-z2}lft 
z2r{z1-z2}
+   ..cycle;
+   fill pat;
+
+   set_char_box (0, 1.7 staff_space# + epsilon,
+   0, y_off# + 1.7 staff_space#);
+
+
+   penlabels (1,2,3,4);
+fet_endchar;
+
+fet_beginchar ("snap pizzicato (Bartok pizzicato)", "snappizzicat");
save height, width, thickness, superness;

height# = 4/15 staffsize#;



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

Re: Adds tick mark to scripts (issue 6568055)

[dak]

http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf
File mf/feta-scripts.mf (right):

http://codereview.appspot.com/6568055/diff/1/mf/feta-scripts.mf#newcode1781
mf/feta-scripts.mf:1781: fet_beginchar ("snap pizzicato (Bartok
pizzicato)", "snappizzicat");
It would appear you renamed this glyph to "snappizzicat" instead of the
previous "snappizzicato".  I can't imagine this being anything other
than a mistake.

http://codereview.appspot.com/6568055/

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

Re: Project - Eliminating grob parents and outside-staff-priority

[Joe Neeman]

On Wed, Sep 26, 2012 at 4:15 AM, m...@mikesolomon.org
wrote:

> Hey all,
>
> As was the case in a few of my previous projects, before I start something
> new I make architecture changes that facilitate my work.  Working on 2801,
> I've realized that any multi-pass algorithm for the spacing of grobs is
> difficult because results of callback calculations are always cached.  So
> triggering callbacks a second time is, in the current architecture,
> impractical and requires a fair bit of kludgery.
>

Are you proposing not to cache callbacks at all? That sounds like a real
performance killer to me; we would probably end up re-typesetting each beam
hundreds of times.

By the way, the problem is not only in the caching of callbacks; there are
also many other places with side effects (calls to set_property,
translate_axis, suicide, etc).

To start this process, I'd like to expand the role of the
> side-position-interface significantly.  All grobs would use this interface
> for their X and Y offsets and they would have two different grob arrays for
> X and Y side-position-elements.  This would allow me to eliminate two
> things:
>
> 1) parents.  Grobs are X/Y aligned to parents, but these parents could be
> elements in the side-position-elements array.  Functions like get_parent,
> which could be kept around for legacy reasons, could return the first
> element of these arrays for a given axis and raise a warning if there are
> multiple elements.
>

If you get rid of unique parents, what would X-offset mean? Would it be
relative to the System? The first element of side-position-elements array?

2) outside-staff-priority.  Saying a grob has outside staff priority is the
> same thing as saying that a grob has as its Y side support elements all
> inside-staff grobs plus all grobs with lower outside staff priority.  A
> callback creating the side-position-elements arrays could do the sorting
> that takes place in Axis_group_interface::skyline_spacing.
>

I think you'll have trouble making this fully callbacky/functional. For
example, we lay out the outside-staff grobs in a very particular order (the
left-to-right layout thing), which we don't know ahead of time. That is,
until we get _all_ of the outside-staff grobs together, we don't know which
grobs have to depend on which other grobs. That means it isn't really
possible for each grob to determine its own position; there needs to be one
grob that lays them out simultaneously. The same issue will come up, I
think in laying out Accidentals and VerticalAxisGroups.

At some point, I had grand plans to formalize this problem by having two
distinct kinds of properties: one that is user-overridable using callbacks,
and one that is internal and gets set by other grobs as a side-effect.
Everything would have explicit dependencies so that caches could be
invalidated. I even started to write a proof-of-concept in scala, but I
never finished it...


> The benefits of this are twofold:
>
> 1) All work on a multi-pass algorithm could be done with respect to
> side-positioning, making it simpler to find bugs and modify code.
>

Not all positioning is side-positioning.

2) A call to translate_axis in avoid_outside_staff_collisions would be
> eliminated, and translate_axis is bad: it goes against the callback model
> at the core of LilyPond layout.
>

Agreed, but this is just one instance of translate_axis, which is just one
example of a side-effect in lilypond. Is your eventual goal to remove them
all?

The disadvantage is that this results in the construction of many more
> skylines (one for each call to
> Side_position_interface::skyline_side_position).  How this will impact
> performance is uncertain, but it'd probably require more optimization in
> skyline.cc and/or caching of skylines.
>

I would suggest that you completely ignore performance in favor of a clean
design. Performance can come later.

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

Re: Project - Eliminating grob parents and outside-staff-priority

[Francisco Vila]

2012/9/26 m...@mikesolomon.org :
>
> On 26 sept. 2012, at 14:13, David Kastrup  wrote:
>> Conceptually simple problems need to map to conceptually simple
>> solutions.  If they don't, our APIs suck.
>
> We don't have APIs,

Sounds like we found the reason they suck.

Couldn't reseist, sorry.
-- 
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com

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

Re: [GLISS] non-timed or non-musical events "z" "y"

[Werner LEMBERG]

>   \after { c'1\p } 4 \after \< 1*1/6 \!
> 
> This is now in "time order" but I am not really convinced that it is
> less confusing.

You are right, it's worse.  Your first solution is fine except that it
doesn't follow lilypond's suffix notation.


Werner

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

Re: Doc: document \time command fully (2807) (issue 6532055)

[Janek Warchoł]

On Saturday, September 22, 2012, David wrote:

> Nobody can be bothered enough to even comment.  Yet when it comes to
> discussing things that will wreak havoc with the parser, everybody is
> fired up and inspired to throw his own spanner into the works.
>
> I am not saying that this is ill will.  It is just a consequence of
> how we are organizing our work and information flow.  The problem is
> that with regard to developer and user motivation, the consequences
> are indistinguishable from ill will and/or disregard.
>
> Users get "GLISS discussions" where they get the impression that
> developers don't care one bit for them, developers get "reviews" where
> they get the impression that users don't care one bit for them.
>
> I know both impressions to be far from the truth.  But that's more by
> deduction rather than a direct feeling.
>

I agree that we have a serious problem.  Hopefully, you've presented the
first step to solve it: realize that this is not ill will, but rather
unfortunate coincidences and poor wording of emails.

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

Re: Doc: document \time command fully (2807) (issue 6532055)

[Janek Warchoł]

On Saturday, September 22, 2012, David wrote:
>
> 2.15.19:
>
> commit a512132fed73a94068b91fb0bab473**319e477b6e
> Author: David Kastrup 
> Date:   Wed Nov 9 11:37:39 2011 +0100
>
> Fold set-time-signature into \time
>
> It may be instructional to look at the diff itself.  That's the kind of
> thing possible just using music functions now, without the need of
> messing with the parser.  I am not entirely sure that it would not have
> been more prudent to instead fold \compoundTime into \time, but as long
> as nobody bothers reviewing such changes, I need to make them without
> feedback
>

David, i'm sorry that this had happened.  Indeed this was a change both
easy and short to review, and i wish i had reviewed it.  I have missed many
things during my absence in last year Autumn.
I want to assure you that i believe this is a needed and useful change, and
i will be happy to see more similar changes in the future.

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

Re: [GLISS] non-timed or non-musical events "z" "y"

[David Kastrup]

Reinhold Kainhofer  writes:

> On 26/09/2012 14:34, David Kastrup wrote:
>> David Kastrup  writes:
>>
>>> Werner LEMBERG  writes:
>>>
>> It would be tremendously helpful if you can show possible syntax
>> *alternatives* instead of just pretending to be a naysayer.
> I've posted actual working definitions for that purpose.
 It seems I've missed that, lost in the many examples you've given to
 demonstrate what doesn't work.
> They would definitely simplify the kind of entry you are asking for.
 Please repeat.
>>> Sigh.
>>>
>>> at =
>>> #(define-music-function (parser location time event music)
>>>   (ly:duration? ly:music? ly:music?)
>>>   "Place @var{event} at a relative duration @var{time} in relation
>>> to @var{music}."
>>>   #{ << { \skip $time <>$event } $music >> #})
>>>
>>> {
>>>   \at 4 \<
>>>   \at 1*2/3 \!
>>>   c'1\p
>>> }
>> [12 days later, and no followup again]
>>
>> Let's just continue pretending me to be a naysayer then.
>
> You demonstrated that a solution is possible, but quite inconsistent with
> the lilypond language: You have to write the dynamic BEFORE the note,
> although it should be printed AFTER the note...

One can, of course, exchange the order of arguments.  However, then
adding several arguments becomes more awkward:

at =
#(define-music-function (parser location music event time)
  (ly:music? ly:music? ly:duration?)
  "Place @var{event} at a relative duration @var{time} in relation
to @var{music}."
  #{ \context Voice << { \skip $time <>$event } $music >> #})

{
  \at {
   \at { c'1\p } \< 4
  } \! 1*2/3
}

In this case, we might get the same result, however, by specifying the
second duration not in relation to the "main" event but to the already
delayed event:

after =
#(define-music-function (parser location music time event)
  (ly:music? ly:duration? ly:music?)
  "Place @var{event} at a relative duration @var{time} in relation
to @var{music}."
  #{ \context Voice << { \skip $time <>$event } <>$music >> #})

{
  \after { c'1\p } 4 \after \< 1*1/6 \!
}

This is now in "time order" but I am not really convinced that it is
less confusing.

-- 
David Kastrup


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

Re: [GLISS] non-timed or non-musical events "z" "y"

[Werner LEMBERG]

>> at =
>> #(define-music-function (parser location time event music)
>>   (ly:duration? ly:music? ly:music?)
>>   "Place @var{event} at a relative duration @var{time} in relation
>> to @var{music}."
>>   #{ << { \skip $time <>$event } $music >> #})
>>
>> {
>>   \at 4 \<
>>   \at 1*2/3 \!
>>   c'1\p
>> }
> 
> [12 days later, and no followup again]
> 
> Let's just continue pretending me to be a naysayer then.

Hehe.  Sorry for not answering (I was busy, and then I forgot), and
thanks for resending the example.  While I can see that this works,
I'm not getting comfortable with the notation.  I still favor
something like

  c'1-{...}

regardless of its impossibility :-) Maybe things change in the future,
and we can reconsider the whole issue then.


Werner

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

Re: [GLISS] non-timed or non-musical events "z" "y"

[David Kastrup]

Reinhold Kainhofer  writes:

> On 26/09/2012 14:34, David Kastrup wrote:
>> David Kastrup  writes:
>>
>>> Werner LEMBERG  writes:
>>>
>> It would be tremendously helpful if you can show possible syntax
>> *alternatives* instead of just pretending to be a naysayer.
> I've posted actual working definitions for that purpose.
 It seems I've missed that, lost in the many examples you've given to
 demonstrate what doesn't work.
> They would definitely simplify the kind of entry you are asking for.
 Please repeat.
>>> Sigh.
>>>
>>> at =
>>> #(define-music-function (parser location time event music)
>>>   (ly:duration? ly:music? ly:music?)
>>>   "Place @var{event} at a relative duration @var{time} in relation
>>> to @var{music}."
>>>   #{ << { \skip $time <>$event } $music >> #})
>>>
>>> {
>>>   \at 4 \<
>>>   \at 1*2/3 \!
>>>   c'1\p
>>> }
>> [12 days later, and no followup again]
>>
>> Let's just continue pretending me to be a naysayer then.
>
> You demonstrated that a solution is possible, but quite inconsistent with
> the lilypond language: You have to write the dynamic BEFORE the note,
> although it should be printed AFTER the note...

It is conceivable to cook up stuff that would allow to write something
like

c'1\p-\at 4 \< -\at 1*2/3 \!

here.

> In your example, what you want is note with "p", hairpin start, hairpin
> end. But what you have to write is hairpin start, hairpin end, note with
> "p".
>
> So, yes, such hacks as workarounds are certainly possible, but IMO they
> currently don't really fit well with the general concepts of the lilypond
> language (i.e. all dynamics are written using postfix notation)...

If you don't even bother to reply, how am I supposed to guess what your
problem with my approach is?

In my opinion, dynamics are one case where using postfix syntax was a
mistake, exactly because they are not inherently associated with a
particular note but rather a moment of time.  It is _that_ choice which
does not really fit well with the general concepts of the LilyPond
language, and in consequence dynamics are the _dominant_ example for use
of <> and/or s1*0.  So my preferred path to a remedy would rather be to
un-postevent stuff that does not really fit the postevent category
rather than to mess with the timing relations of postevents.

-- 
David Kastrup

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

Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)

[dak]

Reinhold Kainhofer  writes:


On 26/09/2012 11:26, d...@gnu.org wrote:

\once does something entirely different.  It does not turn an

override

into a tweak but rather marks it at being active only at the current
timestep.  \once applies at a single time, \single applies on a

single

item.



To me as a user, \once\override is used to change the next note (or
items attached to it) and \single\tweak is used to change the next
item.


Both are only roughly equivalent when there is only one item per
timestep.  \once\override affects _everything_ happening at the same
time.  Your complaint amounts to "I don't want to know about the
difference between an override and a tweak", but that's not a problem
that can be cured by not providing a method of converting one into the
other.


That \once\override applies to the next timestep, and the
following note incidentally happens at that timestep is an internal
detail when I'm writing a score.



 From a developer's POV there is a different concept involved, but I
doubt that a normal user really cares about this.


Shrug.  Feel free to ignore the distinction until things break for you,
but it is not like _I_ am responsible for it merely because I provide an
additional tool making it easier to deal with that difference.


To me it's basically the same as the \set / \override distinction. It
might be a different concept to anyone who knows the internals, but to
a user both are used to change the default.


Code reviews are not the place for _unrelated_ LilyPond-bashing.  I get
blamed for enough things every day without the need to invent extra
causes.

http://codereview.appspot.com/6495135/

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

Re: [GLISS] non-timed or non-musical events "z" "y"

[Reinhold Kainhofer]

On 26/09/2012 14:34, David Kastrup wrote:
> David Kastrup  writes:
>
>> Werner LEMBERG  writes:
>>
> It would be tremendously helpful if you can show possible syntax
> *alternatives* instead of just pretending to be a naysayer.
 I've posted actual working definitions for that purpose.
>>> It seems I've missed that, lost in the many examples you've given to
>>> demonstrate what doesn't work.
 They would definitely simplify the kind of entry you are asking for.
>>> Please repeat.
>> Sigh.
>>
>> at =
>> #(define-music-function (parser location time event music)
>>   (ly:duration? ly:music? ly:music?)
>>   "Place @var{event} at a relative duration @var{time} in relation
>> to @var{music}."
>>   #{ << { \skip $time <>$event } $music >> #})
>>
>> {
>>   \at 4 \<
>>   \at 1*2/3 \!
>>   c'1\p
>> }
> [12 days later, and no followup again]
>
> Let's just continue pretending me to be a naysayer then.

You demonstrated that a solution is possible, but quite inconsistent with
the lilypond language: You have to write the dynamic BEFORE the note,
although it should be printed AFTER the note...

In your example, what you want is note with "p", hairpin start, hairpin
end. But what you have to write is hairpin start, hairpin end, note with
"p".

So, yes, such hacks as workarounds are certainly possible, but IMO they
currently don't really fit well with the general concepts of the lilypond
language (i.e. all dynamics are written using postfix notation)...

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com


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

Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)

[Reinhold Kainhofer]

On 26/09/2012 11:26, d...@gnu.org wrote:
> \once does something entirely different.  It does not turn an override
> into a tweak but rather marks it at being active only at the current
> timestep.  \once applies at a single time, \single applies on a single
> item.

To me as a user, \once\override is used to change the next note (or
items attached to it) and \single\tweak is used to change the next
item.

That \once\override applies to the next timestep, and the
following note incidentally happens at that timestep is an internal
detail when I'm writing a score.

>From a developer's POV there is a different concept involved, but I
doubt that a normal user really cares about this.
To me it's basically the same as the \set / \override distinction. It
might be a different concept to anyone who knows the internals,
but to a user both are used to change the default.

Cheers,
Reinhold

-- 
--
Reinhold Kainhofer, reinh...@kainhofer.com, http://www.kainhofer.com
 * Financial & Actuarial Math., Vienna Univ. of Technology, Austria
 * http://www.fam.tuwien.ac.at/, DVR: 0005886
 * Edition Kainhofer, Music Publisher, http://www.edition-kainhofer.com


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

Re: Call for help with bar lines

[Thomas Morley]

2012/9/26 Marc Hohl :
> Hello list,
>
> I am quite frustrated – yesterday I managed to get the shift out of
> input/regression/beam-feather-breaking.ly which was one of the
> last problematic files for my patch.
>
> Today, I looked at the new results: it seems to me that
> *every* other regtest file is affected now, but the one mentioned above
> is missing – that's not what the patch is supposed to do.
>
> https://www.yousendit.com/download/TEhYa3ZMTEROQnpWUThUQw
>
> (side note: I did not take a full test cycle, since the last
> regtest results showed only major changes in a couple of files, most of them
> were deliberate, and beam-feather-breaking.ly was the one with the biggest
> optical difference, so I checked just this one and did a make all && make
> doc
> afterwards, which went trough without complaining).
>
> I double-checked the dimensions of the empty bar line: it is
> (0.0 . 0.0) for the current master *and* my patch, so this cannot be
> the culprit.
>
> \version "2.17.4"
>
> #(define (my-bar-line::print grob)
>   (let ((stencil (ly:bar-line::print grob)))
>
>(for-each display (list "\n\nBar line extent:" (ly:stencil-extent
> stencil X) " for bar line "
>(ly:grob-property grob 'glyph-name)))
>stencil))
>
> music = {
>   \override Staff.BarLine #'stencil = #my-bar-line::print
>   c4 c c c \bar ""
>   c c c c \bar "|."
> }
>
> \score {
>   \new Staff {
> \new Voice { \music }
>   }
> }
>
>
> Can anyone with more knowledge than me give me a hint what's wrong?
> IIUC correctly, lilypond draws a bar line at the beginning of each line,
> but in most cases, this is an invisible one.
> If you look at the results of input/regression/lyrics-spanbar.ly,
> the whole stuff is shifted that much to the right that lilypond moves
> the rightmost rest to a new line! I can't believe that a bar line with
> zero width can be the cause for this...
>
> Any hints are highly appreciated!
>
> Regards,
>
> Marc
>
>
>
> ___
> lilypond-devel mailing list
> lilypond-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/lilypond-devel

Hi Marc,

an idea, don't know if it's really helpful:

>From 2.16.0-bar-line.scm, bar-glyph-alist:
The old definition of  bar "empty" was: ("empty" . (() . ()))
The old definition of  bar "" was: ("" . ("" . ""))

The new patch converts bar "empty" into bar ""

If I understand correctly than "empty" eliminates the stencil, whereas
"" prints a stencil with dimensions (0.0 . 0.0).
And if there is _no_ stencil lily doesn't reserve any space _after_
it, but if there is a stencil, even a point-stencil, some space _is_
inserted.

Look at this example:

m =
\relative c' {
\key ces\major
ces
\key cis \major
cis
}

\new Staff \with { \override KeyCancellation #'stencil = #'() } \m
\new Staff \with { \override KeyCancellation #'stencil = #point-stencil } \m

You will notice a small, but visible difference.


HTH,
  Harm


BTW,

2012/9/21 Marc Hohl :

> I had some bad feelings that I grabbed
> your ideas and modified it to my needs without some discussion
> with you.

Rubbish! :)
I'm very happy that I had some ideas, you could run with. You managed
to improve the ideas and their coding in an enormous degree.
Great! :D

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

Re: [GLISS] basics

[Joseph Rushton Wakeling]

On 26/09/12 09:19, Janek Warchoł wrote:

This is a good idea in itself, but i'm afraid we'll drown in the flood
of suggestions if we ask this question now.  Currently we want to
focus on syntax alone.


I do understand that, it's just that I think that proposals for syntax changes 
make more sense when considered in the broader context of the notation you want 
to support.  I wasn't proposing asking it as a mailing-list question, more as a 
project that could probably be handled by relatively few people working from 
musical notation texts.


The reason I think that's important is because without considering the 
notational scope, syntax proposals can easily exclude a range of desirable 
features.  The existing \tempo command is a good example.  It makes perfect 
sense for simple metronome marks, but excludes a whole host of widely-used tempo 
change indications.


It turns out (as per David's earlier email) that it's possible to have a syntax 
which allows all of those possibilities, that isn't much more complex for the 
simple use-case, _and_ is easier on the parser.  But without considering that 
broader scope of notation, it would be easy to say, "Hey, this is just 
complicating the existing syntax for the sake of the parser, why not make the 
parser do the work and keep it simple for users?"



I mean, some things you mentioned don't need
syntax changes, for example this


Fair point, some of these things are best characterized as limits in the 
interpretation of syntax rather than in syntax per se.  I don't think at this 
point it's useful for me to respond in detail on the particular examples, though 
I can do so if you like.



Don't get me wrong - i agree with you that we need to check whether
Lilypond syntax can be used to express all musical notations as
effortlessly as possible.  I just mean that "this can be expressed in
Lily syntax" doesn't equal "this notation is supported by LilyPond".


Sure, but that's kind of what I was getting at -- you want to separate out the 
cases where the syntax is genuinely inadequate, where it's theoretically 
adequate but the internal data structures or engraving algorithms are 
inadequate, where the syntax is unnecessarily verbose, or where it's simply 
difficult to find out about the syntax.


That info then gives you the basis to make rigorous changes to the syntax.  For 
example, it lets you know that proposed changes to the \tempo command don't just 
benefit the parser -- they also expand the range of notation it can cover.



My idea was to ask about this in fourth question:

"what do you find difficult to express in LilyPond syntax?  For
example, things that need to be done by moving something manually
instead of describing the logic behind it."

Probably the question could be formulated better.


I think the question is a good one to ask.  As per my examples, you'll surely 
find quite a few where the real issue is not syntax but the engraving process, 
or simply cases where users aren't aware of the existing solutions.


But the real concern I have is that I don't think that members of the Lilypond 
user list are necessarily representative of the range of engraving activity that 
Lilypond needs to support.  That's the other reason I suggested a systematic 
process of checking syntax/engraving support vs. a broad set of musical notation.



I don't have a copy of the Elaine Gould book you mentioned earlier, but
that, together with Keith Stone and Gardner Read might be a good starting
point.


Yes.  As i'm reading "Behind Bars", i'm noticing things that can't be
expressed in Lily syntax easily.  I will make a report about this.
I don't have other books, though.


I can send you a copy of the couple of papers Keith Stone wrote on contemporary 
notation -- these are a precursor to his book.  They're less comprehensive but 
nevertheless useful.



I don't think i have time to do the engraving myself.  That's why we
should ask users, who in their collective wisdom had encountered
almost anything :)


Well, I'm not suggesting engraving whole works.  Selected snippets should be 
adequate.  Besides the obvious "contemporary composer complex stuff", there are 
also some surprisingly simple notations which show up here -- e.g. Ferneyhough 
frequently has hairpins which last until the end of the note and have a 
concluding dynamic value; that dynamic value falls at the end of the hairpin 
rather than the beginning of the subsequent note (if you get me).


See e.g.
http://soundandmusic.org/thecollection/files/scores/28724w.pdf in for example 
bar 4, Violin 3 (although there are plenty of other examples in the score).


That seems to me a notation for which there genuinely isn't a solution in 
Lilypond syntax or internals, although you could probably fake it with careful 
use of parallel space notation.


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

Re: [GLISS] non-timed or non-musical events "z" "y"

[David Kastrup]

David Kastrup  writes:

> Werner LEMBERG  writes:
>
 It would be tremendously helpful if you can show possible syntax
 *alternatives* instead of just pretending to be a naysayer.
>>>
>>> I've posted actual working definitions for that purpose.
>>
>> It seems I've missed that, lost in the many examples you've given to
>> demonstrate what doesn't work.
>>
>>> They would definitely simplify the kind of entry you are asking for.
>>
>> Please repeat.
>
> Sigh.
>
> at =
> #(define-music-function (parser location time event music)
>   (ly:duration? ly:music? ly:music?)
>   "Place @var{event} at a relative duration @var{time} in relation
> to @var{music}."
>   #{ << { \skip $time <>$event } $music >> #})
>
> {
>   \at 4 \<
>   \at 1*2/3 \!
>   c'1\p
> }

[12 days later, and no followup again]

Let's just continue pretending me to be a naysayer then.

-- 
David Kastrup

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

Re: Doc: Improve documentation of \glissando. (issue 6529043)

[Benkő Pál]

> This example shows a beam extending from a stem to the
> final note of the glissando.  Is this correct, or would
> it be better to suppress the beam?

I made some Bartók and Xenakis scans, see
https://docs.google.com/folder/d/0B7AjGy5hUKtAeWtkdHdfN0l4bm8/edit
such beams can be seen in 0162.jpeg and 0164.jpeg
(the former has examples for avoiding such stems too, using flags).

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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 26 sept. 2012, at 14:13, David Kastrup  wrote:

>> What we need to arrive at is a situation where somebody without a clue
> starting to write stuff will more likely than not get a whole lot of
> things working right without realizing it, rather than getting a whole
> lot of things working wrong without realizing it.

I completely agree.

> 
> Which apparently is what is happening to Marc right now.  He is working
> on a simple problem, and it fails for complex reasons.  And that means
> the current design of our backend is bad.
> 
> Conceptually simple problems need to map to conceptually simple
> solutions.  If they don't, our APIs suck.

We don't have APIs, which is a separate but equally problematic issue.

The conceptually simple problem is that grobs are positioned with respect to 
other grobs.  The conceptually simple solution is that grobs contain arrays of 
these other grobs and use them for the positioning.  That's why I want to make 
this change - it provides one-stop-shopping for positioning changes.

> 
>> I think the change decreases complexity as it makes LilyPond more
>> predictable and boring - objects side position based off of other
>> objects and that's it.  No need for side-position, parents and
>> outside-staff-priority.
> 
> parents are used for a _lot_ of positioning, and for example the
> determination of a common grob parent is an _efficient_ operation.  So
> it might make sense to solve the problem you are thinking of via
> artificial/grouping parents.

This is totally possible - you check the side-position-elements array, and if 
it has multiple members, you find their common refpoint.  This can go all the 
way up to System and VerticalAlignment, both of which will have 
side-position-element arrays of size 0 for both the X and Y axes.

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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

"m...@mikesolomon.org"  writes:

> On 26 sept. 2012, at 13:39, David Kastrup  wrote:
>
>> It sounds to me like it would make more sense that we improve our
>> cache invalidation strategy where it goes wrong
>
> There is currently no cache invalidation strategy.

Sounds like we found the place where it goes wrong.

>> rather than shifting the
>> problem around in increasingly complex manners.
>
> There is currently no way in LilyPond to trace what properties depend
> on what properties.  So if we want to invalidate the cache of property
> X, it is very difficult to invalidate the caches of properties that
> depend on it.  This is made considerably easier if side-positioning is
> streamlined.  When a grob X's side position changes for a given axis,
> iterate over its side-position elements and recalculate their offsets.
> That's one of the main reasons I want to make this change.

What we need to arrive at is a situation where somebody without a clue
starting to write stuff will more likely than not get a whole lot of
things working right without realizing it, rather than getting a whole
lot of things working wrong without realizing it.

Which apparently is what is happening to Marc right now.  He is working
on a simple problem, and it fails for complex reasons.  And that means
the current design of our backend is bad.

Conceptually simple problems need to map to conceptually simple
solutions.  If they don't, our APIs suck.

> I think the change decreases complexity as it makes LilyPond more
> predictable and boring - objects side position based off of other
> objects and that's it.  No need for side-position, parents and
> outside-staff-priority.

parents are used for a _lot_ of positioning, and for example the
determination of a common grob parent is an _efficient_ operation.  So
it might make sense to solve the problem you are thinking of via
artificial/grouping parents.  I can't vouch for it, obviously, as the
backend is mostly opaque to me right now.  But it is a possibility.

-- 
David Kastrup

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

Re: Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

On 26 sept. 2012, at 13:39, David Kastrup  wrote:

> "m...@mikesolomon.org"  writes:
> 
>> As was the case in a few of my previous projects, before I start
>> something new I make architecture changes that facilitate my work.
>> Working on 2801, I've realized that any multi-pass algorithm for the
>> spacing of grobs is difficult because results of callback calculations
>> are always cached.  So triggering callbacks a second time is, in the
>> current architecture, impractical and requires a fair bit of kludgery.
> 
> [...]
> 
>> performance is uncertain, but it'd probably require more optimization
>> in skyline.cc and/or caching of skylines.
> 
> It sounds to me like you consider caching a bad idea so you want to
> remove it, and to make this removal feasible you think you will be
> required to do caching.
> 

You're right - I explained myself poorly.

The caching of skylines would come from similar content.  i.e. if Skyline X == 
Skyline A and Skyline Y == Skyline B and we have already measured the distance 
between A and B, use that as the distance between X and Y.  Here, equality is 
defined as having buildings with the same start_, end_, slope_ and y_offset_.  
So it's a different type of caching than the caching of grob properties.

> It sounds to me like it would make more sense that we improve our cache
> invalidation strategy where it goes wrong

There is currently no cache invalidation strategy.

> rather than shifting the
> problem around in increasingly complex manners.
> 

There is currently no way in LilyPond to trace what properties depend on what 
properties.  So if we want to invalidate the cache of property X, it is very 
difficult to invalidate the caches of properties that depend on it.  This is 
made considerably easier if side-positioning is streamlined.  When a grob X's 
side position changes for a given axis, iterate over its side-position elements 
and recalculate their offsets.  That's one of the main reasons I want to make 
this change.

I think the change decreases complexity as it makes LilyPond more predictable 
and boring - objects side position based off of other objects and that's it.  
No need for side-position, parents and outside-staff-priority.

Cheers,
MS


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

Re: Project - Eliminating grob parents and outside-staff-priority

[David Kastrup]

"m...@mikesolomon.org"  writes:

> As was the case in a few of my previous projects, before I start
> something new I make architecture changes that facilitate my work.
> Working on 2801, I've realized that any multi-pass algorithm for the
> spacing of grobs is difficult because results of callback calculations
> are always cached.  So triggering callbacks a second time is, in the
> current architecture, impractical and requires a fair bit of kludgery.

[...]

> performance is uncertain, but it'd probably require more optimization
> in skyline.cc and/or caching of skylines.

It sounds to me like you consider caching a bad idea so you want to
remove it, and to make this removal feasible you think you will be
required to do caching.

It sounds to me like it would make more sense that we improve our cache
invalidation strategy where it goes wrong rather than shifting the
problem around in increasingly complex manners.

-- 
David Kastrup


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

Project - Eliminating grob parents and outside-staff-priority

[m...@mikesolomon.org]

Hey all,

As was the case in a few of my previous projects, before I start something new 
I make architecture changes that facilitate my work.  Working on 2801, I've 
realized that any multi-pass algorithm for the spacing of grobs is difficult 
because results of callback calculations are always cached.  So triggering 
callbacks a second time is, in the current architecture, impractical and 
requires a fair bit of kludgery.

To start this process, I'd like to expand the role of the 
side-position-interface significantly.  All grobs would use this interface for 
their X and Y offsets and they would have two different grob arrays for X and Y 
side-position-elements.  This would allow me to eliminate two things:

1) parents.  Grobs are X/Y aligned to parents, but these parents could be 
elements in the side-position-elements array.  Functions like get_parent, which 
could be kept around for legacy reasons, could return the first element of 
these arrays for a given axis and raise a warning if there are multiple 
elements.

2) outside-staff-priority.  Saying a grob has outside staff priority is the 
same thing as saying that a grob has as its Y side support elements all 
inside-staff grobs plus all grobs with lower outside staff priority.  A 
callback creating the side-position-elements arrays could do the sorting that 
takes place in Axis_group_interface::skyline_spacing.

The benefits of this are twofold:

1) All work on a multi-pass algorithm could be done with respect to 
side-positioning, making it simpler to find bugs and modify code.
2) A call to translate_axis in avoid_outside_staff_collisions would be 
eliminated, and translate_axis is bad: it goes against the callback model at 
the core of LilyPond layout.

The disadvantage is that this results in the construction of many more skylines 
(one for each call to Side_position_interface::skyline_side_position).  How 
this will impact performance is uncertain, but it'd probably require more 
optimization in skyline.cc and/or caching of skylines.

Before I do this, which will take me several months, does anyone have any 
objections?  Do people think it's a good idea?

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

Re: Call for help with bar lines

[m...@mikesolomon.org]

On 26 sept. 2012, at 12:46, Phil Holmes  wrote:

>> I've no idea if this will help, so feel free to ignore it.  However, my 
>> recollection is that running lily with -ddump-signatures gives information 
>> on extents in the output file?
> 

This is a great idea - you can get a lot of useful data from these files.

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

Re: Call for help with bar lines

[Phil Holmes]

- Original Message - 
From: 

To: "Marc Hohl" 
Cc: "Lily-Devel List" 
Sent: Wednesday, September 26, 2012 11:34 AM
Subject: Re: Call for help with bar lines




On 26 sept. 2012, at 12:07, Marc Hohl  wrote:


Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:

On 26 sept. 2012, at 11:01, Marc Hohl  wrote:


Can anyone with more knowledge than me give me a hint what's wrong?
IIUC correctly, lilypond draws a bar line at the beginning of each 
line,

but in most cases, this is an invisible one.
If you look at the results of input/regression/lyrics-spanbar.ly,
the whole stuff is shifted that much to the right that lilypond moves
the rightmost rest to a new line! I can't believe that a bar line with
zero width can be the cause for this...

Any hints are highly appreciated!

Regards,

Marc


Hey Marc,

I unfortunately don't have much time to help you out, but I can tell you 
that you are on the right track doing prints to the command line.  I 
would not, however, stash them in lambda functions used as overrides, as 
this can sometimes interfere with pure properties.
Thanks for the hint, but I assume that this is not the case here, where I 
wrap ly:bar-line::print into

a callback ...


ly:bar-line::print is a registered pure-print-callback (line 2712 of 
define-grobs.scm), so when you use a custom callback, LilyPond stops 
finding pure heights of bar lines.  To make sure that pure extents kick 
in, you'd need to do something like


\override BarLine #'print = #my-print-callback
\override BarLine #'Y-extent = #(ly:unpure-pure-container 
ly:grob::stencil-height (lambda (grob s e) (ly:grob::stencil-height 
grob)))


You can check on the CG subchapter on pure properties for more examples.



There are a couple classic things I use, most of which are in grob.cc.

In Grob::pure_relative_y_coordinate, before the last return statement, 
you can put:


if (name () == "BarLine") print ("RELATIVE COORDINATE for BARLINE at 
spanned rank %d: %4.4f\n", spanned_rank_interval ()[LEFT], out);

This can be quite handy, thanks!

But back to my original question: can someone please have a quick glimpse 
at the regtests?

Perhaps he can spot the cuprit very easily ...


I looked at them and my guess is that the pure extents (and maybe even 
unpure extents) are being changed, which is why I suggested doing prints 
to the command line for extents (both X and Y).



I've no idea if this will help, so feel free to ignore it.  However, my 
recollection is that running lily with -ddump-signatures gives information 
on extents in the output file?


--
Phil Holmes 



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

Re: Call for help with bar lines

[m...@mikesolomon.org]

On 26 sept. 2012, at 12:07, Marc Hohl  wrote:

> Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:
>> On 26 sept. 2012, at 11:01, Marc Hohl  wrote:
>> 
>>> Can anyone with more knowledge than me give me a hint what's wrong?
>>> IIUC correctly, lilypond draws a bar line at the beginning of each line,
>>> but in most cases, this is an invisible one.
>>> If you look at the results of input/regression/lyrics-spanbar.ly,
>>> the whole stuff is shifted that much to the right that lilypond moves
>>> the rightmost rest to a new line! I can't believe that a bar line with
>>> zero width can be the cause for this...
>>> 
>>> Any hints are highly appreciated!
>>> 
>>> Regards,
>>> 
>>> Marc
>>> 
>> Hey Marc,
>> 
>> I unfortunately don't have much time to help you out, but I can tell you 
>> that you are on the right track doing prints to the command line.  I would 
>> not, however, stash them in lambda functions used as overrides, as this can 
>> sometimes interfere with pure properties.
> Thanks for the hint, but I assume that this is not the case here, where I 
> wrap ly:bar-line::print into
> a callback ...

ly:bar-line::print is a registered pure-print-callback (line 2712 of 
define-grobs.scm), so when you use a custom callback, LilyPond stops finding 
pure heights of bar lines.  To make sure that pure extents kick in, you'd need 
to do something like

\override BarLine #'print = #my-print-callback
\override BarLine #'Y-extent = #(ly:unpure-pure-container 
ly:grob::stencil-height (lambda (grob s e) (ly:grob::stencil-height grob)))

You can check on the CG subchapter on pure properties for more examples.

>> 
>> There are a couple classic things I use, most of which are in grob.cc.
>> 
>> In Grob::pure_relative_y_coordinate, before the last return statement, you 
>> can put:
>> 
>> if (name () == "BarLine") print ("RELATIVE COORDINATE for BARLINE at spanned 
>> rank %d: %4.4f\n", spanned_rank_interval ()[LEFT], out);
> This can be quite handy, thanks!
> 
> But back to my original question: can someone please have a quick glimpse at 
> the regtests?
> Perhaps he can spot the cuprit very easily ...

I looked at them and my guess is that the pure extents (and maybe even unpure 
extents) are being changed, which is why I suggested doing prints to the 
command line for extents (both X and Y).

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

Re: Call for help with bar lines

[David Kastrup]

Marc Hohl  writes:

> Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:
>
>> I unfortunately don't have much time to help you out, but I can tell
>> you that you are on the right track doing prints to the command
>> line.  I would not, however, stash them in lambda functions used as
>> overrides, as this can sometimes interfere with pure properties.
> Thanks for the hint, but I assume that this is not the case here,
> where I wrap ly:bar-line::print into
> a callback ...

_I_ wouldn't dare competing against Mike in a purity test.  Unless you
know your way inside/out of pure/impure containers and stuff, it might
really be worth a try to check out his debugging suggestion.

In a different vein, I have the impression that we might need to revisit
the programming model if we want to have a chance of more than 2 people
ever being able to work successfully on/with the backend.

-- 
David Kastrup


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

Re: [GLISS] basics

[Janek Warchoł]

On Wed, Sep 26, 2012 at 11:53 AM, David Kastrup  wrote:
> To get back at the hammer analogy, users might ask for a
> heavier hammer if they have problems getting screws in place.  Or for a
> more convenient way to enter/express xxx when they should not be
> required to bother with xxx at all.

Yes, that's a problem.
Anyway, i think that we agree that we'll have to sort user responses
and that not all of them will actually need language changes to solve.

>> Do i understand correctly that you mean "it's good to have helper
>> functions [1] that make code clean and tidy.  It is also good to be
>> able to look at the code of such function and create your own
>> derivative function if necessary"?
>>
>> If so, that's like +111 from me - couldn't agree more.
>>
>> [1] or other helper stuff, even if technically it's not a function
>
> I would not call "an interface to a musical concept" a "helper function"
> just because it is reasonably easy to translate that concept into a
> graphical representation.

I don't understand what you mean here...[1]  Anyway, i should've
provided an example.  By "helper stuff" i mean things like your \at
function, David Nalesnik's \shape, being able to write
\compressFullBarRests instead of \set SkipBars = ##t etc.

best,
Janek

[1] you don't have to explain (unless you care about it a lot) - i
know that we can talk for hours ;) and there's so much other emails
flying around that it's hard to keep up: i haven't done anything other
than email since i've woken up, except for breakfast :P
I'm trying to get my replies shorter...

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

Re: Call for help with bar lines

[Marc Hohl]

Am 26.09.2012 11:47, schrieb m...@mikesolomon.org:

On 26 sept. 2012, at 11:01, Marc Hohl  wrote:


Can anyone with more knowledge than me give me a hint what's wrong?
IIUC correctly, lilypond draws a bar line at the beginning of each line,
but in most cases, this is an invisible one.
If you look at the results of input/regression/lyrics-spanbar.ly,
the whole stuff is shifted that much to the right that lilypond moves
the rightmost rest to a new line! I can't believe that a bar line with
zero width can be the cause for this...

Any hints are highly appreciated!

Regards,

Marc


Hey Marc,

I unfortunately don't have much time to help you out, but I can tell you that 
you are on the right track doing prints to the command line.  I would not, 
however, stash them in lambda functions used as overrides, as this can 
sometimes interfere with pure properties.
Thanks for the hint, but I assume that this is not the case here, where 
I wrap ly:bar-line::print into

a callback ...


There are a couple classic things I use, most of which are in grob.cc.

In Grob::pure_relative_y_coordinate, before the last return statement, you can 
put:

if (name () == "BarLine") print ("RELATIVE COORDINATE for BARLINE at spanned rank 
%d: %4.4f\n", spanned_rank_interval ()[LEFT], out);

This can be quite handy, thanks!

But back to my original question: can someone please have a quick 
glimpse at the regtests?

Perhaps he can spot the cuprit very easily ...

Thanks in advance,

Marc


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

Re: Feature request

[Benkő Pál]

2012/9/25 David Kastrup :
> But if I remember correctly, beam subdivision is a
> multi-level problem, not just two-level.

yes, see the attachment to
http://code.google.com/p/lilypond/issues/detail?id=2361

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

Re: [GLISS] basics

[David Kastrup]

Janek Warchoł  writes:

> On Wed, Sep 26, 2012 at 9:52 AM, David Kastrup  wrote:
>> Janek Warchoł  writes:
>>> Currently we want to focus on syntax alone.
>>
>> If all you have is a hammer, every problem looks like a nail.
>>
>> "Hard to do" is a large problem class, and it is not necessarily clear
>> to users which problems could be diminuished by syntax changes, which
>> are accessible nicely with the existing syntax, and which would warrant
>> different mechanisms and frameworks.
>
> Sorry, i should've used the term "ly language".  What i mean: when
> asking users about their problems, i wouldn't differentiate between
> these two areas - i'd just ask for everythin.  It would be our job to
> decide what could be done with a bit of syntactic sugar, and what
> needs changes in mechanisms and frameworks.
> In other words, i'd just ask users for "things that need a change in
> ly language", where "a change in ly language" can be either a helper
> function or an actual change in how things work internally... I hope
> that's clear.
> (and it seems that we agree after all)

Not sure.  To get back at the hammer analogy, users might ask for a
heavier hammer if they have problems getting screws in place.  Or for a
more convenient way to enter/express xxx when they should not be
required to bother with xxx at all.

>> The text-based input of LilyPond makes it orders of magnitude better
>> for swapping home-made recipes than WYSIWYG systems, but we should
>> not lose sight of the value of tweak-free black-box solutions over
>> that.  The idea with a black-box approach is not necessarily that you
>> _can't_ open the box and look inside, but that you in general don't
>> need to do so.
>
> Do i understand correctly that you mean "it's good to have helper
> functions [1] that make code clean and tidy.  It is also good to be
> able to look at the code of such function and create your own
> derivative function if necessary"?
>
> If so, that's like +111 from me - couldn't agree more.
>
> [1] or other helper stuff, even if technically it's not a function

I would not call "an interface to a musical concept" a "helper function"
just because it is reasonably easy to translate that concept into a
graphical representation.

-- 
David Kastrup


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

Re: Call for help with bar lines

[m...@mikesolomon.org]

On 26 sept. 2012, at 11:01, Marc Hohl  wrote:

> Can anyone with more knowledge than me give me a hint what's wrong?
> IIUC correctly, lilypond draws a bar line at the beginning of each line,
> but in most cases, this is an invisible one.
> If you look at the results of input/regression/lyrics-spanbar.ly,
> the whole stuff is shifted that much to the right that lilypond moves
> the rightmost rest to a new line! I can't believe that a bar line with
> zero width can be the cause for this...
> 
> Any hints are highly appreciated!
> 
> Regards,
> 
> Marc
> 

Hey Marc,

I unfortunately don't have much time to help you out, but I can tell you that 
you are on the right track doing prints to the command line.  I would not, 
however, stash them in lambda functions used as overrides, as this can 
sometimes interfere with pure properties.

There are a couple classic things I use, most of which are in grob.cc.

In Grob::pure_relative_y_coordinate, before the last return statement, you can 
put:

if (name () == "BarLine") print ("RELATIVE COORDINATE for BARLINE at spanned 
rank %d: %4.4f\n", spanned_rank_interval ()[LEFT], out);

You can put similar prints in the extent function (but this time printing the 
two extent values).

Hopefully the difference will show up here.

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

Re: [GLISS] basics

[Janek Warchoł]

On Wed, Sep 26, 2012 at 9:52 AM, David Kastrup  wrote:
> Janek Warchoł  writes:
>> Currently we want to focus on syntax alone.
>
> If all you have is a hammer, every problem looks like a nail.
>
> "Hard to do" is a large problem class, and it is not necessarily clear
> to users which problems could be diminuished by syntax changes, which
> are accessible nicely with the existing syntax, and which would warrant
> different mechanisms and frameworks.

Sorry, i should've used the term "ly language".  What i mean: when
asking users about their problems, i wouldn't differentiate between
these two areas - i'd just ask for everythin.  It would be our job to
decide what could be done with a bit of syntactic sugar, and what
needs changes in mechanisms and frameworks.
In other words, i'd just ask users for "things that need a change in
ly language", where "a change in ly language" can be either a helper
function or an actual change in how things work internally... I hope
that's clear.
(and it seems that we agree after all)

> The text-based input of LilyPond makes it orders of magnitude better for
> swapping home-made recipes than WYSIWYG systems, but we should not lose
> sight of the value of tweak-free black-box solutions over that.  The
> idea with a black-box approach is not necessarily that you _can't_ open
> the box and look inside, but that you in general don't need to do so.

Do i understand correctly that you mean "it's good to have helper
functions [1] that make code clean and tidy.  It is also good to be
able to look at the code of such function and create your own
derivative function if necessary"?

If so, that's like +111 from me - couldn't agree more.

[1] or other helper stuff, even if technically it's not a function

cheers,
Janek

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

Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)

[dak]

On 2012/09/26 09:05:18, Reinhold wrote:

is there any particular reason why you created a new command (\single)

and

didn't reuse \once. IMO, using \once as an indicator that the next

command

applies only to the next item would make it more consistent.


\once does something entirely different.  It does not turn an override
into a tweak but rather marks it at being active only at the current
timestep.  \once applies at a single time, \single applies on a single
item.

My first reaction was "how can one not understand this?" but then I
reread the description, and it says
"\single can, like \once, translate larger override sets like \voiceOne
into a tweak, so you can use things like \single\voiceOne c4".

Uh, ouch.  This is a rather sense-altering distortion/contraction of
"\single, like \once, can be applied to music consisting of one or more
overrides.  It translates such an override set, for example \voiceOne,
into a tweak on the following music item, so you can use things like
\single\voiceOne c4 inside of a chord and have it only affect a single
notehead of the chord".  Which does not make all that much sense
musically since \voiceOne mostly applies to stuff like stems that are
per-chord anyway.  So I probably should rather use something like
\single\easyHeadsOn for illustration.

I'll alter the description accordingly.

http://codereview.appspot.com/6495135/

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

Re: Issue 2717: Implement \single, \omit and \hide (issue 6495135)

[reinhold . kainhofer]

is there any particular reason why you created a new command (\single)
and didn't reuse \once. IMO, using \once as an indicator that the next
command applies only to the next item would make it more consistent.

http://codereview.appspot.com/6495135/

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

Call for help with bar lines

[Marc Hohl]

Hello list,

I am quite frustrated – yesterday I managed to get the shift out of
input/regression/beam-feather-breaking.ly which was one of the
last problematic files for my patch.

Today, I looked at the new results: it seems to me that
*every* other regtest file is affected now, but the one mentioned above
is missing – that's not what the patch is supposed to do.

https://www.yousendit.com/download/TEhYa3ZMTEROQnpWUThUQw

(side note: I did not take a full test cycle, since the last
regtest results showed only major changes in a couple of files, most of them
were deliberate, and beam-feather-breaking.ly was the one with the biggest
optical difference, so I checked just this one and did a make all && 
make doc

afterwards, which went trough without complaining).

I double-checked the dimensions of the empty bar line: it is
(0.0 . 0.0) for the current master *and* my patch, so this cannot be
the culprit.

\version "2.17.4"

#(define (my-bar-line::print grob)
  (let ((stencil (ly:bar-line::print grob)))

   (for-each display (list "\n\nBar line extent:" 
(ly:stencil-extent stencil X) " for bar line "

   (ly:grob-property grob 'glyph-name)))
   stencil))

music = {
  \override Staff.BarLine #'stencil = #my-bar-line::print
  c4 c c c \bar ""
  c c c c \bar "|."
}

\score {
  \new Staff {
\new Voice { \music }
  }
}


Can anyone with more knowledge than me give me a hint what's wrong?
IIUC correctly, lilypond draws a bar line at the beginning of each line,
but in most cases, this is an invisible one.
If you look at the results of input/regression/lyrics-spanbar.ly,
the whole stuff is shifted that much to the right that lilypond moves
the rightmost rest to a new line! I can't believe that a bar line with
zero width can be the cause for this...

Any hints are highly appreciated!

Regards,

Marc



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

Re: [GLISS] basics

[David Kastrup]

Janek Warchoł  writes:

> On Tue, Sep 25, 2012 at 8:21 PM, Joseph Rushton Wakeling
>  wrote:
>> Actually, rather than "what users find difficult" (which I agree is
>> important in and of itself), perhaps it's better to take a different tack:
>> to try and prepare a systematic specification for the musical notations that
>> Lilypond should support.
>> Then, go through each one and identify the extent Lilypond supports that
>> notation
>
> This is a good idea in itself, but i'm afraid we'll drown in the flood
> of suggestions if we ask this question now.  Currently we want to
> focus on syntax alone.

If all you have is a hammer, every problem looks like a nail.

"Hard to do" is a large problem class, and it is not necessarily clear
to users which problems could be diminuished by syntax changes, which
are accessible nicely with the existing syntax, and which would warrant
different mechanisms and frameworks.

One thing to keep in mind is that every non-trivial snippet is an
example of musical notation that LilyPond has no ready-made solution
for.

The text-based input of LilyPond makes it orders of magnitude better for
swapping home-made recipes than WYSIWYG systems, but we should not lose
sight of the value of tweak-free black-box solutions over that.  The
idea with a black-box approach is not necessarily that you _can't_ open
the box and look inside, but that you in general don't need to do so.

I am digressing.  We can't really get developers to agree all that much
about what problems should be tackled via syntactic means, so it would
be a bit much to demand the same from users before offering feedback.

So I think "focusing on syntax alone" is likely left to us when sifting
through the reports.

-- 
David Kastrup


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

Re: Get along with use of grob-property instead of grob-property-path in overrides (issue 6544060)

[Janek Warchoł]

On Wed, Sep 26, 2012 at 9:10 AM,   wrote:
> On 2012/09/26 06:14:04, janek wrote:
>> i find the name misleading.
>
> That terminology is employed in a number of places in the grammar and
> code, and this patch does not invent any property but just deals
> better with existing definitions and usage.

Sure, i didn't mean to blame you.

> Not "on need".  If the property grob-property is defined, it calls
> "list" on it to create a one-element list (which this code as well as
> similar code elsewhere is expecting), otherwise it takes the property
> grob-property-path as the source for that list.

Ah!  thanks for explanation.
Janek

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

Re: parser.yy: remove STRING_IDENTIFIER token (issue 6542057)

[Janek Warchoł]

On Wed, Sep 26, 2012 at 8:58 AM,   wrote:
> In short, instead of a cryptic error message and dubious error recovery,
> the user gets a human-understandable error message and a recovery more
> likely not to cause follow-up errors.

Ok.  I supposed this was the case, but wanted to be sure.  I don't
think commit message needs rewording.
Thanks for explanation!
Janek

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

Re: [GLISS] basics

[Janek Warchoł]

On Tue, Sep 25, 2012 at 8:21 PM, Joseph Rushton Wakeling
 wrote:
> Actually, rather than "what users find difficult" (which I agree is
> important in and of itself), perhaps it's better to take a different tack:
> to try and prepare a systematic specification for the musical notations that
> Lilypond should support.
> Then, go through each one and identify the extent Lilypond supports that
> notation

This is a good idea in itself, but i'm afraid we'll drown in the flood
of suggestions if we ask this question now.  Currently we want to
focus on syntax alone.  I mean, some things you mentioned don't need
syntax changes, for example this

> slight horizontal and/or vertical offsets of dynamics, as is commonly
> found in many scores.  See e.g. Janek's example of the Mozart Requiem
> http://news.lilynet.net/?The-LilyPond-Report-26#lilypond_output_analysis

is just a (valid) feature request.  There is no new syntax necessary,
Lily should just do this automatically.

>   EXAMPLE: arrowed quarter-tone notation.  For details, see:
>   https://code.google.com/p/lilypond/issues/detail?id=1278

I think that this is more a matter of internal changes (i.e. how Lily
should look at pitches) rather than syntax.

Don't get me wrong - i agree with you that we need to check whether
Lilypond syntax can be used to express all musical notations as
effortlessly as possible.  I just mean that "this can be expressed in
Lily syntax" doesn't equal "this notation is supported by LilyPond".

My idea was to ask about this in fourth question:

"what do you find difficult to express in LilyPond syntax?  For
example, things that need to be done by moving something manually
instead of describing the logic behind it."

Probably the question could be formulated better.

> I don't have a copy of the Elaine Gould book you mentioned earlier, but
> that, together with Keith Stone and Gardner Read might be a good starting
> point.

Yes.  As i'm reading "Behind Bars", i'm noticing things that can't be
expressed in Lily syntax easily.  I will make a report about this.
I don't have other books, though.

> It's also probably worth taking a reflective sample of compositions
> from different periods and seeing how readily they can be engraved; from
> contemporary music, for example, I think that Boulez, Stockhausen and
> Ferneyhough will probably give a good reflection of what Lilypond's limits
> are.

I don't think i have time to do the engraving myself.  That's why we
should ask users, who in their collective wisdom had encountered
almost anything :)

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

Re: Get along with use of grob-property instead of grob-property-path in overrides (issue 6544060)

[dak]

Reviewers: janek,

Message:
On 2012/09/26 06:14:04, janek wrote:

Do i understand correctly that grob-property-path is just a list of

properties,

like '('thickness 'gap 'color)?


Apart from overquoting (when quoting a list, its members are already
quoted), yes.


If so, i find the name misleading.


That terminology is employed in a number of places in the grammar and
code, and this patch does not invent any property but just deals
better with existing definitions and usage.


Anyway, i don't feel competent to give an "LGTM" to a Scheme patch i

don't

understand - but i had certainly not noticed anything wrong.



http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly

File ly/music-functions-init.ly (right):



http://codereview.appspot.com/6544060/diff/1/ly/music-functions-init.ly#newcode1073

ly/music-functions-init.ly:1073: (ly:music-property m

'grob-property-path)

Scheme syntax pwned me again, but i suppose this just uses either

grob-property

or grob-property-path depending on need.


Not "on need".  If the property grob-property is defined, it calls
"list" on it to create a one-element list (which this code as well as
similar code elsewhere is expecting), otherwise it takes the property
grob-property-path as the source for that list.

This is the same way that lily/property-iterator.cc does it.  I
consider this a rather awkward compatibility crutch (grob-property is
not used by any manually written overwrites, just by legacy Scheme
code), but it was not the scope of this patch to change that.


Description:
Get along with use of grob-property instead of grob-property-path in
overrides

LilyPond uses a willy-nilly mixture of grob-property and
grob-property-path when generating overrides programmatically (the
parser only uses grob-property-path).  Several override-reinterpreting
commands and functionalities were not prepared to deal with this.

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

Affected files:
  M ly/music-functions-init.ly
  M scm/lily-library.scm


Index: ly/music-functions-init.ly
diff --git a/ly/music-functions-init.ly b/ly/music-functions-init.ly
index  
e1dcd992e00bf66c60fa7e09e012632732fc7db6..0fa79af3ddb63acd68e1861710c29cfa6903ccf6  
100644

--- a/ly/music-functions-init.ly
+++ b/ly/music-functions-init.ly
@@ -1067,11 +1067,17 @@ a context modification duplicating their effect.")
   (cons* 'push
  (ly:music-property m 'symbol)
  (ly:music-property m 'grob-value)
- (ly:music-property m 'grob-property-path)))
+  (cond
+   ((ly:music-property m 'grob-property #f) => list)
+   (else
+(ly:music-property m 'grob-property-path)
  ((RevertProperty)
   (cons* 'pop
  (ly:music-property m 'symbol)
- (ly:music-property m 'grob-property-path)
+  (cond
+   ((ly:music-property m 'grob-property #f) => list)
+   (else
+(ly:music-property m 'grob-property-path)))
   (case (ly:music-property m 'name)
 ((ApplyContext)
  (ly:add-context-mod mods
Index: scm/lily-library.scm
diff --git a/scm/lily-library.scm b/scm/lily-library.scm
index  
ec1097a32b7ace1ae756e86f61fd5fa08f6cffd7..854980012cea5d3da40df5b955bfde86c4e87a97  
100644

--- a/scm/lily-library.scm
+++ b/scm/lily-library.scm
@@ -275,11 +275,17 @@ bookoutput function"
(cons* 'push
   symbol
   (ly:music-property m 'grob-value)
-  (ly:music-property m 'grob-property-path)))
-  ((RevertProperty)
+   (cond
+((ly:music-property m 'grob-property #f) => list)
+(else
+ (ly:music-property m 'grob-property-path)
+   ((RevertProperty)
(cons* 'pop
   symbol
-  (ly:music-property m 'grob-property-path))
+   (cond
+((ly:music-property m 'grob-property #f) => list)
+(else
+ (ly:music-property m 'grob-property-path
  (case (ly:music-property m 'name)
((ApplyContext)
 (ly:add-context-mod mods
@@ -326,11 +332,17 @@ bookoutput function"
  (cons* 'push
 (ly:music-property m 'symbol)
 (ly:music-property m 'grob-value)
-(ly:music-property m 'grob-property-path)))
+ (cond
+  ((ly:music-property m 'grob-property #f) => list)
+  (else
+   (ly:music-property m 'grob-property-path)
 ((RevertProperty)
  (cons* 'pop