On 2015/10/04 13:53:05, Dan Eble wrote:
On 2015/10/03 12:56:50, dak wrote:
> On 2015/10/03 12:42:19, Dan Eble wrote:
> > I've marked the ticket as "needs work" for now. I still have
questions. It
> > *would* be nice to be able to say
> >
> >\override Staff.partCombineParameter = #x
> >
On 2015/10/03 12:56:50, dak wrote:
On 2015/10/03 12:42:19, Dan Eble wrote:
> I've marked the ticket as "needs work" for now. I still have
questions. It
> *would* be nice to be able to say
>
>\override Staff.partCombineParameter = #x
>\partcombine \one \two ...
>
> and have the part co
On 2015/10/03 12:42:19, Dan Eble wrote:
I've marked the ticket as "needs work" for now. I still have
questions. It
*would* be nice to be able to say
\override Staff.partCombineParameter = #x
\partcombine \one \two ...
and have the part combiner get its initial settings from the
I've marked the ticket as "needs work" for now. I still have questions.
It *would* be nice to be able to say
\override Staff.partCombineParameter = #x
\partcombine \one \two ...
and have the part combiner get its initial settings from the context.
The current implementation runs the comb
On 2015/10/01 22:07:28, Dan Eble wrote:
On 2015/10/01 08:33:11, dak wrote:
> into the user interface as well as extending the code. Let's assume
that we
> make chord extent changeable on the fly via setting a context
property. How
> would you implement that using your part combiner structur
On 2015/10/01 08:33:11, dak wrote:
into the user interface as well as extending the code. Let's assume
that we
make chord extent changeable on the fly via setting a context
property. How
would you implement that using your part combiner structure?
Then I would remove it from the structure
On 2015/09/30 20:50:55, Dan Eble wrote:
On 2015/09/30 12:58:38, dak wrote:
> I don't think that externally we have much to gain from
> having it fall apart into different implementations rather than
using
different
> parameters for driving a single partcombiner.
I'm not sure I understand you
On 2015/09/30 12:58:38, dak wrote:
I don't think that externally we have much to gain from
having it fall apart into different implementations rather than using
different
parameters for driving a single partcombiner.
I'm not sure I understand you clearly. Which one of these describes
this pa
On 2015/09/30 12:18:07, Dan Eble wrote:
On 2015/09/30 11:23:11, dak wrote:
>
> I don't see where you want to be going with this patch. What is it
supposed
to
> make easier for the programmer or the user?
Well, for the typical user, nothing. For people like me, it reduces
the amount
of in
On 2015/09/30 11:23:11, dak wrote:
I don't see where you want to be going with this patch. What is it
supposed to
make easier for the programmer or the user?
Well, for the typical user, nothing. For people like me, it reduces the
amount of internal Lilypond code that must be duplicated to
On 2015/09/26 13:39:55, Dan Eble wrote:
restore \partcombine interface
What is the problem you are trying to solve here? I've just resurrected
issue 4131 since it's now (as of issue 4609) possible to tell \set and
\once \set apart reliably and thus work with context properties.
Context mods ar
https://codereview.appspot.com/265260043/diff/1/ly/music-functions-init.ly
File ly/music-functions-init.ly (left):
https://codereview.appspot.com/265260043/diff/1/ly/music-functions-init.ly#oldcode1265
ly/music-functions-init.ly:1265: #(define-music-function (chord-range
part1 part2)
No, just no
Reviewers: ,
Description:
collects in one place the options for routing parts to
Voice contexts and generating marks.
\partcombine, \partcombineUp, and \partcombineDown accept an optional
in place of an optional chord range, though this is
not yet documented.
This makes customization signific
13 matches
Mail list logo
