lilypond-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Iterators in Scheme?


From: David Kastrup
Subject: Re: Iterators in Scheme?
Date: Wed, 29 Jul 2020 15:58:57 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)

Niols <niols@niols.fr> writes:

> Hi David,
>
> On 29/07/2020 15:16, David Kastrup wrote:
>> Niols <niols@niols.fr> writes:
>>> Must I understand that it is not possible to write iterators in Scheme
>>> and that they have to be written in C++?
>> Yes.
>
> Thank you; at least I stop wondering about that.
>
>>> Must I then understand that, if I wanted to write iterators for a
>>> personal use, I would have to recompile LilyPond myself?
>> Yes, or reuse one of the existing ones.  Some are comparatively
>> generic.
>
> I would love that as it would allow to only have to write some
> Scheme. But I am not sure this can be achieved. See below.
>
>> What do you want to achieve?
>
> This is actually follow-up research from my side after a previous
> e-mail to this list. I would like to print bar numbers that are
> "repeat aware", that is such that if bars 9 to 12 repeat twice, then
> the bar numbers go
>
>     1, 2, …, 9, …, 12, 17, 18, etc.
>
> with a jump after 12 that corresponds to the bars 13 to 16 that are
> actually 9 to 12. Even better, I would like to print the two bar
> numbers for these bars (9/13, 10/14, etc.)
>
> I have tried hacking around the current bar number with an engraver
> that would recognize repeat commands, putting the current bar number
> in a stack whenever reaching a "start-repeat" and popping it when
> reaching an "end-repeat". This works, but:
>
> - does not seem very clean,
>
> - does not allow to write several bar numbers because we can't know
>   yet how long the repeat is going to be,

Markup expressions are converted into stencils at a comparatively late
point of time.

> - does not recognize repeats that are for more than twice.
>
> From what I understand, however, there are two passes: first the
> iteration and then the engraving.

No, that's wrong.  It's just a single pass.  Iterators are strongly tied
to the sequence of music expressions in the source code (and only
persist while such an expression is being interpreted) while engravers
are tied to contexts and persist as long as the respective context
lives.  Iterators are driven by the music expressions and the advancing
time while engravers are driven by stream events announced in contexts.

But there is no separate pass involved.

> For the problem of repeats, I read the code of the
> Volta_repeat_iterator. In particular, it seems to read the 
> "repeat-count" property:
>
>     rep_count_ = scm_to_int (get_property (get_music (), "repeat-count"));
>
> but only uses it to detect the "first time" and the other times. The
> first time:
>
>     if (first_time_)
>       {
>         add_repeat_command (ly_symbol2scm ("start-repeat"));
>         first_time_ = false;
>       }
>
> it adds a "start-repeat" command. As far as I understand, that means
> that the engraving then only gets the repeat commands, which is
> actually not enough information for what I am trying to achieve.
>
> I am really motivated to read code and do my own research and write my
> own Scheme code, but I do not really know where to look and if I 
> understood stuff correctly. If you had any pointer to understand more
> (or better) about what I understood, and to achieve this in the end, I 
> would be very grateful.
>
> In any case, I am already very grateful for the time you took to read
> my message/s and answer me. Sorry for the long text.

I thought we had several options for bar numbering in connection with
repeats but don't know about the details.  There may be a more
specialised solution for your use case.

Then there also is the recording-group-emulate function which you can
use for causing a complete pass of iteration just for event gathering
purposes.  It might be feasible to use that for collecting repeat count
information in advance.

-- 
David Kastrup



reply via email to

[Prev in Thread] Current Thread [Next in Thread]