denemo-devel
[Top][All Lists]
Advanced

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

Re: [Denemo-devel] Bookpart command


From: Andreas Schneider
Subject: Re: [Denemo-devel] Bookpart command
Date: Tue, 12 Jul 2016 20:52:32 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.1.0

Sorry that I took so long to answer. I was very busy.

Am 07.07.2016 um 18:37 schrieb Richard Shann:
> On Tue, 2016-07-05 at 21:19 +0200, Andreas Schneider wrote:
>> Am 05.07.2016 um 10:41 schrieb Richard Shann:
>>> On Sun, 2016-07-03 at 20:14 +0200, Andreas Schneider wrote:
>>>> Thank you for creating an advanced version of the command. In most cases
>>>> it works really well.
>>>>
>>>> There are a few small things I noticed:
>>>> * If you put the end at the same movement as the beginning it does not
>>>> work. (A chapter with only one movement may sometimes be needed.)
>>>
>>> If I understand correctly there is no need for this, you just leave that
>>> movement alone, giving it a title. It makes the single-movement book a
>>> bit irregular but was easier to deal with.
>>
>> For me, chapters group movements of a special type. Sometimes there may
>> be only one movement of a certain type.
> 
> Yes, that is the logical way to have things. Does the attached file give
> the desired output though? It has three chapters the middle one being of
> only one movement. Just done with Book Chapter, (and Score->Simple
> Titles->Title for the singleton chapter).

No, this is not my desired output because normally each movement has a
title. At the start of a chapter there is first the chapter title
(preferably in a larger font) and then the movement title.

>>  For the first movement in a
>> chapter there is first the heading of the chapter and then the heading
>> of the movement, regardless if the given chapter contains one or more
>> movement(s).
>> I am thinking about how one can overcome the restriction that a chapter
>> cannot end at the same movement where it starts.
>>  First of all, your
>> solution is clever because it does not need a reference (e.g. to the
>> movement number where the end is) that may void if movements are
>> inserted or deleted, and because it automatically prevents starting a
>> chapter where a chapter end is already present. At the moment you cannot
>> begin and end a chapter at the same movement because you use the same
>> tag for both begin and end.
> 
> Well, no actually you *can* have begin and end on the same movement -
> you could have a single Denemo Directive with the tag SimpleChapter but
> with both prefix and postfix fields filled in for the end and start of
> chapter respectively. You could test for this case (you get #f for a
> field that isn't filled in) and write the script to handle that.

Your idea is more elegant than mine. So this should be the way to go.

>>  When using a different tag, that restriction
>> would not be present any longer. Is there a directive to get the number
>> of movements in a score?
> I don't think so - it is (d-PushPosition)(while (d-NextMovement))(set!
> number-of-movements (d-GetMovement))(d-PopPosition).
>>  Maybe I can come up with some code. Or do you
>> think that approach is not wise?
> 
> The advantage of using a single tag is that it can be (and is in this
> case) the name of the command, and so the user can re-run the command in
> the Movement Properties Editor. Directives that have a tag that isn't a
> command name are more difficult for the user to work with - Denemo
> doesn't know what command created them and can't give any guidance about
> them. There *is* a mechanism to mitigate this - you can write an
> "editscript" named after the tag and put that in the actions/editscripts
> directory, but I think that is over elaborate.

I see, I did not think of that.

>>>> * If you give an end movement number that is larger than the number of
>>>> movements and thus does not exist, the script does an infinite loop. In
>>>> that case the end movement should be set to the last present movement
>>>> and a warning be given.
>>>
>>> I've fixed this.
>>>
>>>> * If you give an end movement that is before the start movement, the
>>>> lilypond code is erroneous. That should be checked and an error message
>>>> given.  For example before line 32: (if (< end (d-GetMovement))
>>>> (d-InfoDialog "Chapter end cannot be before chapter start!") (begin ... ))
>>>
>>> that fix also prevents bad code generation in this case
>>
>> I suggest to give a message to the user in this case, e.g. by inserting
>> (d-WarningDialog (string-append (_ "Invalid movement number: ") end ))
>> as else branch of the (if ...) starting in line 28.
>>
>>>> * The end movement cannot be changed. (This becomes important if one
>>>> insert a movement at the end of a chapter.) If you click on EndChapter,
>>>> you just get an information dialog. It would be more convenient be told
>>>> the movement number where the corresponding start is and given the
>>>> option to move the EndChapter to another movement. Workaround is to
>>>> delete and re-insert.
>>>
>>> Hmm, it seems you have to delete the start as well as the end and the
>>> re-instate.
> 
> actually, there should be a cleverer way - you make a button that will
> create a clone of the End Chapter, then delete that End Chapter, move to
> the movement where you want the end to go and use the button to
> reinstate the End Chapter in the new position.

That sounds like a good possibility. However, it also sounds like a lot
of work for which I don't have the time right now.

Andreas




reply via email to

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