Re: Discussion: automatic engraving and single-source publishing

[Janek Warchoł]

Hi,

2013/11/27 Noeck noeck.marb...@gmx.de:
 Hi

 Just a quick but honest thank you from my side to all of you for
 improving the out-of-the-box quality, tweaking-possibilities (e.g.
 \shape) and simplifications for users (e.g. the.dot.syntax instead of #')!

You're welcome!  And i join the acknowledgements for the stuff that
was contributed by others :-)

 I think, the blog posts show that there is still room for improvements
 to the automatic typesetting (I am thinking about vertical and
 horizontal spacing, the latter especially for triplets and many other
 points Janek mentioned). I would be interested, if you could classify
 the tweaks needed for the Fried songs?
 Something like: note-spacing, default slurs, broken slurs, very special
 slurs, lyrics shifts, … How many did you need for every kind? And how
 many could (in principle) be solved by a more clever automatic behaviour
 (just a rough guess)?

There are two posts with statistics in the pipelines :-)
In general, i think that at least in half of the cases that needed
tweaking it should be possible to improve automatic formatting so that
LilyPond would solve these problems herself (but it may not be easy).

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[David Kastrup]

Urs Liska m...@ursliska.de writes:

 Hi,

 recently I wrote that LilyPond input files - being plain text - are a
 quite natural choice for single-source or cross-media publishing.
 However, I'm not so sure anymore that this is really true (yet).

 When finishing a LilyPond score to publication quality there is quite
 a lot of tweaking involved - as you can see from Janek's recent posts
 on lilypondblog.org. And this tweaking makes the engraving very
 specific, actually it's only valid for a specific page layout and even
 a specific LilyPond version. Using the same score in a different
 context will now involve quite some hassles: clever versioning
 strategies, complicated tagging or plain rewriting.
 Each of these solutions is more or less impractical, and I think they
 are far away from real cross-media publishing.

That's to be expected.  When tweaking becomes a regular part of the
typesetting process, the advantages of a content-focused system over
WYWISYG are non-existent.  Actually, the balance is likely going to be
negative since WYSIWYG systems _specialize_ on tweaking.

You are doing manually what LilyPond is bad at, and that works contrary
to its design.  The ultimate solution, of course, is to make LilyPond
better, but of course this is less plannable and has less direct and
visible progress than fixing every slur manually.

Of course, that is sobering: if it takes more time to get from
LilyPond's 95% initial typesetting quality to the 99% quality one wants
for publishing than it takes for some WYSIWYG's initial 80%, then we
have a problem.

And yes, it is a problem if sticking with the 95% is not an option.

 If I want a score to be working in a printed book and in a beamer
 presentation, if I want to reformat the score on a display on the
 music stand depending on user's choice of cue notes or let it reflow
 depending on screen resolution etc. I think we'd need really automatic
 engraving, as LilyPond actually advertises already.

 At least to an extent where there are no tweaks necessary for the
 quality demands at hand.

Sure.  For that reason, I consider much of the time spent on tweaking
and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right.  Of course, that option is harder and requires
different resources.  But it only needs to be done once.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan Nieuwenhuizen]

David Kastrup writes:

 Sure.  For that reason, I consider much of the time spent on tweaking
 and tweaking tools a waste of lifetime better spent on trying to get the
 automatisms right.  Of course, that option is harder and requires
 different resources.  But it only needs to be done once.

Yes, although doing manual tweaks once or twice gives you a good feel
for how much work it is, how necessary the tweaks are for publication,
what the new automations should produce and what priorities you would
pick for automating these tweaks.

We used to have an experimental `tweak editor' that would store tweaks a
in a separate tweaks file.  In some way it would be a nice intermediate
to put all manual tweaks in a separate file and merge them with the
actual source.  It would be good to experiment more with that.

Jan.

-- 
Jan Nieuwenhuizen jann...@gnu.org | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar®  http://AvatarAcademy.nl  

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Urs Liska]

Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:

We used to have an experimental `tweak editor' that would store tweaks a
in a separate tweaks file.  In some way it would be a nice intermediate
to put all manual tweaks in a separate file and merge them with the
actual source.  It would be good to experiment more with that.
A way to permanently separate music source from tweaks would be a good 
thing IMO. Separating content from appearance.
If that would be possible one could switch a set of tweaks (i.e. 
different target formats) together with the different layout style sheets.
Actually that's what tags do IISC, but of course they are way too mixed 
in the actual source file.


Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan-Peter Voigt]

Hello all,

I am used to this topic. And I made up my own tool, which is working for
me, but should be called experimental.
I always hesitate to post my github link, because its not well
formed/documented and a mixup of totally different things ...
but there is one engraver, which actually deals with the named situation:
https://github.com/jpvoigt/lalily

The edition engraver is used to make overrides in named contexts
separate from the music content:
%%%
\version 2.16.1
\include lalily.ly

music = \new Staff \with {
  \consists \editionEngraver #'(my edition)
} \new Voice \with {
  \consists \editionEngraver #'(my edition)
} \repeat unfold 3 \relative c'' { bes4( a) c b }

\addEdition master
\editionMod master 2 0/4 #'(my edition Voice A) \once \override NoteHead
#'color = #red
\editionMod master 2 0/4 #'(my edition Voice A) \once \shape Slur #'((0
. 0)(0 . 1)(0 . 1)(0 . 0))

\score {
  \music
  \layout {
\context {
  \Score
  \consists \editionEngraver #'(my edition)
}
  }
}
%%%

While I was working on a larger project, I didn't update to 2.17 yet.
But it will make the input of the path-lists to identify the contexts a
lot easier like
\editionMod master 2 0/4 my.edition.Voice.A {...}

The idea is to have a PDF or printout of the score to publish and I can
simply say for example the slur in measure 42 on the second quarter
needs a little shaping, without polluting the actual music content with
overrides. If I store the music in variables, I can include that file
and engrave a score with the needed overrides. (I say overrides, because
it might be difficult to use \tweak.)

Sometimes I use tags, but they can lead to extraordinary long lines -
polluting the input for one engraving task.

With my lalily framework I store the music in a file-structure-like tree
and call with templates, which are actually music-functions. You find
very few basic examples in the examples folder of the project. But thats
another topic.

Best, Jan-Peter





Am 26.11.2013 11:35, schrieb Urs Liska:
 Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
 We used to have an experimental `tweak editor' that would store tweaks a
 in a separate tweaks file.  In some way it would be a nice intermediate
 to put all manual tweaks in a separate file and merge them with the
 actual source.  It would be good to experiment more with that.
 A way to permanently separate music source from tweaks would be a good
 thing IMO. Separating content from appearance.
 If that would be possible one could switch a set of tweaks (i.e.
 different target formats) together with the different layout style sheets.
 Actually that's what tags do IISC, but of course they are way too mixed
 in the actual source file.
 
 Urs


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Caio Barros]

2013/11/26 Urs Liska u...@openlilylib.org


  A way to permanently separate music source from tweaks would be a good
 thing IMO. Separating content from appearance.
 If that would be possible one could switch a set of tweaks (i.e. different
 target formats) together with the different layout style sheets.
 Actually that's what tags do IISC, but of course they are way too mixed in
 the actual source file.


I don't know if you guys already tried it, but the two times I type
orchestral scores I needed to use little different tweaks for the parts and
for the actual orchestral score (for example: setting a page break after a
silent bar so the player can turn the page). The solution I applied for
this was to create variables that mean one thing in the part file and
another in the orchestral file.

So, for instance:

1) I create a file called partsVariables.ly which have: partBreakPage = {
\pageBreak }

2) In the violinsMusic.ly, for instance I have

violinsMusicOne = \relative c' {
 %some music
 c d e f
 \partBreakPage
 f e d c
}

violinsMusicTwo = \relative c' {
 %music for the second movement
c d e f
}

3) then I create a violins.ly file which contains

\include partsVariables.ly

%first movement

\score {
 \violinsMusicOne
}

% second movement

\score {
 \violinsMusicTwo
}

4) finally, in the orchestra.ly file I don't call the partsVariables.ly
file and simply write:

partBreakPage = { }

\include violinsMusic.ly

%%start the music here

Of course you can create an orchestaVariables.ly if you want. This is
kind of what you are describing as setting the tweaks in a different file
and this really helps in writing orchestral files, including being able to
drop some cue voices, creating scores with just parts of the full orchestra
(just woodwinds, for instance), etc.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Richard Shann]

On Tue, 2013-11-26 at 11:35 +0100, Urs Liska wrote:
 Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
  We used to have an experimental `tweak editor' that would store tweaks a
  in a separate tweaks file.  In some way it would be a nice intermediate
  to put all manual tweaks in a separate file and merge them with the
  actual source.  It would be good to experiment more with that.
 A way to permanently separate music source from tweaks would be a good 
 thing IMO. Separating content from appearance.
 If that would be possible one could switch a set of tweaks (i.e. 
 different target formats) together with the different layout style sheets.

Denemo does allow tweaks to be labelled as exclusive to specific score
layouts, but I am not sure how much separation is possible. If the tweak
were in a completely separate file some means of identifying the point
of application of the tweak would be needed that would be robust against
editing the music. In Denemo you put the music in and then say things
like page break here if it is for the full score layout. Such tweaks
do distract from a clean view of the input music.

Richard



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan-Peter Voigt]

Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:
 Sure.  For that reason, I consider much of the time spent on tweaking
  and tweaking tools a waste of lifetime better spent on trying to get the
  automatisms right.  Of course, that option is harder and requires
  different resources.  But it only needs to be done once.
 Yes, although doing manual tweaks once or twice gives you a good feel
 for how much work it is, how necessary the tweaks are for publication,
 what the new automations should produce and what priorities you would
 pick for automating these tweaks.
IMHO the chances to reduce the number of necessary tweaks for a
publication-ready score to zero are near zero, looking at the diversity
of musical scores.
So, (still IMHO) one should still spend hours to reduce the number of
necessary tweaks. But we should also work on good interfaces for
tweaking the engraving *and* on interfaces to separate content and
design. In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to say: Modify item x in measure n on moment m with
modification (override) d

That way I am able to tweak the full score and the instrument or vocal
parts differently without any - probably tagged - override in the
content file. And I can use the content for any paper size and layout
again, without any overrides in the content.

What do you think about it?

Best, Jan-Peter


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Urs Liska]

Am 26.11.2013 14:12, schrieb Jan-Peter Voigt:

Am 26.11.2013 11:31, schrieb Jan Nieuwenhuizen:

Sure.  For that reason, I consider much of the time spent on tweaking

and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right.  Of course, that option is harder and requires
different resources.  But it only needs to be done once.

Yes, although doing manual tweaks once or twice gives you a good feel
for how much work it is, how necessary the tweaks are for publication,
what the new automations should produce and what priorities you would
pick for automating these tweaks.

IMHO the chances to reduce the number of necessary tweaks for a
publication-ready score to zero are near zero, looking at the diversity
of musical scores.
So, (still IMHO) one should still spend hours to reduce the number of
necessary tweaks. But we should also work on good interfaces for
tweaking the engraving *and* on interfaces to separate content and
design. In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to say: Modify item x in measure n on moment m with
modification (override) d

That way I am able to tweak the full score and the instrument or vocal
parts differently without any - probably tagged - override in the
content file. And I can use the content for any paper size and layout
again, without any overrides in the content.

What do you think about it?


_I_ think that it's very close to what I would currently want to have.
In what way do you consider it experimental?

OTOH I can understand David's concerns: If we make it more comfortable 
to tweak scores (and I think current plans for Frescobaldi are going a 
_big_ step in that direction) we will take the pressure out of improving 
the core.
But I agree: Zero tweaking is definitely impossible. That's why I 
initially spoke about quality demands at hand. If you are creating 
performance material which even has to be flexibly re-formatted you 
can't and don't need to have the same demands as when you publish a 
printed score.


And exactly for this an approach like your edition engraver could be 
very useful.

a) don't stop improving LilyPond to reduce the amount of necessary tweaks
b) write clean input files
c) hope they are sufficient for 'flexible' and 'perform only' use cases
d) store tweaks for a paper publication in a separate file.

Urs



Best, Jan-Peter


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Kieren MacMillan]

Hi all,

 we should also work on good interfaces for
 tweaking the engraving *and* on interfaces to separate content and
 design. In my former answer to Urs' post, I talked about the engraver I
 use. Here's the idea behind it again:
 - I have my music stored, to recall it when I actually engrave it.
 - I want to be able to say: Modify item x in measure n on moment m with
 modification (override) d

Yes. This.

 In what way do you consider it experimental?

Put a different way, why can’t I use it right now? I’ve got many, many [very 
large] projects where this would be so helpful to me.

 If you are creating performance material which even has to be flexibly 
 re-formatted you can't and don't need to have the same demands as when you 
 publish a printed score.

To some degree… but it would be wonderful to improve the **expectations** of 
flexibly-reformattable performance materials to approximate the **demands** of 
a printed score.

 And exactly for this an approach like your edition engraver could be very 
 useful.
 a) don't stop improving LilyPond to reduce the amount of necessary tweaks
 b) write clean input files
 c) hope they are sufficient for 'flexible' and 'perform only' use cases
 d) store tweaks for a paper publication in a separate file.

+1^1
I know… that’s still 1.  ;)

Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Carl Sorensen]

On 11/26/13 6:12 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:

 In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to say: Modify item x in measure n on moment m with
modification (override) d

I think the proposed facility is the kind of thing that is needed.

I look forward to seeing your lalily fix updated to 2.18.  However, IIUC,
at the present your tool can only say: Modify at measure n on moment m in
context c with {}.  That is, there isn't a way to identify an element,
so \tweak isn't available.

My complex versioning strategy (as Urs correctly called it) is to put
the music in a git repository, with a branch for content, and then a
separate branch for each edition.  The branches for each edition are
maintained to be one commit away from the content branch.  I would then
have a makefile with targets for each edition:

A4:
git checkout a4_branch
lilypond myScore

beamer:
git checkout beamer_branch
lilypond myScore

It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Urs Liska]

Am 26.11.2013 14:41, schrieb Carl Sorensen:

It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.


Do you have actual experience how this setup behaves when you have to 
update the content?
Having the branches like you do seems obvious to me. But does that mean 
that once I have to update the content (e.g. apply corrections) I will 
rebase the different 'layout' branches and check if everything is still ok?


Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan-Peter Voigt]

Am 26.11.2013 14:28, schrieb Urs Liska:
 In what way do you consider it experimental?
I don't like the current way of addressing the contexts. I still have to
first look in the created *.edition.log file, to see, under which path
the context is addressed. This is OK for me, but I don't know, how to
explain it to someone else ;)


 OTOH I can understand David's concerns: If we make it more comfortable
 to tweak scores (and I think current plans for Frescobaldi are going a
 _big_ step in that direction) we will take the pressure out of improving
 the core.
yes, I agree. But I still see it as two sides of a medal.

Best, Jan-Peter


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[David Kastrup]

Carl Sorensen c_soren...@byu.edu writes:

 On 11/26/13 6:12 AM, Jan-Peter Voigt jp.vo...@gmx.de wrote:

 In my former answer to Urs' post, I talked about the engraver I
use. Here's the idea behind it again:
- I have my music stored, to recall it when I actually engrave it.
- I want to be able to say: Modify item x in measure n on moment m with
modification (override) d

 I think the proposed facility is the kind of thing that is needed.

Well, the problem is that having the computer juggle with this kind of
information requires a computer-readable format, and basically
non-linear operations beyond the scope of an editor.

That leads to storage formats like MusicXML and editing environments
like Denemo that don't make it the user's job to fiddle with syntax.

At the very least, it becomes unfeasible to use unspecialized text
editors (one could let Emacs do a _lot_ with specialized interfaces and
code, but it would bind continued work on such conglomerate source files
to Emacs _with_ the respective modes) for such a work style, creating
additional dependencies for solving standard editing tasks.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan-Peter Voigt]

Am 26.11.2013 14:41, schrieb Carl Sorensen:
 In my former answer to Urs' post, I talked about the engraver I
 use. Here's the idea behind it again:
 - I have my music stored, to recall it when I actually engrave it.
 - I want to be able to say: Modify item x in measure n on moment m with
 modification (override) d
 I think the proposed facility is the kind of thing that is needed.
OK, it seems, there is interest in this engraver. I hope, I can manage
to demix the whole stuff and right docs sooon.
 
 I look forward to seeing your lalily fix updated to 2.18.
I will do it soon. And I want to demix the whole thing, so that the
edition-engraver, the templating-system and all the other tiny pieces
are separated and only dependant, where needed.
 However, IIUC,
 at the present your tool can only say: Modify at measure n on moment m in
 context c with {}.  That is, there isn't a way to identify an element,
 so \tweak isn't available.
Most times I was able to use (once) override or set, which are
supported. Also supported are break and pageBreak. But if one wants to
edit one notehead (or Accidental) of a chord, it seems not possible
right now. I probably will introduce an interface for that kind of mod,
that says at measure-moment-context look for a note-event then use my
callback (or the like).

Best, Jan-Peter


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan-Peter Voigt]

Am 26.11.2013 15:04, schrieb Jan-Peter Voigt:
 and right docs sooon
I meant write docs soon ...

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Kieren MacMillan]

Hi Jan-Peter (et al.),

 Most times I was able to use (once) override or set, which are
 supported. Also supported are break and pageBreak. But if one wants to
 edit one notehead (or Accidental) of a chord, it seems not possible
 right now. I probably will introduce an interface for that kind of mod,
 that says at measure-moment-context look for a note-event then use my
 callback (or the like).

That sounds great!

As someone who is experimenting with polymetric music (i.e., with non-aligned 
bar lines), please consider — and try to handle gracefully — such situations. 
(That is to say, “measure-moment-context” must be Voice-, or at least Staff-, 
specific.)

Best,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Joseph Rushton Wakeling]

On 26/11/13 11:01, David Kastrup wrote:

Sure.  For that reason, I consider much of the time spent on tweaking
and tweaking tools a waste of lifetime better spent on trying to get the
automatisms right.  Of course, that option is harder and requires
different resources.  But it only needs to be done once.


I don't think it's helpful to see these things in opposition.  Virtually all 
practical engraving scenarios involve needing to make _some_ tweaks -- any 
difficulty in doing so is a block to the usability of Lilypond and hence a block 
to growing the user base.  A growing user base corresponds to a much broader 
range of engraving scenarios and hence feedback that helps drive automation.


Put it another way: your ability to automate is always limited by your ability 
to grasp the range of user requirements and to implement solutions for them.  It 
makes you the bottleneck.  Facilitating users' ability to easily customize 
everything by contrast frees them from the limits of your own vision and time 
constraints.


In one aspect of this, Lilypond is already one of the best tools, because it 
liberates the user so very greatly.  But in terms of the _ease_ of enjoying that 
freedom, it's far too limited, particularly when it comes to trivial tweaks.


I think that you personally are quite right to focus your efforts on automation, 
but it doesn't mean that the efforts to build friendly tweaking tools are a 
waste of time or resources ill-spent.


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[David Kastrup]

Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:

 I think that you personally are quite right to focus your efforts on
 automation, but it doesn't mean that the efforts to build friendly
 tweaking tools are a waste of time or resources ill-spent.

The problem is not with the friendly tweaking tools but with the tweaks.
If you put 1000 tweaks into some music document (and Janek somewhat
proudly stated putting that amount in in a recent project of his), the
document is for all practical considerations locked to a particular
paper format and a particular LilyPond version.  You might as well
archive the PDF file rather than the LilyPond source, since the LilyPond
source will become unusable much faster.

Serious tweaking locks down the document almost as much as
postprocessing with InkScape.  It's a point of no return, and one that
marks the point where having the source code available loses a number of
its advantages.

The number we want to be talking about is maybe a tweak every few pages.
A friendly tweaking tool is still nice for that, but it's not as
important than when you are doing a hundred tweaks per page.

But if we are talking about a hundred tweaks per page, it is extremely
unlikely that those tweaks are _not_ dealing with systematic problems,
and dealing with systematic problems is something that the computer does
with a lot less effort and boredom and tie-in than a human in the long
run.

-- 
David Kastrup


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Jan-Peter Voigt]

Hi Kieren,

On 26.11.2013 15:38, Kieren MacMillan wrote:
 As someone who is experimenting with polymetric music (i.e., with non-aligned 
 bar lines), please consider — and try to handle gracefully — such situations. 
 (That is to say, “measure-moment-context” must be Voice-, or at least Staff-, 
 specific.)
it should deal with this. It is looking for the time in the current
context - and I did a short test with a polymetric piece a typesetted
once. But I found a bit problematic, to find the right barnumber,
because I didn't know where to place a barnumber engraver. I can add one
to a Staff, but it was a bit tricky.

Best, Jan-Peter



___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Carl Sorensen]

On 11/26/13 6:45 AM, Urs Liska u...@openlilylib.org wrote:

Am 26.11.2013 14:41, schrieb Carl Sorensen:
 It's more complex than having a single file that can be correctly
 processed by lilypond, but it's doable with today's tools.

Do you have actual experience how this setup behaves when you have to
update the content?
Having the branches like you do seems obvious to me. But does that mean
that once I have to update the content (e.g. apply corrections) I will
rebase the different 'layout' branches and check if everything is still
ok?

Yes.  Every time the content branch is updated, the layout branches are
rebased.

This isn't as big a problem as it could be because I don't get to the
tweaks until the content is reasonably settled.

The more complex issue (which is probably unnecessary) is that I actually
have two branches for each layout.  One keeps the full history of commits;
the other is squashed to have only a single commit of difference from
layout.  I know it's not necessary, but I find it convenient to be able to
see all of the layout tweaks in a single commit on a git tree viewer.

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Urs Liska]

Am 26.11.2013 17:16, schrieb Carl Sorensen:


