While pondering how an “nth time only” feature might work, I considered what it
might take to generalize the way the Mark engraver handles updating the
rehearsal mark number and make it expressible in ly code instead.
I have a working prototype that uses all the following features and I’m lookin
2018-04-22 19:13 GMT+02:00 Torsten Hämmerle :
> dak wrote
>> Well, yeah. (* (/ ... h_inf) h_inf) does not make a whole lot of sense
>> either way.
>
> @Harm
>
> Function F0_1(w) basically is supposed to return 0 for w = 0 and
> asymptotically approach a limit of 1 as w grows wider.
> Because atan
After looking into this further, it appears that I need to modify
the implementation of the Book C++ class to include a
print_smob() method if I want to see its contents.
Kim
___
lilypond-devel mailing list
lilypond-devel@gnu.org
https://lists.gnu.org/
In my ongoing exploration of lilypond internals, i am looking
at printing out the value of the argument being passed to
toplevel-book-handler, defined in ly/declarations-init.ly.
I have tried a few different functions such as
(display-scheme-music book port)
or
(pretty-print book port)
dak wrote
> Well, yeah. (* (/ ... h_inf) h_inf) does not make a whole lot of sense
> either way.
@Harm
Function F0_1(w) basically is supposed to return 0 for w = 0 and
asymptotically approach a limit of 1 as w grows wider.
Because atan(x) -> π/2 (i.e. 90°) as x -> infinity, the result is multip
Thomas Morley writes:
> Hi,
>
> with
> https://sourceforge.net/p/testlilyissues/issues/3088/
> I implemented \undertie markup based on Jan's proposal.
>
> I now wanted to use make-tie-stencil for other stuff and noticed some
> problems.
>
> (1)
> The local binding of slur-height, based on Jan's:
Hi,
with
https://sourceforge.net/p/testlilyissues/issues/3088/
I implemented \undertie markup based on Jan's proposal.
I now wanted to use make-tie-stencil for other stuff and noticed some problems.
(1)
The local binding of slur-height, based on Jan's:
%% FIXME: c&p from bezier-bow.cc
#(define
On 2018/04/22 13:56:01, Dan Eble wrote:
On 2018/04/22 13:37:50, dak wrote:
> So again I don't see what problem you are trying to solve.
1. find_something(...)->blahblah()
I have no idea whether that will call blahblah() with a valid instance
of
something.
C++ does not allow "this" to be 0,
On 2018/04/22 13:37:50, dak wrote:
So again I don't see what problem you are trying to solve.
1. find_something(...)->blahblah()
I have no idea whether that will call blahblah() with a valid instance
of something.
2. find_something(...).blahblah()
I know will call blahblah() with a valid insta
https://codereview.appspot.com/341150043/diff/1/lily/context.cc
File lily/context.cc (right):
https://codereview.appspot.com/341150043/diff/1/lily/context.cc#newcode723
lily/context.cc:723: find_top_context (Context &where)
On 2018/04/22 13:19:45, Dan Eble wrote:
On 2018/04/21 20:58:32, dak wro
On 2018/04/22 13:19:46, Dan Eble wrote:
of calls in some scope: if (Context *c = find_whatever(...)) { a(*p);
b(*p);
c(*p); }.
of course I meant *c for *p
https://codereview.appspot.com/341150043/
___
lilypond-devel mailing list
lilypond-devel@gnu
https://codereview.appspot.com/341150043/diff/1/lily/context.cc
File lily/context.cc (right):
https://codereview.appspot.com/341150043/diff/1/lily/context.cc#newcode723
lily/context.cc:723: find_top_context (Context &where)
On 2018/04/21 20:58:32, dak wrote:
And it was simpler to understand and
On 2018/04/22 01:18:22, Carl wrote:
It seems like if there is a problem that this solves, there should be
a
regression test that shows the problem and hence why this patch is
needed.
The problems this solves are semantic. I should have classified this as
"maintainability" in the ticket; that
13 matches
Mail list logo
