lilypond-user
[Top][All Lists]
Advanced

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

Re: LilyPond learning curve (was: feasibilty question: simple GUI for we


From: Martín Rincón Botero
Subject: Re: LilyPond learning curve (was: feasibilty question: simple GUI for web-based Lilypond instance)
Date: Sun, 25 Oct 2020 17:05:48 +0100

The price you pay is that an LP score is considerably more time-consuming to enter

I feel there are at least two factors that create this situation: the lack of graphical interface limits the amount of selection tools (you can basically select what your cursor can select). With more selection tools that allowed the user to easily copy, paste, cut, insert, attach articulations to all staves, etc., entering notes in Lilypond would be way faster. Since I started using Python to help me create Lilypond files, I can have whatever amount of lists I want (for example one called "tutti") and use programmatic commands to affect all staves. F. ex.

for staff in tutti:
add_music(staff, "c4. d8 e4 f |")

Where "tutti" is a list, e.g. tutti = [flute, violin, cello] and add_music is a function I programmed to add more music to the end of the staff (amongst other I programmed, like copy_bar, insert_bar, etc.).

The other aspect that makes working with Lilypond unnecessarily slow is the fact that invoking the Lilypond command always processes the whole score over and over again from scratch. Telling the user that their scores are gonna take more time to compile every time they enter more music doesn't sound attractive nor efficient. The alternative, only working on the text file from beginning to end with no visual feedback to then proceed to "debug" such file after compiling is not a realistic alternative for the majority of users. In my Python script I'm using subprocesses in conjunction with OLL's partial compilation that let me make pdfs page by page (using pdftk), so that I can only update the page I'm working on without losing the rest of the pages.

These are the kinds of things I believe we could improve upon more easily and quickly (or at least with more obvious incentive?!) if the user base was larger. And — like it or not — a real critical mass like that will require a GUI.

All of this, although it has made my work with Lilypond many times more efficient, takes the user further away from a more attractive paradigm like a GUI.

Am So., 25. Okt. 2020 um 16:18 Uhr schrieb Kieren MacMillan <kieren_macmillan@sympatico.ca>:
Hi Marc,

> I tried LP several years ago and quickly gave up. I decided to try it again because I was frustrated with all of the manual adjustments my Finale scores require, and wanted to see if LP could do better.

I used Finale from v1 [!!] in 1988 to Finale 2000. I gave up at that point — too many frustrations!! — and started looking for an alternative.

> The price you pay is that an LP score is considerably more time-consuming to enter. Although I expect to get better at it over time, I don’t think that disadvantage can ever go away entirely.

With Frescobaldi — especially the MIDI keyboard input — I believe I can now enter music faster than I ever could in Finale (and I was *very* fast). If the music doesn’t repeat at all, I’d say I am 5%-10% faster than I was at my Finale peak; when I can reuse material (which is VERY often, in the types of music I engrave), that percentage goes up.

Of course, the real savings comes (as you imply) once the data is in: my tweaking time is ~5% TOTAL of what I used to put in with Finale (and what I still see my colleagues and friends putting in with Fin/Sib/etc., though Dorico is much better).

> I am typesetting an opera score, which is clearly not the easiest place to start—but that is what I do. I am guessing that whoever designed LP was not thinking of orchestral scores

Agreed. As a composer of operas, musicals, orchestra pieces, and other large-forces works, I feel your pain!  =)

> some things that ought to be easy (the “MarkLine” concept) are in fact quite difficult.

These are the kinds of things I believe we could improve upon more easily and quickly (or at least with more obvious incentive?!) if the user base was larger. And — like it or not — a real critical mass like that will require a GUI.

Cheers,
Kieren.
________________________________

Kieren MacMillan, composer (he/him/his)
‣ website: www.kierenmacmillan.info
‣ email: kieren@kierenmacmillan.info




--
www.martinrinconbotero.com

reply via email to

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