Re: Guide to Writing Orchestral Scores with Lilypond?????

[Urs Liska]

Am 09.01.2013 04:29, schrieb Antonio Gervasoni:

Wow! I didn't expect all this enthusiasm and eagerness to collaborate.......
at least no so fast!

Well, the risk may be that it is a case of immediate enthusiasm which might fade away when there aren't immediate results ;-)

Ben wrote:

That's very kind of you to offer your own personal documentation on how
you grasped LilyPond 
and its power.  I'm sure that if you put together a PDF guide and uploaded
it somewhere 
(Dropbox, your site, etc) and posted the link here in the mailing list,
many would be 
grateful and appreciative. 

I always thought it was the least I could do, since I have been able to
create this score only because others decided to do the same thing!

That's what Open Source is for ...

Urs wrote:

This is a _very_ good idea, and I would be pleased to get you 'into 
my boat'.

Count me in!!! Please!!! I took a look at your site and the first thing that
came to my mind was "why haven't I seen this website before???" I agree with
everything you say in the introduction. I experienced the same things.

You haven't seen it before because it probably isn't really findable.
I didn't take care of this so far because it is just one single tutorial - which may be valuable in itself, but doesn't make an impressive web appearance.
If we could collect a certain number of items (with the potential to grow) it should be possible to create a more prominent presentation and then also to take care of making it more known.

...

During the development of a musical edition some others and me created
the base 
for a kind of LilyPond toolkit library. When the edition is finished 
we'll change that to be an open source project hosted on Github. This 
will consist of sets of functionality, templates and examples which 
of course have to be well documented.
The 'includable' library can and is intended to be 
accompanied by more or less standalone essays (like how to set up 
projects to be variable, how to deal with complicated transpositions, 
how to change the overall visual appearance of scores etc.)

Amazing! Again, count me in!

I will try to give a few more hints on what this library could become, although it's actually untimely now.
I intended to 'refactor' the present material into a reasonably generic basis after the current project is finished and then look for collaborators. But as we are right now discussing it I think I have to put it up for discussion, so we can see if it is a good starting point for a collaborative effort.

The 'library' consists of several - partly independent - concepts:

a) 'Toolboxes'
These are grouped collections of functions and shorthands. It is in a sense similar to the LSR, but has a few important differences:

• Items in these toolboxes are selected to be somewhat consistent with the library
• The library provides a consistent interface to the available functionality:
  One includes the library (or a single toolkit) and then can directly use the functions.
• The library is consistently documented (reference and introductory material).
  Well it isn't ATM. But I will make sure that only documented material will be added to the library (that means, when I move the items from our current project directory to the 'openLilyLib' folder I will only add a second item when a first item is documented).

To give you an idea I'll enumrate some of the functionality we have ATM:

• All kind of shorthands for common tasks (simple things like changing a (piano) Staff and switching Voice context with one short command)
• Shorthands for common tweaks (e.g. padding articulations, shifting lyrics or notes etc.)
• An 'editorial toolbox' with two kinds of items:
  - shortcuts to mark editorial additions (e.g. dashed slurs, smaller fonts or parentheses)
  - functions to use in the editorial process. These produce warnings in the console output and/or color the output
• A 'curves toolbox' with functions like visualizing the control points of bezier curves or tools for creating cross-voice curves.
  The best function which had been retouched during our project has in the meantime found its way to core LilyPond under the name of \shape :-)
• Engravers
• The introduction and implementation of a 'draft mode' concept:
  If you include the library and then the 'draft mode', then most of the tweaks that can be applied through the library - and the items affected by the editorial toolbox are colorized.
  This is very handy during the editing process: You immediately see what you tweaked manually, and you are visually directed to the Grobs that have been commented on by other contributors.
  The highlighting does not affect the layout at all, so you can simply comment out the draft mode include to have the final printable score.
  

b) Includes/examples/templates
This can be style sheets or snippets that can be used as modules.
For example I have a modular style sheet for songs that has modules for page layout, font selection and size adjustments.
The page layout takes care of staff size and other sizes (e.g. line thicknesses) I want for songs.
The font selection file sets all kinds of grobs to a specific font (I don't simply make a font tree because I want detailed control over the selection of font faces).
This makes sense because I mainly typeset songs. But if I wanted to write a score for two pianos eight hands (which will actually be the next thing) I would create a new page layout file, use the existing font selection file and see if I have to adjust sizes differently.
With such a design it is quite simple to create a set of different style sheets for different uses. If I create a new font selection file I can still use my page layout file.

c) '(best) practices'
This is basically the same as b) but from a more instructional perspective. It consists of sets of related files that can be used to set up efficient and modular constructions (what we had to use are set-ups to maintain scores of songs in original and transposed keys in parallel). The crucial point here is documentation - which so far mostly lives in our private email archive. But as I said - this has to change when everything moves to its public place.

[d) lilyDoc
This is an idea that I have but that will have to wait for some time (until I will have the time for it and until my Python skills are good enough (I know these are two high stakes ;-) )).
I want to develop a tool that parses a LilyPond file (or crawls through the tree of included files) and creates a documentation for it (from variable declarations and special comments) - just like exists for many programming languages.
But this should be coordinated with contributions I hope to make to Frescobaldi one day (because there is _much_ common functionality): I would like to use the same parsing mechanism to enhance Frescobaldi's code completion (and maybe to provide on-the-fly documentation of the current project)
]

I think that the contributions we are talking about right now (tutorial and material for orchestral scores for example) could very well be included in c)
Question would be the form and the place (see below).

Wim wrote:

Not replacing the learning manual 
but as an addition with e.g. an orchestral example build in stages 
(with all the intermediate files available for who is interested to 
follow the process in detail.

Precisely! The Learning Manual is already a great source of information but
it needs to be complemented with 'productivity tools' and '(best) practice
strategies', as Urs pointed out.

Yes. I think the Learning Manual is excellent. The Notation Reference is basically excellent too, but for beginners it is still quite difficult to get over the step to creating somewhat complex scores. Exactly this target group (typesetters who are willing to learn text based input and have found out how to use LilyPond, but have problems to get a deeper understanding) could be addressed by more tutorials. Such tutorials don't have to be 'references' and have therefore more freedom in their form (how detailed do I want to explain an issue? How many examples do I use? How much space do I use for 'background' information? etc.).
I think if we had more documents on this level it could well keep typesetters from giving up and switching back to their former WYSIWYG software.

The only drawback I can think of now (for 
this "Guide") would be that it might be better to start with a smaller 
example first (e.g. a guide to write a SATB piece or smaller lead 
sheet). To get the process right before drowning in a large example.

I think that might be a much bigger project than the one I had in mind! My
intention was just to document my process of creating an orchestral score. I
agree that a guide that starts from more simple examples and builds itself
up to the most complex ones would be an awesome document but then we would
need a lot of people contributing to this effort, documenting their
experiences writing different types of scores. It could be done though, and
I'm definitely in if it gets to that point but for now I'm just thinking
about orchestral scores.

IMHO it isn't advisable to directly tackle a 'definitve and exhaustive' guide. This _is_ a huge project and probably would get stuck before we'd get any single result.
I would suggest to see it as a growing collection of individual documents. Any single new text that is available publicly is an improvement, so we should encourage anybody to contribute, be it a 30 page essay on orchestral scores or a one page hint on a practice to transpose harmonically complex scores.
It would be nonsense if Antonio would _not_ write his proposed text, just because it is too complicated as the 'beginning of a book' ...

I've written documentation texts for years, so I think I can 
probably fit in. But most of all I can't guarantee the speed.

I think nobody can! We should think about a frame where any contribution can be made at any time (see my above comment).

So what could be a good place for such a project?
My 'natural' choice would be the (already existing, but essentially empty) Github repository (https://github.com/lilyglyphs/openLilyLib).

Advantages seem to be:

• The Git/Github approach is really good for collaborative work.
• It would make sense to tightly integrate tutorial documents with a LilyPond library, especially when there are examples and usable snippets involved.

Drawbacks I can think of:

• Git(hub) isn't really intended to deal with binary files, so it wouldn't be 'natural' to include contributions in form of finished pdf files. Ideally one should have all texts as LaTeX documents in order to
  - profit from Git's versioning and
  - be able to compile the texts consistently to different forms (individual pdf, compiled 'volume' etc.)
  But I'm afraid this would be a restriction that prevents many from contributing.
• I don't have any experience yet with Github's Wiki pages.
  Would they be suited well to create a public 'frontend' to the project?

Any opinions?

Awesome! I have absolutely no knowledge on that and also one of the things I
have been worried about, when thinking about documenting my process, is that
my use of the English language is far from being the one needed to write
such a document (being that my native language is Spanish)

No need to worry. A document in non-perfect English (and I don't see any problem when reading your emails ...) is far better than no document. And if we'd go for the Git approach it would be easy for someone else to just make a few improvements here and there ...

And most important: Am I welcome on this adventure?

>From my part, by all means! Up till know I was just thinking about writing
the document myself and uploading all the files. Now, looking at the
possibility of a collaborative effort I am absolutely thrilled!

At this point I think it might be good to give everyone reading this thread
an idea of what I meant with my first post. I just put in my Dropbox the
full score I've been working on for the past months. It is not complete yet!
I still have to typeset the parts of the second violins, violas, cellos and
double basses but you can get an idea of what I was referring to when I said
it is a very complex score. Here's the link:
https://dl.dropbox.com/u/4857747/Icarus%20Jan-08-2013.pdf

Very nice!
It's a perfect example of the aesthetic credo mentioned on the first page of the introduction on lilypond.org.
Of course I'm always impressed when seeing a LilyPond score. But the deepest impact is always when I have the music on the music stand and have to play from it. There you really can _feel_ the difference.


Finally, I hope we can take up and keep the impetus this discussion has created ...

Best
Urs

Finally, I have only used Lilypond for over a year and I am not a programmer
nor do I have any knowledge of Scheme. I majored from a computing science
career called Systems Engineering, but that was a long time ago. I then
majored in Music Composition at the National Conservatory Music (in Peru, my
country) and have dedicated myself to composition ever since. Therefore, I
can only offer what I have learned in the very brief time I've been using
Lilypond as well as the experience and knowledge acquired in the practice of
my profession. I hope this suffices!

Regards,

Antonio




--
View this message in context: http://lilypond.1069038.n5.nabble.com/Guide-to-Writing-Orchestral-Scores-with-Lilypond-tp139065p139090.html
Sent from the User mailing list archive at Nabble.com.

_______________________________________________
lilypond-user mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/lilypond-user