Gives each grob an integer hash.

Gives each grob an integer hash.

[MikeSol, 2011-05-31 15:57:51]

This patch'll be useful for some advanced tweaks I'm doing while running
LilyPond in multiple passes.  Lemme know if it looks all right.

Cheers,
MS

[Neil Puttock, 2011-05-31 16:28:15]

On 2011/05/31 15:57:51, MikeSol wrote:
> This patch'll be useful for some advanced tweaks I'm doing while running
> LilyPond in multiple passes.  Lemme know if it looks all right.

Hmm, I'm not convinced, particularly as you could easily do the same thing via a
Scheme engraver.

Cheers,
Neil

[mike_apollinemike.com, 2011-05-31 18:07:16]

On May 31, 2011, at 5:28 PM, n.puttock@gmail.com wrote:

> On 2011/05/31 15:57:51, MikeSol wrote:
>> This patch'll be useful for some advanced tweaks I'm doing while
> running
>> LilyPond in multiple passes.  Lemme know if it looks all right.
> 
> Hmm, I'm not convinced, particularly as you could easily do the same
> thing via a Scheme engraver.


I actually tried this, but the issue is that when new grobs are made outside of
an engraver context (i.e. broken spanners), there is no way to keep track of
them.  This seems the only way to catch every grob made during a session. 
Unless there is some type of engraver hack that I am overlooking, which is
always possible.

Cheers,
MS

[Neil Puttock, 2011-05-31 21:52:49]

On 31 May 2011 19:07, mike@apollinemike.com <mike@apollinemike.com> wrote:

> I actually tried this, but the issue is that when new grobs are made outside
of an engraver context (i.e. broken spanners), there is no way to keep track of
them.  This seems the only way to catch every grob made during a session.
 Unless there is some type of engraver hack that I am overlooking, which is
always possible.

I don't think so; cloning occurs after translation's ended, so there's
no way to announce the cloned grobs.

Cheers,
Neil

[hanwenn, 2011-06-07 04:05:07]

We had something like this a long time ago.  Search for Object_key
in the history, eg. commit 4a964b10c411827584eb720c63cd0d6fc5b65d72.

This was intended for making persistent tweaks,  but it never got used
so we scrapped it.

I'm on a holiday, so I dont have time to look into this, but it seems
a less versatile reimplementation of what we scrapped, so I am
skeptical that this should be included this for general distribution.


On Tue, May 31, 2011 at 12:57 PM,  <mtsolo@gmail.com> wrote:
> Reviewers: ,
>
> Message:
> This patch'll be useful for some advanced tweaks I'm doing while running
> LilyPond in multiple passes.  Lemme know if it looks all right.
>


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

[mike_apollinemike.com, 2011-06-07 06:50:16]

Fair enough.  I used it for a few rather esoteric experiments w/ algorithmic
composition - it's true that the utility of such a feature is limited to
hardcore tweaking.

Cheers,
MS

On Jun 7, 2011, at 6:05 AM, Han-Wen Nienhuys wrote:

> We had something like this a long time ago.  Search for Object_key
> in the history, eg. commit 4a964b10c411827584eb720c63cd0d6fc5b65d72.
> 
> This was intended for making persistent tweaks,  but it never got used
> so we scrapped it.
> 
> I'm on a holiday, so I dont have time to look into this, but it seems
> a less versatile reimplementation of what we scrapped, so I am
> skeptical that this should be included this for general distribution.
> 
> 
> On Tue, May 31, 2011 at 12:57 PM,  <mtsolo@gmail.com> wrote:
>> Reviewers: ,
>> 
>> Message:
>> This patch'll be useful for some advanced tweaks I'm doing while running
>> LilyPond in multiple passes.  Lemme know if it looks all right.
>> 
> 
> 
> -- 
> Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen