Another note:
You can download my lilypond .ly generated file from here:
http://veltzer.github.io/openbook/static/openbook.ly
It is 28,000 lines long....:)
This is a real regression test for lilypond...:)
Maybe you can use it.
I have actually found that if I don't put page breaks between the tunes
lilypond will take forever to render this file.
So large files like this could be used to find performance issues with
lilypond.
Just a thought...
Cheers,
Mark
On Wed, Nov 5, 2014 at 9:39 PM, Mark Veltzer <[email protected]> wrote:
> A few notes:
> - I do have a \version statement but it is in one central place and not in
> every tune. The ideas is that I compile *all the tunes* as one huge file
> but maintain them as separate. I do not with to give the author of every
> single tune the ability to select his/her own lilypond version since they
> all must be compiled together to produce the final book.
> - Regarding guile-2.0 - I already have it in 14.10 which uses it. That's
> where it came from.
> - You are right that okular is a redundant dependency.
> - My site is down due to DNS issues. When it will be back up you would be
> able to see the rendered book. I'm attaching a sample.
> - I don't want to use real lilypond files because I want to enforce the
> same stucture on all tunes. This works out well since it means that every
> author has to write less lilypond code and gets macros to help with that.
> - if I had split and used includes in building the book each tune will
> have at least three files which will triple the amount of files I have and
> would have made it awkward to edit. Actually, since some tunes have 2 or 3
> versions one tune could take up to 9 files. That is a mess. The way I do it
> now is that each tune takes one file. The size of each tune is not great
> and manageable and the fact that it is one file is very convenient.
> - the templar project is in ubuntu launchpad. I need to link to it and
> make the installation easier. For my defense I can say it's on my TODO list.
>
> - you can now see the results of the project on:
>
> http://veltzer.github.io/openbook
>
> Cheers,
> Mark
>
> On Wed, Nov 5, 2014 at 12:39 PM, Mark Veltzer <[email protected]>
> wrote:
>
>> A few notes:
>> - I do have a \version statement but it is in one central place and not
>> in every tune. The ideas is that I compile *all the tunes* as one huge file
>> but maintain them as separate. I do not with to give the author of every
>> single tune the ability to select his/her own lilypond version since they
>> all must be compiled together to produce the final book.
>> - Regarding guile-2.0 - I already have it in 14.10 which uses it. That's
>> where it came from.
>> - You are right that okular is a redundant dependency.
>> - My site is down due to DNS issues. When it will be back up you would be
>> able to see the rendered book. I'm attaching a sample.
>> - I don't want to use real lilypond files because I want to enforce the
>> same stucture on all tunes. This works out well since it means that every
>> author has to write less lilypond code and gets macros to help with that.
>> - if I had split and used includes in building the book each tune will
>> have at least three files which will triple the amount of files I have and
>> would have made it awkward to edit. Actually, since some tunes have 2 or 3
>> versions one tune could take up to 9 files. That is a mess. The way I do it
>> now is that each tune takes one file. The size of each tune is not great
>> and manageable and the fact that it is one file is very convenient.
>>
>> On Wed, Nov 5, 2014 at 10:27 AM, Federico Bruni <[email protected]>
>> wrote:
>>
>>> Il giorno mer 5 nov 2014 alle 9:07, Federico Bruni <[email protected]>
>>> ha scritto:
>>>
>>> I would have put the music in a separate .ly file instead of putting it
>>> in the .mako files. I guess that any lilypond user would have done so, but
>>> I don't know how much it's difficult to use external files in your project
>>> (as Mutopia does, for example).
>>> However I would not contribute to this project unless it uses external
>>> files.
>>>
>>> The problem you are reporting can be fixed using sed, as already advised.
>>> However in the next future you should expect syntax changes. You are not
>>> using any \version statement in your snippets. This is a very bad practice,
>>> even if convert-ly can still update the syntax if you specify the version
>>> from which you want to update.
>>>
>>>
>>> Another problem with the missing \version statement is: how can the
>>> build know which version of lilypond should run? I have 3 different
>>> versions of lilypond on my system, each in a different location within the
>>> PATH. And the default one is the dev version, currently 2.19.x
>>>
>>>
>>>
>>
>
_______________________________________________
lilypond-user mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/lilypond-user
