Aaron Hill writes:
>>> => David K., do you know why the parser balks at such a top-level
>>> ly:book?
>
>> How can a book be distinguished from a bookpart?
>
> Are they both ly:book? behind the scenes? If so, I can see the problem.
>
>
>> Without an answer to
>> that question, we cannot implemen
=> David K., do you know why the parser balks at such a top-level
ly:book?
How can a book be distinguished from a bookpart?
Are they both ly:book? behind the scenes? If so, I can see the problem.
Without an answer to
that question, we cannot implement this. But have you tried explicitly
Aaron Hill writes:
> On 2020-03-08 3:57 pm, Stephan Schöll wrote:
>> It looks as if the "output" (return value) of a function can only be of
>> type "music", not "score", "book" aso, which would disappoint me. Am I
>> right? Or is there a way to define/change the type of the return value?
>
> Mus
On 2020-03-08 3:57 pm, Stephan Schöll wrote:
It looks as if the "output" (return value) of a function can only be of
type "music", not "score", "book" aso, which would disappoint me. Am I
right? Or is there a way to define/change the type of the return value?
Music functions are for music. Boo
To be precise: It's not the looping through voices which is primarly on
my mind, but rather the deduplication of code when generating scores for
each instrument.
Regards
Steff
Am 08.03.2020 um 23:57 schrieb Stephan Schöll:
> Hi all
>
> When working with larger scores / several voices/instruments,
Hi all
When working with larger scores / several voices/instruments, I would
like to "loop through every single instrument" to produce the
\book-blocks in order to avoid duplicate lilypond code.
Let's take the following MVE:
--- MVE START ---
\version "2.19.83"
notesI = \relative c' {
c4 d e