On 11/26/13 6:45 AM, Urs Liska u...@openlilylib.org wrote:


Am 26.11.2013 14:41, schrieb Carl Sorensen:

It's more complex than having a single file that can be correctly
processed by lilypond, but it's doable with today's tools.

Do you have actual experience how this setup behaves when you have to
update the content?
Having the branches like you do seems obvious to me. But does that mean
that once I have to update the content (e.g. apply corrections) I will
rebase the different 'layout' branches and check if everything is still
ok?

Yes.  Every time the content branch is updated, the layout branches are
rebased.

This isn't as big a problem as it could be because I don't get to the
tweaks until the content is reasonably settled.

The more complex issue (which is probably unnecessary) is that I actually
have two branches for each layout.  One keeps the full history of commits;
the other is squashed to have only a single commit of difference from
layout.  I know it's not necessary, but I find it convenient to be able to
see all of the layout tweaks in a single commit on a git tree viewer.

Thanks,

Carl

You could keep the full history as a tag so it's slightly more hidden 
for daily work.

But this will probably result in more hassle when rebasing.

Urs

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Kieren MacMillan]

Hi all,

 The number we want to be talking about is maybe a tweak every few pages.
 A friendly tweaking tool is still nice for that, but it's not as
 important than when you are doing a hundred tweaks per page.
 
 But if we are talking about a hundred tweaks per page, it is extremely
 unlikely that those tweaks are _not_ dealing with systematic problems,
 and dealing with systematic problems is something that the computer does
 with a lot less effort and boredom and tie-in than a human in the long run.

So the sweet spot is the convergence point of optimally-intelligent 
automatic/“systematic” algorithms and an optimally-user-friendly tweaking 
system…
Sounds dead simple to implement…  ;)

Cheers,
Kieren.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[David Kastrup]

Kieren MacMillan kieren_macmil...@sympatico.ca writes:

 Hi all,

 The number we want to be talking about is maybe a tweak every few pages.
 A friendly tweaking tool is still nice for that, but it's not as
 important than when you are doing a hundred tweaks per page.
 
 But if we are talking about a hundred tweaks per page, it is extremely
 unlikely that those tweaks are _not_ dealing with systematic problems,
 and dealing with systematic problems is something that the computer does
 with a lot less effort and boredom and tie-in than a human in the long run.

 So the sweet spot is the convergence point of optimally-intelligent
 automatic/“systematic” algorithms and an optimally-user-friendly
 tweaking system…
 Sounds dead simple to implement…  ;)

The sweet spot is nothing to implement: it's an emergent measure from
the respective qualities of tweaking tools and algorithms.

I tend to view the tweaking tools as being more on the sickly-sweet side
since the real problems come after you think you are done.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Janek Warchoł]

2013/11/26 Urs Liska m...@ursliska.de:
 When finishing a LilyPond score to publication quality there is quite a lot
 of tweaking involved - as you can see from Janek's recent posts on
 lilypondblog.org. And this tweaking makes the engraving very specific,
 actually it's only valid for a specific page layout and even a specific
 LilyPond version.

Fortunately my recent improvements to \shape (in particular polar
coordinates) should make slur tweaks much less specific.

2013/11/26 David Kastrup d...@gnu.org:
 Of course, that is sobering: if it takes more time to get from
 LilyPond's 95% initial typesetting quality to the 99% quality one wants
 for publishing than it takes for some WYSIWYG's initial 80%, then we
 have a problem.

I'd say that the effort is similar in both cases.  This is generally
what i had in mind when i wrote this post:
http://lilypondblog.org/2013/08/is-lilypond-good-enough-followup-with-graphs/

 For that reason, I consider much of the time spent on tweaking
 and tweaking tools a waste of lifetime better spent on trying to get the
 automatisms right.  Of course, that option is harder and requires
 different resources.  But it only needs to be done once.

Well, the most important problem is that usually you have a deadline
for finishing a project, and improving LilyPond takes two or more
orders of magnitude longer than tweaking - even _if you have_ the
skills necessary for improving LilyPond...

Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Janek Warchoł]

2013/11/26 Carl Sorensen c_soren...@byu.edu:
 On 11/26/13 6:45 AM, Urs Liska u...@openlilylib.org wrote:
Am 26.11.2013 14:41, schrieb Carl Sorensen:
 It's more complex than having a single file that can be correctly
 processed by lilypond, but it's doable with today's tools.

