lilypond-user
[Top][All Lists]
Advanced

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

Re: short Musikmesse minutes


From: Francois Planiol
Subject: Re: short Musikmesse minutes
Date: Wed, 19 Mar 2014 20:23:12 -0500

Lily is free and that is a biiiig problem, for salesmen.

Remember the incandescent lamp? It was not expensive enough and
forcedly replaced by a dangerous CFL with a higher margin for
everybody except the end-customer. So forget it, when it is free. Just
even worse for commerce. (sure there is not some trust-negociations
between engraving programs companies and music publishing job?)

We have Mutopia, remotedly cpdl and imslp, I miss a more flexible
snippets2music.ly website, the use of tablets under musicians in
drastically increasing (I still prefer high-quality paper) so the
configurability of scores will have to stand to new standards anyway,
so what the deal?

"let the deads bury the deads" and use lily.pdf on tablets, print at
home and find a binding system that you like (and sell tablets!)

Expensive sheet music is dead, be happy in free and GNU-world.

:-)

Francois

2014-03-19 19:56 GMT-05:00, SoundsFromSound <address@hidden>:
> Urs Liska wrote
>> Am 20.03.2014 00:18, schrieb Kieren MacMillan:
>>> Hi Urs,
>>>
>>>>> Time for a Lilypond Publishing House...
>>>> I'd say rather push LilyPond into the existing publishing houses.
>>>
>>> Why not both?
>>
>> Nothing against it. But actually there _are_ already a number of
>> "LilyPond Publishing Houses" - all of them of neglectable market impact.
>>
>>>
>>>> And I think changes have never been better for that than now.
>>>
>>> True.
>>>
>>> In my opinion, here -- in order of importance -- are the things we need to
>>> make established houses sit up and take notice:
>>>
>>> 1. Flawless MusicXML import and export.
>>> 2. Better "pixel-level" control of objects.
>>> 3. A finely-tuned stylesheet system.
>>> 4. Excellent, "turnkey" edition control features.
>>> 5. Several examples of fairly complex engravings, presented with "best
>>> practice" coding.
>>>
>>> #4 is nearly in place, thanks to Jan-Peter.
>>
>> Indeed. I hope it will be possible to make that generally usable (be it
>> through inclusion in LilyPond itself or a easily usable place in one of
>> the libraries.
>> Having this would be a valuable additional selling point.
>>
>>>
>>> #3 would take, in my estimation, about 10 person-hours to prepare an
>>> exemplar set of stylesheets (I'd be happy to do this myself), and 5-10
>>> hours to create an appropriate stylesheet-loading function.
>>>
>>
>> I'm not so sure if this would really matter that much in terms of
>> "market penetration".
>> Which isn't to say that I'd find that highly desirable myself.
>>
>>> #5 could be put together in "no time".
>>
>> At the messe I had a compilation of samples (explicitly including
>> non-publication quality "default" engravings) with me (including your
>> Beethoven BTW), and this proved very useful.
>>
>>>
>>> #2 would require some fundamental changes to Lilypond -- likely this is
>>> the largest hurdle.
>>
>> Apart from pixel-level it will be a tremenduous step if we manage to get
>> a certain kind of graphical approach to that, as is currently being
>> worked on in Frescobaldi.
>> Graphically editing things while retaining strict control over the
>> source code will be a killer feature.
>> So I'd add that as a separate item to your list.
>>
>>>
>>> #1 is the next largest hurdle.
>>
>> Yes, and a crucial one. But I think current development is very
>> promising. For the first time someone is actually working on it.
>> Although it is only a first step this is really a solid foundation.
>> (Although only visible when using Frescobaldi from its Git repository.
>>
>>>
>>> Thoughts?
>>
>> One thing that isn't in your list - and which already is there - is
>> everything around the power of version controlled workflows. This
>> provides solutions to actual problems people have. At least this was my
>> experience in Frankfurt. Everybody seems to know about the hassles one
>> has with concurrent revisions of files when having to pass documents
>> around. Meticulous project documentation, encapsulation in branches etc.
>> were keywords editors could grasp immediately.
>> Question is how they will react when they see actual LilyPond code. I'm
>> looking forward to that (there are two publishers I'll visit for closer
>> demonstrations, with two more I have hopes to get to that point too).
>>
>> Urs
>>
>>>
>>> Kieren.
>>> _______________________________________________
>>> lilypond-user mailing list
>>>
>
>> lilypond-user@
>
>>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>>>
>>
>>
>> _______________________________________________
>> lilypond-user mailing list
>
>> lilypond-user@
>
>> https://lists.gnu.org/mailman/listinfo/lilypond-user
>
> Are there any style sheets floating around that people can take a look at?
> The sheet Urs & co. used looked great to my eyes, on that collection.
>
> Maybe that could help users and also inspire them to create their own sorts
> of "house styles". Just a thought...
>
>
>
>
>
>
> -----
> composer | sound designer
> LilyPond Tutorials (for beginners) --> http://bit.ly/bcl-lilypond
> --
> View this message in context:
> http://lilypond.1069038.n5.nabble.com/short-Musikmesse-minutes-tp160594p160628.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
>



reply via email to

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