"N. Andrew Walsh" writes:
> Hi David,
>
> On Fri, Jan 11, 2019 at 5:58 PM David Kastrup wrote:
>
>>
>> Just put the whole path in "double quote marks".
>>
>
> thanks. OK, now I must confess I don't really know what was going wrong
> exactly, but I resolved the error.
You cannot "resolve" this
Hi David,
On Fri, Jan 11, 2019 at 5:58 PM David Kastrup wrote:
>
> Just put the whole path in "double quote marks".
>
thanks. OK, now I must confess I don't really know what was going wrong
exactly, but I resolved the error.
My main file had a bunch of variables defining each instrument, and
"N. Andrew Walsh" writes:
D> On Fri, Jan 11, 2019 at 5:21 PM David Kastrup wrote:
>
>>
>> You have to start gdb with the name of your LilyPond executable.
>>
>> --
>> David Kastrup
>>
> Ugh, OK, now it's getting confusing.
>
> Since gdb can't handle whitespaces in the path,
Just put the whole
On Fri, Jan 11, 2019 at 5:21 PM David Kastrup wrote:
>
> You have to start gdb with the name of your LilyPond executable.
>
> --
> David Kastrup
>
Ugh, OK, now it's getting confusing.
Since gdb can't handle whitespaces in the path, I copied the whole project
directory into a new folder, and
"N. Andrew Walsh" writes:
> On Fri, Jan 11, 2019 at 4:36 PM David Kastrup wrote:
>
>>
>> I cannot really find the location where this error would get triggered,
>> so indeed a backtrace in gdb would be helpful.
>>
>>
> When I get to the (gdb) prompt, I try this:
> (gdb) run /[PATH]/plus-minus\
On Fri, Jan 11, 2019 at 4:36 PM David Kastrup wrote:
>
> I cannot really find the location where this error would get triggered,
> so indeed a backtrace in gdb would be helpful.
>
>
When I get to the (gdb) prompt, I try this:
(gdb) run /[PATH]/plus-minus\ example\ 1.ly -file
Starting program:
"N. Andrew Walsh" writes:
> Hi David,
>
> On Fri, Jan 11, 2019 at 4:06 PM David Kastrup wrote:
>
>> With the given example, I get no problem with either one or both of
>> those changes.
>>
>> How about actually posting the full error message?
>>
>
> Like I said: it works fine on its own; but
Hi David,
On Fri, Jan 11, 2019 at 4:06 PM David Kastrup wrote:
> With the given example, I get no problem with either one or both of
> those changes.
>
> How about actually posting the full error message?
>
Like I said: it works fine on its own; but within a larger orchestral
piece, under
"N. Andrew Walsh" writes:
> I have the following code:
>
> \version "2.19.82"
>
> \relative c' {
> \clef alto
> \override Score.Stem.stemlet-length = #0.75
> deh,2\f~ deh
>
> | %2
> deh2
> %\once \override Beam.positions = #'(2.5 . 1.5)
> c'16\rest[ deh,8.]
>
> }
>
> That compiles fine on
I have the following code:
\version "2.19.82"
\relative c' {
\clef alto
\override Score.Stem.stemlet-length = #0.75
deh,2\f~ deh
| %2
deh2
%\once \override Beam.positions = #'(2.5 . 1.5)
c'16\rest[ deh,8.]
}
That compiles fine on its own. However, in the context of a full orchestra
10 matches
Mail list logo