[prev in list] [next in list] [prev in thread] [next in thread] 

List:       lilypond-devel
Subject:    Re: Auto_change_iterator no longer creates staff contexts itself. They are created in scheme. (issue
From:       thomasmorley65 () gmail ! com
Date:       2015-06-29 8:54:18
Message-ID: 089e0158aa622bfa630519a43c92 () google ! com
[Download RAW message or body]

On 2015/06/28 12:30:21, Dan Eble wrote:
> On 2015/06/28 11:17:58, thomasmorley651 wrote:
> >
> > Let me clearify, I don't insist in keeping those properties, though
I'd like
> to
> > keep the possibility to simply write \autochange { ... } _and_ to
have the
> > possibility to set the clefs in both staves.

> What do you think about putting that enhancement into a ticket of its
own?  My
> only motivation to touch \autochange is to remove what I see as
unnecessary
> duplication in the innards of \partcombine and \autochange.

Ok with me, if it speeds up your work on /partcombine.
I did a search in the user-archives for bassStaffProperties and
trebleStaffProperties, result: zero.
So it will do no real harm, undocumented features tend to be effectively
non-existent.

More, I'd offer to create an issue and provide a patch for it. I've
already a sketch of a working patch locally. Though, it needs to touch
autochange.scm as well. Regarding your other patches affecting
autochange.scm I'd like to postpone it, until they are though.

> > The NR shows an example for \autochange { ... } and I think the
> > treble/bassStaffProperties were meant to set the clefs.

> Maybe, but the split point is hard-coded to middle C, isn't it?  So
that makes
> it a little weird with other clefs.  (Of course that could be fixed as
well.)

Ofcourse that should be fixed then!



https://codereview.appspot.com/249970043/

_______________________________________________
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-devel
[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic