lilypond-user
[Top][All Lists]
Advanced

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

Re: Lilypond lobbying?


From: Janek Warchoł
Subject: Re: Lilypond lobbying?
Date: Mon, 22 Aug 2011 20:49:42 +0200

2011/8/22 Christ van Willegen <address@hidden>:
> 2011/8/22 Janek Warchoł <address@hidden>:
>> What would be the point of using LilyPond then, if all the beautiful
>> formatting will be lost?
>
> Keyboard entry?

For many people it's a disadvantage.
Certainly entering notes on a virtual staff paper has some advantages.


2011/8/22 Urs Liska <address@hidden>:
> Am 22.08.2011 14:23, schrieb Janek Warchoł:
> The point is to be more open in a bidirectional exchange.
> This option would allow to write scores in LilyPond even when you for some
> reason or the other are obliged to produce Finale/Sibelius files.

Of cource i support bidirectional exchange!  It'll be very good to
have the possibility to convert LilyPond scores to finale scores in
case such need arises.  I only don't see much sense in writing score
in LilyPond with the intention of converting it to finale right from
the start.  I think it would be more reasonable to do it altogether in
finale.

> There are several situations I could think of:
>
> LilyPond is just the program you know how to use.
> You don't want to learn - and even less to buy - other programs
> You write music that relies on complex scheme functions
> (for example for some forms of algorithmic composition)
> You want to create scores programmatically
> - I once wrote a Pascal program that created the LilyPond input file for a
> serial composition
> - I never really did but dreamt of a possibility to create a LilyPond file
> from a PureData performance

ok, these are valid exceptions to what i wrote above.

> The situations where you need the Finale files have been thoroughly
> discussed by now.
> While we all would prefer being able to sell our Lily files, we have to live
> with the fact that this is often not possible.
> This mail that I had to read gives an unwanted but good argument why editors
> have the right to insist on their "workflow":
> http://www.mail-archive.com/address@hidden/msg64139.html.
>
> Having the possibility to stay somewhat compatible would ease the step to
> try out LilyPond for other typesetters and would thus probably increase the
> user base.
> This is somewhat comparable to the impact of the existence of Dual Boot
> setups (and then Virtual Machines and even Into-Windows-Installing) on the
> increased amount of Linux users.
>
> When I started to use LilyPond I didn't expect at all that I would someday
> have to deal with real world publishers. If I had known then, I might never
> had given LilyPond a try.

Yes, it's very discouraging that publishers don't want to accept Lily format.

2011/8/22 David Kastrup <address@hidden>:
> Assume that the composer has created a four part fugue with macros for
> the parts and counterparts, snug together with augmentation,
> transposition and so on.  You can change the theme, and get a different
> fugue out.
>
> But an editor does not want to change the theme.  He might want to
> octavate a phrase to accommodate common instrument ranges, or add
> fingerings to some passages.  The fingerings, obviously, don't transpose
> well.  The score is composer-friendly, not editor-friendly.
>
> Hm.

That's a valid and very important concern.  I think that the best
solution to such problems would be an advanced user interface, capable
of converting lily source in many ways - for example extracting
dynamics from a voice and integrating them back with a one click,
changing style formatting etc.
It would be extremely useful if such an interface could show the score
in a "horizontal view", i.e. turn automatically this:

voiceI = {
  c'4 d' e' f'
  g'8 d' g'4 f'2
}
voiceII = {
  g2 c
  b2 f8 e d c
}
<<
  \new Voice \voiceI
  \new Voice \voiceII
>>

into:

<<
  \new Voice { c'4  d'  e'  f'  | g'8 d' g'4  f'2      | }
  \new Voice { g2       c       | b2          f8 e d c | }
>>

(view this with monospace font)
and back again!  Imagine the possibilities!


2011/8/22 Henning Hraban Ramm <address@hidden>:
> Of course a proud composer would mention this contest. But including the
> sponsor’s logos? Forever??
> If you don’t become famous, it’s no problem.
> But imagine you’d have to credit each of Mozart’s, Bach’s etc. principals
> including their coat of arms in every kind of publication? (Ignoring that
> they're in the public domain now.)

:D


2011/8/22 Urs Liska <address@hidden>:
> And I still think a versed editor will also be very well able to deal with
> lilypond files. The problem is that publishers don't have enough specialists
> at hand, don't know whether they can rely on getting the right people for
> the revised edition in ten years, a.s.o.
> While this also holds true for the commercial products it surely is more
> frightening being confronted with an open source project with an input
> language that seemingly only nerds care to learn, a.s.o.
> I have by now understood that it is very much useless to try to convince or
> even force any major players in using LilyPond. And probably one  can't even
> blame them because - as you pointed out - from their current perspective it
> would be economically risky to rely on such a thing.
>
> No, I'm a pianist. So far I used Lilypond to create performance material if
> I need it (for example transpositions of songs, creating an ensemble score
> from handwritten parts etc.) But now things have changed and there sometimes
> arises the possibility to publish these scores. Or not, because I can't
> provide Finale files.

It seems like a chicken-and-egg problem...  But we simply cannot
afford not overcoming it.
I wouldn't stand it if i knew for sure that LilyPond would never be
accepted in the professional market.  I think it would break my heart,
but i would quit the project in such case, and perhaps music
typesetting in general (i'm not suicidal enough to use fin/sib).  I
hope that it's a matter of time and hard work till we become widely
known.

cheers,
Janek



reply via email to

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