Francois Planiol <alicuota...@gmail.com> writes: > 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?)
Free is not a problem but it also is not much of a selling point for in-house software as pretty much all acquisition costs are dwarfed by running expenses, particularly personnel. How expensive is personnel that can be trained to work with LilyPond, and how fast are they going to crank out stuff? And most importantly: when there are problems, is there a reliable place you can throw money at to make them go away? There are quite few businesses built around TeX/LaTeX which has, in some manner, a more dependable foundation than LilyPond. > 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. GNU was never a counterthesis to "expensive". The main question we have to ask ourselves is even if we manage to promote LilyPond as a "technology", how do we get actual users to profit from that? Wikipedia offers LilyPond input by now as a <score> tag IIRC. That's actually a use where the input syntax is available to the user. I think that LilyPond's main strength is transformative use: different page formats, different media, different transpositions, individual variations. Pixel-wise control is a nuisance for those kinds of uses. Any tweaks should be reasonably robust (meaning that they do close to the right thing under transformations) and you probably need a versioned/interpolating handling of them so that manipulations for version x and version y are reasonably applicable to something in between. That starts smelling like semi-manual "hinting" of scores. -- David Kastrup _______________________________________________ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