Do you have actual experience how this setup behaves when you have to
update the content?
Having the branches like you do seems obvious to me. But does that mean
that once I have to update the content (e.g. apply corrections) I will
rebase the different 'layout' branches and check if everything is still
ok?

 Yes.  Every time the content branch is updated, the layout branches are
 rebased.

 This isn't as big a problem as it could be because I don't get to the
 tweaks until the content is reasonably settled.

I was thinking about such setup, too.  But the problem that i see is
that rebasing so often is problematic, especially when you're
collaborating with someone.

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Janek Warchoł]

2013/11/26 Carl Sorensen c_soren...@byu.edu:
 My complex versioning strategy (as Urs correctly called it) is to put
 the music in a git repository, with a branch for content, and then a
 separate branch for each edition.  The branches for each edition are
 maintained to be one commit away from the content branch.  I would then
 have a makefile with targets for each edition:

 A4:
 git checkout a4_branch
 lilypond myScore

 beamer:
 git checkout beamer_branch
 lilypond myScore

 It's more complex than having a single file that can be correctly
 processed by lilypond, but it's doable with today's tools.

I was thinking about this, too.  But the problem that i see is that
this strategy requires rebasing often, i.e. commits with layout tweaks
need to be rebased on top of musical content commits every time a
correction/change to the content is added.

Rebasing so often is problematic, especially when you're collaborating
with someone.

best,
Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Janek Warchoł]

2013/11/26 David Kastrup d...@gnu.org:
 Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes:

 I think that you personally are quite right to focus your efforts on
 automation, but it doesn't mean that the efforts to build friendly
 tweaking tools are a waste of time or resources ill-spent.

 The problem is not with the friendly tweaking tools but with the tweaks.
 If you put 1000 tweaks into some music document (and Janek somewhat
 proudly stated putting that amount in in a recent project of his),

;-)
I wasn't proud of myself, i was proud of \shape.

 the
 document is for all practical considerations locked to a particular
 paper format and a particular LilyPond version.  You might as well
 archive the PDF file rather than the LilyPond source, since the LilyPond
 source will become unusable much faster.

 Serious tweaking locks down the document almost as much as
 postprocessing with InkScape.

No, that's an overstatement.  Sure, one cannot update to new LilyPond
versions easily, but geting small modifications and corrections into
the scores remains easy.

 The number we want to be talking about is maybe a tweak every few pages.

Lol, good joke! ;-P
Achieving that will take us some time :)

 But if we are talking about a hundred tweaks per page, it is extremely
 unlikely that those tweaks are _not_ dealing with systematic problems,
 and dealing with systematic problems is something that the computer does
 with a lot less effort and boredom and tie-in than a human in the long
 run.

Yes, i definitely agree!  But i also agree with Joe wheh he says:

2013/11/26 Joseph Rushton Wakeling joseph.wakel...@webdrake.net:
 A growing user base corresponds to a much broader range of engraving
 scenarios and hence feedback that helps drive automation.

Case in point: exactly _because_ i had used \shape to tweak over a
1000 slurs, i was able to see how to best improve it, and now we'll
have the ability to use polar coordinates in \shape.  Which is a step
towards robustness and automation (for example, one \shape with polar
coordinates can often fix multiple slurs).  I have also learned a
great deal about how slurs in LilyPond behave in general, and
collected tons of examples, and i hope to use that knowledge to
improve actual slur formatting code (yes, i hope to continue working
on http://code.google.com/p/lilypond/issues/detail?id=3628 this
week...).

Bottom line: after \shaping 1000 slurs, i got really bored and
improved \shape.  After using it for the next 500 slurs, i expect to
get really bored again and fix some issues in slur formatting that
will bother me the most - because i'll be _personally motivated_ to do
so.  Repeat ad infinitum :-)

Janek

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Urs Liska]

Am 26.11.2013 18:12, schrieb Janek Warchoł:

Bottom line: after \shaping 1000 slurs, i got really bored and
improved \shape.  After using it for the next 500 slurs, i expect to
get really bored again and fix some issues in slur formatting that
will bother me the most - because i'll be_personally motivated_  to do
so.  Repeat ad infinitum:-)


Better: Iterate until resolution ...

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[David Kastrup]

