Re: New attempt on tuplets/percent repeats

[Han-Wen Nienhuys]

Erik Sandberg schreef:
> > > Highlights:
> > > - tuplets are now signalled by start/stop events.
> >
> > This patch looks almost ready for inclusion. Can you address my
> > tuplet-event nit, verify that a clean make web still work, and commit?
> >
> > The tuplet-engraver looks good, but I would still like the events to be
> > generated in the Tuplet_iterator (which you may rename from
> > time-scaled-music-iterator), so the music representation is analogous to
> > the
> >
> >   \times 2/3
> >
> > syntax.
>
> ok, that's fine. Perhaps the music compression should be performed by
> the iterator as well?

I've been toying with that idea for a long time, but I haven't been able 
to work out how we could do that easily and cleanly.

> > Keeping the music representation and syntax as closely related as
> > possible makes things easier, both for me (understanding the whole
> > thing), Nicolas (maintaining display-music) and you (when you want to
> > separate the parser and tree generation).
> >
> > In general, I think it makes sense to move parser substitutions as much
> > as possible to the iterators, eg. at some point, we should also change
> > the implementation of mmrests, \clef and \time.
>
> Is there a long-term plan to make iterators softcodable? The main
> thing I dislike about moving stuff to iterators is that it moves code
> to C++, so if someone wants to do a nonstandard tweak of
> time_scaled_music_iterator, he has to recompile lily locally.

No plans, but I understand your concern. However, I haven't seen 
instances that need SCM-written iterators. Let's wait for situations 
where that is necessary before we start changing things. FWIW, there is 
a lot in the parser that is softcodable (eg. the meaning of articulation 
scripts, the \bar command etc), but nobody ever uses that functionality.

> BTW, what's your position on copyrights/licensing? I've added my name
> to files which I feel I have modified massively, do you have
> objections to that? 

No, go ahead. Remember to update AUTHORS.texi too.

> (I'm ready to relicense any code I write to lgpl
> or gpl>=3 if that's needed in the future)

I have toyed with the idea of getting disclaimers from all contributors, 
but haven't actually gone through with the idea. Regarding GPLv3 vs GPL 
vs LGPL, let's wait before the v3 storm settles down before changing 
licensing terms.

Also, we might consider removing the names from copyright headers 
completely - as it puts ownership stamps on files, which not desirable 
from a engineering perspective. Perhaps it would be better to have a 
separate legal entity  to carry the copyrights.

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

LilyPond Software Design
 -- Code for Music Notation
http://www.lilypond-design.com