Re: Staff.instr code change?

[Papazian Christophe]

thank you for all your answer !

I explain my patch, so anybody can help me to make it more acceptable.
When I try to patch lilypond, to make it sensitive to further changes
of Staff.instr, I see that the parser scan all the *.ly file, and then
compute then line breakings.
So I add a vector in lily/instrument-name-engraver.cc to keep each  
changes
of Staff.instr. I add three properties to each of this Spanner.
"first" (integer) is the bar number when the property is set.
"last" (integer) is the last bar number just before the property is  
replace by another /set Staff.instr...
"first" (bool) is a boolean to express if it is the first spanner of  
the staff (because it is possible that staff doesn't
begin to bar number one)

All those spanners are the send through lily/system-start-text.cc  
into the print function in reverse order.
So the first spanner that "comes" is the one to print (the last  
defined in this part), and I keep in tmp
its "first" property that can be compared to the "last" property of  
each spanner to know If I print them or not.
Obviously, If I can access to the currentBarNumber at this time, I  
would not need the tmp variable, but I didn't
find how to. The tmp could be name something like currentTimeInstr...  
and it is a property of the engraver.

If it was possible to give to each spanner a limited life, it would  
be simpler. I guess there is something easier to do.

Hope this help to give me some hints to upgrade this little patch to  
a better level.

        Christophe

On 13 juin 06, at 00:50, Johannes Schindelin wrote:

> Hi,
>
> On Mon, 12 Jun 2006, Papazian Christophe wrote:
>
> > For the tmp variable, I would be happy if I could find how
> > to make it linked to one engraver object (and not a global variable)
>
> I did not look into your patch, but I guess you could make it a  
> member --
> but then, the name has to become a little more descriptive.
>
> > I am sure you could reindent a couple a lines of new code ! :)
>
> And I am sure you can do it yourself!

right :)

> > Undeclared properties ?? Did you mean the new properties "last",  
> > "first", etc
> > ?
>
> I think Han-Wen was referring to the file scm/define-music- 
> properties.scm
> or one of its siblings. And you could make the name a bit more
> descriptive...
>
> Ciao,
> Dscho