Janek Warchoł janek.lilyp...@gmail.com writes:

 2013/11/26 David Kastrup d...@gnu.org:

 But if we are talking about a hundred tweaks per page, it is
 extremely unlikely that those tweaks are _not_ dealing with
 systematic problems, and dealing with systematic problems is
 something that the computer does with a lot less effort and boredom
 and tie-in than a human in the long run.

 Yes, i definitely agree!  But i also agree with Joe wheh he says:

 2013/11/26 Joseph Rushton Wakeling joseph.wakel...@webdrake.net:
 A growing user base corresponds to a much broader range of engraving
 scenarios and hence feedback that helps drive automation.

 Case in point: exactly _because_ i had used \shape to tweak over a
 1000 slurs, i was able to see how to best improve it, and now we'll
 have the ability to use polar coordinates in \shape.
 Which is a step towards robustness and automation (for example, one
 \shape with polar coordinates can often fix multiple slurs).

Aren't you confusing automation with more comfortable manual tools
here?

 Bottom line: after \shaping 1000 slurs, i got really bored and
 improved \shape.  After using it for the next 500 slurs, i expect to
 get really bored again and fix some issues in slur formatting that
 will bother me the most - because i'll be _personally motivated_ to do
 so.  Repeat ad infinitum :-)

I haven't been doing any actual typesetting for years, so that approach
does not work all that much for me.

My usual creative process involves explaining to people how to do
something with LilyPond and becoming so grossly embarrassed that
I change LilyPond rather than having to repeat that explanation.

Of course, this works better for frontend work which is indeed where
I spend most of my energy.  So that gets me to the point where people
and LilyPond understand each other.

-- 
David Kastrup

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Carl Sorensen]

On 11/26/13 9:50 AM, Janek Warchoł janek.lilyp...@gmail.com wrote:

2013/11/26 Carl Sorensen c_soren...@byu.edu:


 This isn't as big a problem as it could be because I don't get to the
 tweaks until the content is reasonably settled.

I was thinking about such setup, too.  But the problem that i see is
that rebasing so often is problematic, especially when you're
collaborating with someone.

I haven't experienced any problems with rebasing in non-lilypond git
collaboration.

I haven't ever done collaboration in lilypond score development, so I
don't have any basis for judgement in this case.

Thanks,

Carl


___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Janek Warchoł]

2013/11/26 David Kastrup d...@gnu.org:
 Janek Warchoł janek.lilyp...@gmail.com writes:

 2013/11/26 David Kastrup d...@gnu.org:

 But if we are talking about a hundred tweaks per page, it is
 extremely unlikely that those tweaks are _not_ dealing with
 systematic problems, and dealing with systematic problems is
 something that the computer does with a lot less effort and boredom
 and tie-in than a human in the long run.

 Yes, i definitely agree!  But i also agree with Joe wheh he says:

 2013/11/26 Joseph Rushton Wakeling joseph.wakel...@webdrake.net:
 A growing user base corresponds to a much broader range of engraving
 scenarios and hence feedback that helps drive automation.

 Case in point: exactly _because_ i had used \shape to tweak over a
 1000 slurs, i was able to see how to best improve it, and now we'll
 have the ability to use polar coordinates in \shape.
 Which is a step towards robustness and automation (for example, one
 \shape with polar coordinates can often fix multiple slurs).

 Aren't you confusing automation with more comfortable manual tools
 here?

Not quite.  Yes, as of now i've mostly worked on making tweaking more
comfortable, but i gained insight that will be helpful when improving
automation.

 Bottom line: after \shaping 1000 slurs, i got really bored and
 improved \shape.  After using it for the next 500 slurs, i expect to
 get really bored again and fix some issues in slur formatting that
 will bother me the most - because i'll be _personally motivated_ to do
 so.  Repeat ad infinitum :-)

 I haven't been doing any actual typesetting for years, so that approach
 does not work all that much for me.

 My usual creative process involves explaining to people how to do
 something with LilyPond and becoming so grossly embarrassed that
 I change LilyPond rather than having to repeat that explanation.

:-)

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user

Re: Discussion: automatic engraving and single-source publishing

[Noeck]

Hi

Just a quick but honest thank you from my side to all of you for
improving the out-of-the-box quality, tweaking-possibilities (e.g.
\shape) and simplifications for users (e.g. the.dot.syntax instead of #')!

I think, the blog posts show that there is still room for improvements
to the automatic typesetting (I am thinking about vertical and
horizontal spacing, the latter especially for triplets and many other
points Janek mentioned). I would be interested, if you could classify
the tweaks needed for the Fried songs?
Something like: note-spacing, default slurs, broken slurs, very special
slurs, lyrics shifts, … How many did you need for every kind? And how
many could (in principle) be solved by a more clever automatic behaviour
(just a rough guess)?

The possibility to enter tweaks separately from the music input sounds
very good.


Cheers,
Joram

___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user