Re: Appreciation / Financial support
On Mon, Jun 18, 2012 at 6:46 AM, Christ van Willegen cvwille...@gmail.comwrote: On Mon, Jun 18, 2012 at 12:12 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamara tim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. Ouch, that's quite steep! David, since you live in .de, you probably also have a bank account there. If you list the IBAN (and other info) somewhere, in .eu bank transfers are free of fees... Does that include the UK? Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ 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: Appreciation / Financial support
Christ van Willegen cvwille...@gmail.com writes: On Mon, Jun 18, 2012 at 12:12 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamara tim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. Ouch, that's quite steep! David, since you live in .de, you probably also have a bank account there. If you list the IBAN (and other info) somewhere, in .eu bank transfers are free of fees... Only in the Euro zone, and they are not _free_ of fee but just can't exceed the fees for national transfers. A recent contributor from France discovered that his bank took €3 according to its conditions. But it would have done so as well within France. Now while I have my doubts that a bank with that sort of condition for a fundamental operation would be competitive (and so I consider it somewhat likely that there was some mistake involved), I think that would not be against EU regulations: you can charge all you want for a SEPA bank transfer as long as you are gouging your customers the same in-country. As a rule, contributors in the Euro zone have found transfer costs zero or small. This obviously excludes the UK, and fees for bank transfers from there are somewhere around the £10 figure or more, namely prohibitive. Fees might vary according to bank, but so far people have found that what Paypal skims off is the lesser evil. I will not list my bank data publicly but give it out on request. This is my private account and I need to be able to track the source of incoming money. The account also is not specific to LilyPond but to myself, so if I quit working on LilyPond on a donation basis, I need to be able to contact everyone who has contributed so far, and don't want to continue having this account be the target for LilyPond based contributions. A publicly listed account number would require a _dedicated_ account, one which one can close down when the purpose is no longer in place. Fees for such a non-personal account, namely a business account, are considerably higher. Basically it is the same story all over: if you do things properly, everybody working the pipeline feels entitled to a more substantial share. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Are either Flattr or Bitcoin possible good alternatives? On Mon, Jun 18, 2012 at 8:54 AM, David Kastrup d...@gnu.org wrote: Christ van Willegen cvwille...@gmail.com writes: On Mon, Jun 18, 2012 at 12:12 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamara tim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. Ouch, that's quite steep! David, since you live in .de, you probably also have a bank account there. If you list the IBAN (and other info) somewhere, in .eu bank transfers are free of fees... Only in the Euro zone, and they are not _free_ of fee but just can't exceed the fees for national transfers. A recent contributor from France discovered that his bank took €3 according to its conditions. But it would have done so as well within France. Now while I have my doubts that a bank with that sort of condition for a fundamental operation would be competitive (and so I consider it somewhat likely that there was some mistake involved), I think that would not be against EU regulations: you can charge all you want for a SEPA bank transfer as long as you are gouging your customers the same in-country. As a rule, contributors in the Euro zone have found transfer costs zero or small. This obviously excludes the UK, and fees for bank transfers from there are somewhere around the £10 figure or more, namely prohibitive. Fees might vary according to bank, but so far people have found that what Paypal skims off is the lesser evil. I will not list my bank data publicly but give it out on request. This is my private account and I need to be able to track the source of incoming money. The account also is not specific to LilyPond but to myself, so if I quit working on LilyPond on a donation basis, I need to be able to contact everyone who has contributed so far, and don't want to continue having this account be the target for LilyPond based contributions. A publicly listed account number would require a _dedicated_ account, one which one can close down when the purpose is no longer in place. Fees for such a non-personal account, namely a business account, are considerably higher. Basically it is the same story all over: if you do things properly, everybody working the pipeline feels entitled to a more substantial share. -- David Kastrup ___ 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: Appreciation / Financial support
On 17/06/12 23:12, Janek Warchoł wrote: On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamaratim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. https://cms.paypal.com/us/cgi-bin/?cmd=_render-contentcontent_ID=marketing_us/fees They also have a micropayments rate which might work out better depending on typical donation size: https://micropayments.paypal-labs.com/ ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 17/06/12 23:12, Janek Warchoł wrote: On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamaratim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. https://cms.paypal.com/us/cgi-bin/?cmd=_render-contentcontent_ID=marketing_us/fees They also have a micropayments rate which might work out better depending on typical donation size: https://micropayments.paypal-labs.com/ Do the math. The break-even point for 5%+$0.05 as opposed to 2.9%+$0.30 is when 2.1% amount to $0.25, namely $11.90. The fee for $20 will already be $1.05 rather than $0.88, for $50 it will be $2.55 rather than $1.75. With the current contribution structure, a change would not really be prudent. That makes more sense if you have a large number of casual small contributors. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Message: 2 Date: Sat, 02 Jun 2012 20:33:47 +0200 From: David Kastrup d...@gnu.org To: Janek Warcho? janek.lilyp...@gmail.com Cc: lilypond-user@gnu.org Subject: Re: Appreciation / Financial support Message-ID: 87hauty35g@fencepost.gnu.org Content-Type: text/plain; charset=utf-8 Janek Warcho? janek.lilyp...@gmail.com writes: On Sat, Jun 2, 2012 at 5:37 PM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jun 02, 2012 at 04:38:24PM +0200, Janek Warcho? wrote: So, apologies - and where can i read detailed policies? Detailed policy is pretty much exactly what is shown on that webpage, ok. I think that adding a /small/ donation progress bar in David's description wouldn't be a violation of the rules. But i don't insist. End of discussion :) I'll probably see whether I manage to create some 250-byte ASCII-art progress bar donation home page that does not pose much of a risk of blowing the transfer limits of some zero-cost site if it is _that_ important to people. Sorry, I missed this message... Ok, so the messages I've taken away so far are, Lilypond Website Commercialism Danger! Battlestations, and, You can already sneak into my room and leave money in my sock drawer, why do I need to draw you a website? It'd be nice if someone else (i.e., not me) figured out a user-friendly way for people to donate money to the Lilypond devs without having the entire donation eaten up in the fees accrued from time spent trying to interact with them. -Jonathan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Jonathan Wilkes jancs...@yahoo.com writes: Message: 2 Ok, so the messages I've taken away so far are, Lilypond Website Commercialism Danger! Battlestations, and, You can already sneak into my room and leave money in my sock drawer, why do I need to draw you a website? Frankly, you already _have_ my Email address for use in Paypal donations. Being able to click a ready-made donation button with target bar apparently takes out an additional percentage. Unless one can show to be a tax-exemptible charity. And so forth and so on. It'd be nice if someone else (i.e., not me) someone else is certainly LilyPond's most asked for developer. Who would not know a lot of tasks that someone else is absolutely the best choice for? figured out a user-friendly way for people to donate money to the Lilypond devs without having the entire donation eaten up in the fees accrued from time spent trying to interact with them. Frankly, I'd have a bad conscience spending a week of paid LilyPond work figuring out a way to get a clickable button for another deduction of fees. And if I feel bad about things, my efficiency drops about ten notches. That's stuff I _am_ pretty bad at. So don't hold your breath. But it does not appear like you do. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Sun, Jun 17, 2012 at 6:47 PM, Jonathan Wilkes jancs...@yahoo.com wrote: It'd be nice if someone else (i.e., not me) figured out a user-friendly way for people to donate money to the Lilypond devs without having the entire donation eaten up in the fees accrued from time spent trying to interact with them. If you are in EU, send a SEPA wire transfer. It's cheap. If you're from outside of EU, PayPal should be easy. These look user-friendly enough, i think. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Jun 17, 2012, at 4:04 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: On Sun, Jun 17, 2012 at 6:47 PM, Jonathan Wilkes jancs...@yahoo.com wrote: It'd be nice if someone else (i.e., not me) figured out a user-friendly way for people to donate money to the Lilypond devs without having the entire donation eaten up in the fees accrued from time spent trying to interact with them. If you are in EU, send a SEPA wire transfer. It's cheap. If you're from outside of EU, PayPal should be easy. These look user-friendly enough, i think. From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamara tim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. https://cms.paypal.com/us/cgi-bin/?cmd=_render-contentcontent_ID=marketing_us/fees cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Mon, Jun 18, 2012 at 12:12 AM, Janek Warchoł janek.lilyp...@gmail.com wrote: On Sun, Jun 17, 2012 at 11:28 PM, Tim McNamara tim...@bitstream.net wrote: From experience, PayPal is very easy to use to send money to someone in Europe. The currency exchange is automatic, although I don't know what the recipient fees are. According to their website it's between 0 and 4% +0,3$ depending on payment method and country. Ouch, that's quite steep! David, since you live in .de, you probably also have a bank account there. If you list the IBAN (and other info) somewhere, in .eu bank transfers are free of fees... Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Am 12.06.2012 19:48, schrieb Janek Warchoł:
form = {
\repeat unfold 4 { s1*4 \break }
}
music = {
\repeat unfold 64 a'4
}
\music \form
Actually this doesn't work. You will need something like this:
music = \relative c'' {
\repeat unfold 8 { a4 b c d e d c b }
}
\oneVoice \music \\ \form
...but without \\. You don't want to have \music typeset as first
voice (upstemmed).
Nope, as you can see I changed the music definition so that you get both
notes with up stem and down stem. The intention is to show the up/down
stem problem.
Without the \\ you get up and down stems but also an empty stave that
you don't want, want you? The oneVoice inhibits the all upstemmed. Give
it try, pass the lines to Lilypond. ;-)
Helge
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Wed, Jun 13, 2012 at 8:20 PM, Helge Kruse helge.kruse-nos...@gmx.net wrote: Am 12.06.2012 19:48, schrieb Janek Warchoł: ...but without \\. You don't want to have \music typeset as first voice (upstemmed). Nope, as you can see I changed the music definition so that you get both notes with up stem and down stem. The intention is to show the up/down stem problem. Without the \\ you get up and down stems but also an empty stave that you don't want, want you? The oneVoice inhibits the all upstemmed. Give it try, pass the lines to Lilypond. ;-) Indeed, i didn't notice \oneVoice. Nevertheless, the structurally correct way of doing this is \new Staff \music \form cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Ivan Kuznetsov ivan.k.kuznet...@gmail.com writes:
Music notation is complex. Any ASCII representation of
music notation likewise has to be complex.
Music consists of many notes and parts. Any music instrument likewise
has to consist of many notes and parts. For example, you can play
several dozens of different notes on a violin, so a violin needs several
dozens of strings.
Any simplification of lilypond syntax must mean a removal
of features.
Which feature did I remove by reallowing to use
\midi { \tempo 4 = 120 }
instead of
\midi { \context {
\Score tempoWholesPerMinute = #(ly:make-moment 480 4)
} }
or whatever it was?
Which feature did I remove by changing the use of $ in music functions
and making lexical closures work as one would expect?
The only other alternative is to use a WYSIWYG editor [...]
Available complexity does not mean that things must not be worked as
expected. It does not mean that simple tasks need to be complex as
well.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
I think that this could simplify the syntax by creating a standard skeleton for .ly files going from most global to most specific: \version information \paper information \form information (number of bars, repeat locations, bars-per-line, rehearsal mark locations, number of staves, instruments/voices, \clef, \key, \time, etc.) \music information (could be \notes (including percussion), \chordnames or \lyrics) It would be great if you could work out a small piano piece with, say, 16 bars, using your suggested syntax. Werner ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 3:45 AM, Tim McNamara tim...@bitstream.net wrote: Let me respond as a musician rather than as a programmer, because I am the first and I am not the second. A lot of the syntax of Lilypond makes little sense except perhaps to people used to coding. If you're a musician, the first months of trying to use Lilypond can be little more than an exercise in frustration. There are several reasons for this, including: [..] Do you know about GLISS (http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#grand-lilypond-input-syntax-standardization-_0028gliss_0029)? It's planned for this summer (never mind obsolete dates in Contributors' Guide), and it may help with many of your (valid) concerns. I hope that you'll help by participating in (maybe organizing some?) discussions. Btw, have you read my articles in previous LilyPond Report? http://news.lilynet.net/?The-LilyPond-Report-25#lilypond_s_future http://news.lilynet.net/?The-LilyPond-Report-25#working_with_lilypond_a_personal_experience cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 7:49 AM, Jonathan Wilkes jancs...@yahoo.com wrote: I think if Lilypondtool or Frescobaldi would allow you to click-drag some of the grobs like dynamics and markup in the preview pdf and automatically insert code to make the tweak, that would be huge. +1 Wilbert (author of Frescobaldi) said this should be possible to do. -- Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, 12 Jun 2012 00:22:55 -0500
Tim McNamara tim...@bitstream.net wrote:
I think that this could simplify the syntax by creating a standard
skeleton for .ly files going from most global to most specific:
\version information
\paper information
\form information (number of bars, repeat locations, bars-per-line,
rehearsal mark locations, number of staves, instruments/voices,
\clef, \key, \time, etc.)
\music information (could be \notes (including percussion),
\chordnames or \lyrics)
I think that the \score block could possibly be eliminated if the
required information was specified in the other blocks; much of that
information would be under \form (e.g., how many staves and what
information is assigned to those staves). There could be one method
for engraving chord names and lyrics instead of multiple methods.
But it may be that there would be no practical way to separate form
information into its own block separate from note/chord information.
This sounds at least a little like the way I usually organize my
scores, though the \score block becomes necessary at least for deciding
*how* to put all of the formal and musical elements together:
%%% code snippet begins
\version 2.[whatever]
\paper {}
Form = {
% key, time, and form elements, usually referenced in an
% included file
}
Notes = {
% note information, also usually referenced in an include file
}
\score {
\new Staff
% put it all together!
\Form
\Notes
\layout {}
%\midi {}
}
%%% code snippet ends
So while there may be more graceful ways to ask for four-bar lines
(something in layout, perhaps, like \four-bar-lines = ##t? but that
brings up its own problems), it's already pretty easy separate the
formal and musical elements -- and in ways that are suggested and
supported in the official documentation.
--
Josiah Boothby
josi...@gmail.com
http://josiahboothby.org
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 12 juin 2012, at 08:35, Josiah Boothby wrote:
On Tue, 12 Jun 2012 00:22:55 -0500
Tim McNamara tim...@bitstream.net wrote:
I think that this could simplify the syntax by creating a standard
skeleton for .ly files going from most global to most specific:
\version information
\paper information
\form information (number of bars, repeat locations, bars-per-line,
rehearsal mark locations, number of staves, instruments/voices,
\clef, \key, \time, etc.)
\music information (could be \notes (including percussion),
\chordnames or \lyrics)
I think that the \score block could possibly be eliminated if the
required information was specified in the other blocks; much of that
information would be under \form (e.g., how many staves and what
information is assigned to those staves). There could be one method
for engraving chord names and lyrics instead of multiple methods.
But it may be that there would be no practical way to separate form
information into its own block separate from note/chord information.
This sounds at least a little like the way I usually organize my
scores, though the \score block becomes necessary at least for deciding
*how* to put all of the formal and musical elements together:
%%% code snippet begins
\version 2.[whatever]
\paper {}
Form = {
% key, time, and form elements, usually referenced in an
% included file
}
Notes = {
% note information, also usually referenced in an include file
}
\score {
\new Staff
% put it all together!
\Form
\Notes
\layout {}
%\midi {}
}
%%% code snippet ends
Couldn't agree more - LilyPond already has all of this. Every score I've
created since 2008 does this in some way or another. Four bars per system in
simple music? No problem.
form = {
\repeat unfold 4 { s1*4 \break }
}
music = {
\repeat unfold 64 a'4
}
\music \form
If you're not sure how long music is, you can write a music function to find
out and then automate the creating of the skips in form.
I think the issue at this point is not LilyPond's lack of ability to do this or
that, but rather the lack of a vibrant cookbook culture like Python has. This
is obviously what the LSR is trying to do but I'm not sure how effective it is
globally (I've used it for tons of stuff).
I haven't followed this thread closely but it seems like there's been a good
deal of talk about to make things easy for the user. What seems more important
(to me) is how to empower the user so that she can make things easy for
herself. That's one of the main reasons I like free software. One of my
concerns with non-free software is that by automating certain processes, they
channel people's thoughts towards a easy choices and (even worse) make people
less likely to think at all, which augments the necessity of proprietary
institutions that can think for them. It would be great if LilyPond could help
people become good thinkers about putting music together through code (any code
- Scheme, ly syntax, abjad, whatever). The extension language in question is
almost irrelevant (they all work more or less) - what really matters is the
person using it.
One day I'm going to make a tutorial site for LilyPond that focuses on the
making of actual pieces in the spirit of Urs's work. Just need time...
Cheers,
MS
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 8:57 AM, m...@apollinemike.com
m...@apollinemike.com wrote:
Couldn't agree more - LilyPond already has all of this. Every score I've
created since 2008 does this in some way or another. Four bars per system in
simple music? No problem.
form = {
\repeat unfold 4 { s1*4 \break }
}
music = {
\repeat unfold 64 a'4
}
\music \form
If you're not sure how long music is, you can write a music function to find
out and then automate the creating of the skips in form.
David Nalesnik already did this:
http://lsr.dsi.unimi.it/LSR/Item?u=1id=838
I think the issue at this point is not LilyPond's lack of ability to do this
or that,
but rather the lack of a vibrant cookbook culture like Python has.
I think you're right.
cheers,
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Janek Warchoł janek.lilyp...@gmail.com writes: David Nalesnik already did this: http://lsr.dsi.unimi.it/LSR/Item?u=1id=838 I think the issue at this point is not LilyPond's lack of ability to do this or that, but rather the lack of a vibrant cookbook culture like Python has. I think you're right. It is a bit more than that. A cookbook is nice (and we have excellent cooks here), but of more importance is a standard cook you can hand it to. Namely a sort of module system. A place where you can drop things in, call them by name, and they will come. Copypaste jobs are nice, but a standard place where things can be called from, and maintained and improved by someone else, beats that. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
2012/6/12 Jonathan Wilkes jancs...@yahoo.com: I think if Lilypondtool or Frescobaldi would allow you to click-drag some of the grobs like dynamics and markup in the preview pdf and automatically insert code to make the tweak, that would be huge. LilyPondTool already does this. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Mon, Jun 11, 2012 at 08:45:24PM -0500, Tim McNamara wrote: On Jun 10, 2012, at 10:00 PM, Ivan Kuznetsov wrote: On Mon, May 28, 2012 at 12:21 PM, Tim McNamara tim...@bitstream.net wrote: As great as Lilypond's output is, there is a long way to go in terms of simplification and usability (the syntax needs to be simplified dramatically; a lot of the code users have to write is pretty ugly and is going to scare off potential users). I don't understand how this could be possible. Does anyone talk about the need to simplify the syntax of Latex? Of Perl? Let me respond as a musician rather than as a programmer, because I am the first and I am not the second. A lot of the syntax of Lilypond makes little sense except perhaps to people used to coding. If you're a musician, the first months of trying to use Lilypond can be little more than an exercise in frustration. There are several reasons for this, including: That's an excellent write up, Tim. It describes my experience with Lilypond over the last seven years perfectly. I also agree with your analysis of why it is that way, and what is both good and bad about it. Cheers, Colin. -- Colin Hall ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Colin Hall colingh...@gmail.com writes: On Mon, Jun 11, 2012 at 08:45:24PM -0500, Tim McNamara wrote: On Jun 10, 2012, at 10:00 PM, Ivan Kuznetsov wrote: On Mon, May 28, 2012 at 12:21 PM, Tim McNamara tim...@bitstream.net wrote: As great as Lilypond's output is, there is a long way to go in terms of simplification and usability (the syntax needs to be simplified dramatically; a lot of the code users have to write is pretty ugly and is going to scare off potential users). I don't understand how this could be possible. Does anyone talk about the need to simplify the syntax of Latex? Of Perl? Let me respond as a musician rather than as a programmer, because I am the first and I am not the second. A lot of the syntax of Lilypond makes little sense except perhaps to people used to coding. If you're a musician, the first months of trying to use Lilypond can be little more than an exercise in frustration. There are several reasons for this, including: That's an excellent write up, Tim. It describes my experience with Lilypond over the last seven years perfectly. I also agree with your analysis of why it is that way, and what is both good and bad about it. I think we can do better, but it does not happen by itself. Perhaps one byproduct of my comparatively old age is that I am quite more willing to interpret it is too hard for me as it is too hard rather than I am too stupid. It is the prerequisite of youth, in particular programming youth, to get good initial return of investment for coding based on the I am too stupid angle, whereas I make as much backward as forward progress in that area. On the other hand, I have the experience for getting the it is too hard angle under control in a somewhat planned manner: while I suck at the efficiency of making every step, at least I know where I want to be going. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 10:26 AM, Francisco Vila paconet@gmail.com wrote: 2012/6/12 Jonathan Wilkes jancs...@yahoo.com: I think if Lilypondtool or Frescobaldi would allow you to click-drag some of the grobs like dynamics and markup in the preview pdf and automatically insert code to make the tweak, that would be huge. LilyPondTool already does this. wow! I wish that LilyPondTool and Frescobaldi were merged into one uber-tool. They both have awesome features, and i wish that i could have all these features together. Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 9:35 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: David Nalesnik already did this: http://lsr.dsi.unimi.it/LSR/Item?u=1id=838 I think the issue at this point is not LilyPond's lack of ability to do this or that, but rather the lack of a vibrant cookbook culture like Python has. I think you're right. It is a bit more than that. A cookbook is nice (and we have excellent cooks here), but of more importance is a standard cook you can hand it to. Namely a sort of module system. A place where you can drop things in, call them by name, and they will come. Copypaste jobs are nice, but a standard place where things can be called from, and maintained and improved by someone else, beats that. Indeed! We need a standard cookbook and a cookbook standard. I hope that GLISS will help with this. And, of course, your continous effort is angled toward these issues - i appreciate that! cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 12:03:53PM +0200, Janek Warchoł wrote: On Tue, Jun 12, 2012 at 9:35 AM, David Kastrup d...@gnu.org wrote: Janek Warchoł janek.lilyp...@gmail.com writes: David Nalesnik already did this: http://lsr.dsi.unimi.it/LSR/Item?u=1id=838 I think the issue at this point is not LilyPond's lack of ability to do this or that, but rather the lack of a vibrant cookbook culture like Python has. I think you're right. It is a bit more than that. A cookbook is nice (and we have excellent cooks here), but of more importance is a standard cook you can hand it to. Namely a sort of module system. A place where you can drop things in, call them by name, and they will come. Copypaste jobs are nice, but a standard place where things can be called from, and maintained and improved by someone else, beats that. I guess that you mean something akin to http://www.cpan.org/ http://www.ctan.org/search/ Regards, Gilles Indeed! We need a standard cookbook and a cookbook standard. I hope that GLISS will help with this. And, of course, your continous effort is angled toward these issues - i appreciate that! cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
2012/6/12 Janek Warchoł janek.lilyp...@gmail.com: LilyPondTool already does this. wow! It's called the ruler tool and it allows this: http://lists.gnu.org/archive/html/lilypond-user/2010-02/msg00150.html The code won't work unmodified on current LP but you get the idea. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Jun 12, 2012, at 1:28 AM, Janek Warchoł wrote: On Tue, Jun 12, 2012 at 3:45 AM, Tim McNamara tim...@bitstream.net wrote: Let me respond as a musician rather than as a programmer, because I am the first and I am not the second. A lot of the syntax of Lilypond makes little sense except perhaps to people used to coding. If you're a musician, the first months of trying to use Lilypond can be little more than an exercise in frustration. There are several reasons for this, including: [..] Do you know about GLISS (http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#grand-lilypond-input-syntax-standardization-_0028gliss_0029)? It's planned for this summer (never mind obsolete dates in Contributors' Guide), and it may help with many of your (valid) concerns. I hope that you'll help by participating in (maybe organizing some?) discussions. Thank you, Jaenk. I had heard a bit about GLISS but had not paid close attention. I will read up on it. Btw, have you read my articles in previous LilyPond Report? http://news.lilynet.net/?The-LilyPond-Report-25#lilypond_s_future http://news.lilynet.net/?The-LilyPond-Report-25#working_with_lilypond_a_personal_experience I have not been consistent with reading the LP Report, so I will read up on that too. Tim ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Jun 12, 2012, at 1:15 AM, Werner LEMBERG wrote: I think that this could simplify the syntax by creating a standard skeleton for .ly files going from most global to most specific: \version information \paper information \form information (number of bars, repeat locations, bars-per-line, rehearsal mark locations, number of staves, instruments/voices, \clef, \key, \time, etc.) \music information (could be \notes (including percussion), \chordnames or \lyrics) It would be great if you could work out a small piano piece with, say, 16 bars, using your suggested syntax. Werner, that is an eminently practical idea that I had not thought about. It's easy to be abstract, it's harder to be specific. I have a Bill Evans chart arranged for my combo that might suite the need easily. Of course, it would not compile but for this exercise that would not be necessary. I will work on this and hope to have something by the end of the week. Tim ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
- Original Message - From: Francisco Vila paconet@gmail.com To: Jonathan Wilkes jancs...@yahoo.com Cc: lilypond-user@gnu.org lilypond-user@gnu.org Sent: Tuesday, June 12, 2012 4:26 AM Subject: Re: Appreciation / Financial support 2012/6/12 Jonathan Wilkes jancs...@yahoo.com: I think if Lilypondtool or Frescobaldi would allow you to click-drag some of the grobs like dynamics and markup in the preview pdf and automatically insert code to make the tweak, that would be huge. LilyPondTool already does this. Click-dragging to generate code is different from click-dragging, clicking, selecting a context from a long list for which the default has no relationship to what I just clicked, selecting a grob from a long list for which the default has no relationship to what I just clicked, selecting a property, then clicking write to score. Then doing it again for every grob I want to move even if they are all, say, dynamic scripts, because the dialog window resets each time. Having the dialog window remember my settings would go a long way to making the tool more useful. -Jonathan -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Am 12.06.2012 08:57, schrieb m...@apollinemike.com:
form = {
\repeat unfold 4 { s1*4 \break }
}
music = {
\repeat unfold 64 a'4
}
\music \form
Actually this doesn't work. You will need something like this:
music = \relative c'' {
\repeat unfold 8 { a4 b c d e d c b }
}
\oneVoice \music \\ \form
This doesn't look as easy as what you provided. But the idea to divide
form and music is still valid.
Helge
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Tim McNamara wrote: I think that this could simplify the syntax by creating a standard skeleton for .ly files going from most global to most specific: \version information \paper information \form information (number of bars, repeat locations, bars-per-line, rehearsal mark locations, number of staves, instruments/voices, \clef, \key, \time, etc.) \music information (could be \notes (including percussion), \chordnames or \lyrics) As a programmer first and musician second, I have a deep appreciation (awe is more like it) for how LilyPond got to where it is. Computers deal with very strict rules. Humans, when writing out music, apply rules very loosely. We stretch things, we abbreviate, we shift things around for dubious reasons, we make up new symbols, we assign new meaning to old symbols, we apply titling rules that make sense to us at the time. And yet, everyone wants LilyPond to engrave exactly what they were writing out by hand. In virtually every case, LilyPond can do that, but that immense flexibility means complexity. If we were willing to have LilyPond become the music police, so that it engraved a specific, approved subset of the myriad rules that have been applied to engraving over time, it would certainly be possible to simplify the syntax considerably. Would that make users happy? I don't think it would. And so, you have to be able to support numbering every measure on top, numbering every measure below, numbering every 5th measure, numbering every 8th measure, numbering only at the start of each system, numbering every staff, numbering some staves, boxing the numbers, circling the numbers, italicizing the numbers, skipping the number when there is a rehearsal mark, or not, etc. Every individual will say well, of course it needs to support X!, but everyone's X will be different. The same applies to layout. Each movement on a separate page? Multiple movements on a page? New movements indented, or not? Different titles on each movement? Different titles on each page? Suppress some titles on certain pages? One huge long system like a piano roll? Again, LilyPond can do ALL of that. It's not entirely clear you could retain that flexibility and still simplify the syntax significantly. That's the problem. Any new scheme must embrace what has already been done. That virtually guarantees there are going to be multiple ways to specify things. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 7:14 PM, Helge Kruse helge.kruse-nos...@gmx.net wrote:
Am 12.06.2012 08:57, schrieb m...@apollinemike.com:
form = {
\repeat unfold 4 { s1*4 \break }
}
music = {
\repeat unfold 64 a'4
}
\music \form
Actually this doesn't work. You will need something like this:
music = \relative c'' {
\repeat unfold 8 { a4 b c d e d c b }
}
\oneVoice \music \\ \form
...but without \\. You don't want to have \music typeset as first
voice (upstemmed).
cheers,
Janek
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 12/06/12 07:30, Janek Warchoł wrote: On Tue, Jun 12, 2012 at 7:49 AM, Jonathan Wilkesjancs...@yahoo.com wrote: I think if Lilypondtool or Frescobaldi would allow you to click-drag some of the grobs like dynamics and markup in the preview pdf and automatically insert code to make the tweak, that would be huge. +1 Wilbert (author of Frescobaldi) said this should be possible to do. That's fantastic to hear, and would solve one of the key usability issues of LilyPond. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Mon, May 28, 2012 at 12:21 PM, Tim McNamara tim...@bitstream.net wrote: As great as Lilypond's output is, there is a long way to go in terms of simplification and usability (the syntax needs to be simplified dramatically; a lot of the code users have to write is pretty ugly and is going to scare off potential users). I don't understand how this could be possible. Does anyone talk about the need to simplify the syntax of Latex? Of Perl? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Ivan Kuznetsov ivan.k.kuznet...@gmail.com writes:
On Mon, May 28, 2012 at 12:21 PM, Tim McNamara tim...@bitstream.net wrote:
As great as Lilypond's output is, there is a long way to go in terms
of simplification and usability (the syntax needs to be simplified
dramatically; a lot of the code users have to write is pretty ugly
and is going to scare off potential users).
I don't understand how this could be possible. Does anyone talk
about the need to simplify the syntax of Latex?
Sure. URL:http://www.latex-project.org/latex3.html
Of Perl?
Perl is a programming language, not an application and large-scale
programming project. Nobody here talks about the need to simplify the
syntax of Scheme. It's take it or leave it (with some people suggesting
leaving it). The question of simplify is rather how to tie concepts
of LilyPond together with Scheme, and how to improve the LilyPond
language itself, either in its connections with the lower language
layers, or viewed on its own.
As one example, once you could write
\midi { \tempo 4 = 60 }
Then you had to do something like
\midi { \context { \Score
tempoWholePerMinutes = #(ly:make-moment 240 4) } }
(don't quote me on the details) because otherwise you would be
confusing music syntax with context definitions, and nowadays you can
write
\midi { \tempo 4 = 60 }
which actually _is_ music _converted_ to a context definition and does
the same thing as it did a long time ago, only totally differently.
What do you want to read in a score? The first version was a strange
exception, the second version was pretty much straightforward, and the
third version requires a whole complex conversion mechanism.
If you try debugging this, the first versions are similarly complex
(rather straightforward) and the third version is really contorted.
Version 1 could be seen in the parser, but is a one-shot exception.
Version 2 can be followed from its own logic and is pretty
straightforward. Version 3 is a consequence of rather strange rules and
commands, and it is not easy to see how the music ends up becoming a
context modification after all.
So what? It expresses intent in a natural way. Probably in a way
appearing obscene to a programmer, but unremarkable to a musician.
Is it a simplification of syntax? Yes and no.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Can anyone recommend a book or website for learning Scheme as it currently exists in Lilypond? So that I won’t start using deprecated features or whatever. I’m fluent in Lua (which I like a lot). I found Kent Dybvig's book to be useful and readable: http://scheme.com/tspl4/. Scheme as it currently exists in Lilypond is Guile, but I believe Guile agrees with Scheme R6RS (except for the short list documented here http://www.gnu.org/software/guile/manual/guile.html#R6RS-Incompatibilities). Lilypond's particular usage of Guile also may have its own traditions and quirks with which I'm not very familiar at the moment. Nevertheless, I believe becoming familiar with the basics of Scheme is immensely (intellectually, plus in this case practically) rewarding and well worth the effort, and I don't think it's a large effort. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Jun 10, 2012, at 10:00 PM, Ivan Kuznetsov wrote: On Mon, May 28, 2012 at 12:21 PM, Tim McNamara tim...@bitstream.net wrote: As great as Lilypond's output is, there is a long way to go in terms of simplification and usability (the syntax needs to be simplified dramatically; a lot of the code users have to write is pretty ugly and is going to scare off potential users). I don't understand how this could be possible. Does anyone talk about the need to simplify the syntax of Latex? Of Perl? Let me respond as a musician rather than as a programmer, because I am the first and I am not the second. A lot of the syntax of Lilypond makes little sense except perhaps to people used to coding. If you're a musician, the first months of trying to use Lilypond can be little more than an exercise in frustration. There are several reasons for this, including: 1. Inconsistency between what is needed for coding things that need to be on the page. I can put in a barline with \bar and a very descriptive set of options (|: || :| |. etc.). There is a simple visual logic to this that is excellent. The use of pitch and duration is likewise very simple and understandable such as c1, d2, e4 f8, g16, etc. It takes seconds to grasp the syntax; ditto how chords are written out with something like c e g b1 which is easily grasped. OTOH, if I want to put in rehearsal marks like section marks, codas, segnos, etc., the syntax is obtuse. It seems like I should be able to just use \coda, \segno, etc. But that's not the syntax Lilypond uses, the syntax is much more verbose and therefore easy to screw up- and one screw up kills the whole compilation. There is another issue there with needing simple and comprehensible error reporting to help users find the thing they screwed up. 2. Then there is the whole dealing with repeats and voltas and getting all the parentheses right. How a score is structured is not intuitive in Lilypond. It is not all that easy to make Lilypond to do things like setting four bars to the line (something jazz musicians tend to like). Things like glyphs and such are located by time rather than by structure, which is often backwards to how composers work on a manuscript- when I start with pen and paper, I usually start with sketching out the structure of the song before the melody ever gets written down; in Lilypond one cannot really do this. One result of this is that some things end up in funny, unexpected places. Codas placed at the end of a line used to go to the start of the next line if there was a \break; I don't recall offhand if that still happens. Surely someone thought there was a good reason for this but it frustrated me to no end when the damn coda didn't stay where I put it and ended up in the wrong place- because I use \break in every score in order to force four bars to the line- which rendered the chart incorrect for the musicians (there is a workaround for this, but IMHO it shouldn't be necessary). 3. There are too many valid ways of structuring a .ly file. A flexible syntax can be a good thing, but there are too many ways in which a .ly file can be organized and still have it compile correctly. This makes it hard to learn. There should be a logical flow to the syntax and how it is structured; good syntax should be enforced. Of course, we'd probably all have different ways defining good syntax. I am amazed at the variety of what I see when people post files, and most of them compile just fine! I may be seeing a problem where where there really isn't one, but it seems to me that in the long run a standardized .ly file structure will be easier to learn. 4. There are hundreds of pages of documentation and it can be very hard to find the information one needs in order to accomplish the task at hand. And searching either the web version or the PDF version does not always yield the needed information. Why is it like this? Because the focus of Lilypond has been, to a great degree, to create something that enables users to produce beautiful sheet music. That is the raison d'être of Lilypond. The main focus has not been on user friendliness and easy useability. As a result, a total of zero of the dozen or so musicians/composers I have tried to turn on to Lilypond have taken it up. They downloaded it, saw it is impossibly difficult, and went to something else. BTW, most of these are people with doctorates, medical degrees, MBAs, etc. They are computer savvy and they are not dumb. The user interface (like it or not, the *syntax* is the user interface- the text editor chosen by the user is not the user interface for Lilypond) is too beginner-unfriendly. Now, maybe that's OK- it may not be necessary to reach millions of users; maybe it's OK to focus on the users who will persevere through the steep learning curve and obscure commands and sometimes difficult syntax. Maybe it's OK to focus first and
Re: Appreciation / Financial support
Music notation is complex. Any ASCII representation of music notation likewise has to be complex. Any simplification of lilypond syntax must mean a removal of features. The only other alternative is to use a WYSIWYG editor where you draw the musical notation you want, and good luck waiting for an flexible open-source version of such a program with quality output. Or maybe Frescobaldi will someday evolve to something like this, I have yet to investigate the interface. P.S. Perl was a bad example, but the latex comparison was valid. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Hi TIm, I agree with much of what you said. However It is not all that easy to make Lilypond to do things like setting four bars to the line (something jazz musicians tend to like). That's pretty darned simple now — check the archives for more details. =) Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Tim McNamara tim...@bitstream.net writes: Why is it like this? Because the focus of Lilypond has been, to a great degree, to create something that enables users to produce beautiful sheet music. That is the raison d'être of Lilypond. The main focus has not been on user friendliness and easy useability. As a result, a total of zero of the dozen or so musicians/composers I have tried to turn on to Lilypond have taken it up. They downloaded it, saw it is impossibly difficult, and went to something else. BTW, most of these are people with doctorates, medical degrees, MBAs, etc. They are computer savvy and they are not dumb. The user interface (like it or not, the *syntax* is the user interface- the text editor chosen by the user is not the user interface for Lilypond) is too beginner-unfriendly. Now, maybe that's OK- it may not be necessary to reach millions of users; maybe it's OK to focus on the users who will persevere through the steep learning curve and obscure commands and sometimes difficult syntax. Maybe it's OK to focus first and foremost on great output. But it might be OK to focus on making Lilypond easier to learn and use for non-programmers. Indeed, I think that this is part of what David is talking about working towards. That's the impression I get as well. I think a part of the difficulty is that in this situation it is absolutely necessary for those creating the core code of Lilypond to program it backwards - to write their code according to what users want to *type*, and _not_ according to the end result that those users want to *accomplish*. Coding according to what your users want to type must be a ridiculously inefficient and irritating way for a programmer to have to work. It's unfortunately also the only way Lilypond can suffice for more than a few people. David Kastrup gave a good example of this earlier, showing how the midi block has been changed over time. To a programmer, the current easy-to-use Lilypond syntax for obtaining midi output is (apparently) an illogical kludge. Needless to say, it doesn't look that way to a non-programmer. -- David R ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Jun 11, 2012, at 9:21 PM, Ivan Kuznetsov wrote: Music notation is complex. Any ASCII representation of music notation likewise has to be complex. Hmm, it would be more accurate to say music notation *can* be complex. It can also be very simple. I use Lilypond for creating jazz lead sheets; simplicity of presentation is very important. Music notation does two essential and necessary things. It specifies pitch information and time information: what note is played and how long it is held. Lilypond's syntax makes that pretty easy to express in text: c1 d2 e4 f8 g16, etc. Indeed, it is as simple a way to express musical notation as possible in a text format. Brilliant! This is not the problem. IMHO at least part of the problem is how the structure of scores is specified in Lilypond's syntax. The placement of every structural item (bar lines, repeats, alternate endings, sections, etc.) is specified by being tied to time values rather than the structure being a set of values that can be described independently of the notes. Instead of a 32 bar form being specified as a 32 bar form, it is specified as being 128 beats and the barlines are placed by Lilypond counting beats. Now, because computer programs do not operate like human brains there may be no practical alternative. I think I'd like to see the structure of the score (number of bars in the form, bars per line, placement of repeats, section marks, etc.) be specified in its own block, which would then allow the block(s) for musical information to be devoted only to that information (pitch, duration and expression such as accents, falls, doits, bends, slurs, crescendo/decrescendo, etc.). I think that this could simplify the syntax by creating a standard skeleton for .ly files going from most global to most specific: \version information \paper information \form information (number of bars, repeat locations, bars-per-line, rehearsal mark locations, number of staves, instruments/voices, \clef, \key, \time, etc.) \music information (could be \notes (including percussion), \chordnames or \lyrics) I think that the \score block could possibly be eliminated if the required information was specified in the other blocks; much of that information would be under \form (e.g., how many staves and what information is assigned to those staves). There could be one method for engraving chord names and lyrics instead of multiple methods. But it may be that there would be no practical way to separate form information into its own block separate from note/chord information. Any simplification of lilypond syntax must mean a removal of features. With all due respect, that is IMHO incorrect. Lilypond's syntax could be simplified through pursuing elegance while retaining power. In short, harder to use != more power. I can see no reason to be opposed to making Lilypond's input as attractive as its output- that is in many ways a more difficult task, however, because it's squishier than coding the processes that take the text and produce the score. Squishy stuff is difficult for a lot of reasons. One goal would be to remove redundant features, which reduces the complexity of the application code and improves its maintainability, and to make input streamlined. For example, do we need multiple ways to put in lyrics? (Maybe we do for reasons I don't understand). IMHO an economical syntax is easier to learn, is easier to type without errors, and probably easier to compile although I wouldn't know about that part. It seems self-defeating to say that we can't simplify and make the input method more elegant and even intuitive. It seems silly to me that we need hundreds of pages of documentation plus an online snippet repository. In terms of power, BTW, there would be no reason to remove Lilypond's Scheme interpreter which would allow for extending Lilypond as needed. Of course, I could be all wet. The only other alternative is to use a WYSIWYG editor where you draw the musical notation you want, and good luck waiting for an flexible open-source version of such a program with quality output. The closest is Musescore. http://musescore.org/ It has drawbacks in the quality of the output, to my eye, although it is generally better than many Finale things I have suffered through. I've tried Musescore, it's easy to use and it may be possible that the output can be tweaked to look really nice. I haven't felt like messing around with it because I've got so much time invested in learning Lilypond. Or maybe Frescobaldi will someday evolve to something like this, I have yet to investigate the interface. P.S. Perl was a bad example, but the latex comparison was valid. The LaTeX comparison is apt, given that it has the same goal as Lilypond: the rendering of a page of well-formatted and fluently shaped information. I've never bothered with it, a word processor is a much more practical
Re: Appreciation / Financial support
Message: 7 Date: Mon, 11 Jun 2012 21:21:08 -0500 From: Ivan Kuznetsov ivan.k.kuznet...@gmail.com To: Tim McNamara tim...@bitstream.net Cc: lilypond-user Users lilypond-user@gnu.org Subject: Re: Appreciation / Financial support Message-ID: caasqlbw+e4rk81trxcvdbxoe9i4_brzz7+gwk1miarsuhvg...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Music notation is complex. Any ASCII representation of music notation likewise has to be complex. Any simplification of lilypond syntax must mean a removal of features. The only other alternative is to use a WYSIWYG editor where you draw the musical notation you want, and good luck waiting for an flexible open-source version of such a program with quality output. See Musescore. It uses Lilypond's Feta Font and has the look and feel of Sibelius. Or maybe Frescobaldi will someday evolve to something like this, I have yet to investigate the interface. I think if Lilypondtool or Frescobaldi would allow you to click-drag some of the grobs like dynamics and markup in the preview pdf and automatically insert code to make the tweak, that would be huge. (Plus maybe some way to click-drag an entire system to tweak vertical spacing, though after looking at the notation manual I have no idea how that could be achieved.) -Jonathan P.S. Perl was a bad example, but the latex comparison was valid. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 12, 2012 at 12:22:55AM -0500, Tim McNamara wrote: On Jun 11, 2012, at 9:21 PM, Ivan Kuznetsov wrote: Any simplification of lilypond syntax must mean a removal of features. With all due respect, that is IMHO incorrect. Lilypond's syntax could be simplified through pursuing elegance while retaining power. Agreed. That's what's planned for GLISS, which has been on the books for ages but is currently expected to start in July. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 07/06/12 05:24, David Kastrup wrote: You picked a _Scheme_ function, not a music function. That does not, I repeat _not_ at all show how you embed this thing into your LilyPond code, and we were talking about using D as an _extension_ language of LilyPond, not about its usefulness as a general purpose programming function. I don't see any point in simply embedding D as an alternative scripting language to Scheme, and I'm not proposing that. Rather, in my original post I was introducing D as a language that could be used to code all levels of LilyPond, from low-level internals to high-level stuff all the way up to scripts embedded in LilyPond input files. That seems a pretty reasonable input to a discussion where the technology and architectural choices of LilyPond were being debated, and one of LilyPond's original authors had written: That's nice but still does not show how you would embed D for the high-level stuff all the way up to scripts embedded in LilyPond input files. I have only a very basic familiarity with Go, but if the intention would be to do a rewrite from the ground up, using a language that provides the features described here, then D would be a strong contender. You have not shown how this would work at user-level scripting. The kind of stuff where cutpaste of Scheme snippets or creating music functions works. As I already said: the examples in scm/* don't interface with the user/LilyPond level: you have to look at ly/* for that. I'm not asking anyone to do that rewrite. I'm simply pointing out that a possibly useful language choice exists, should a bottom-up rewrite be considered, and I tried to illustrate the general features that I think make it useful. If that information is useful to anyone -- great. If not -- let's move on. You are evading the embedding question. I am not saying it would be impossible to tackle. But it is _crucial_ to the success of the whole. It is the main reason we have a Scheme layer in the first place rather than just the original C++. Then there's a somewhat different discussion, which is the accessibility of Scheme as a scripting language. If you want to argue that the accessibility issue is outweighed by the power and flexibility of the language, that's fine. Yes and no. We don't really utilize Scheme's potential here at the current point of time. Music transformations (including transforming music into displayed form and MusicXML and unfolding repeats and other things) could be done using tools like URL:http://www.gnu.org/software/guile/manual/html_node/Pattern-Matching.html. We don't do that right now, and using music terms as non-native C++ constructs rather than accessible through records/Goops does not help. If you take a look at scm/define-music-display-methods.scm you'll see that there _is_ some home-brewn pattern matching going on that would not be easy to do in most other languages, but it is not the same as being able to use standard facilities, and it is just used for display and nowhere else in the LilyPond code base. I am not sure I disagree with you. But that doesn't alter the fact that its syntax and style is very different from the mainstream languages that users and potential new contributors are more likely to be familiar with. New contributors are familiar with music and LilyPond input. The principal source of contributors are musicians, not programmers. C++ is much more mainstream, and will you claim that we have more people working with the C++ parts of LilyPond than with the Scheme parts? Working with the internals is going to be heavy-duty no matter what the programming language. On the other hand it's a reasonable concern (raised by someone other than me) that if too much of the internals is rewritten in Scheme, it may be difficult to secure new contributors to the codebase. Straw man. The principal target is making stuff accessible from Scheme, not rewriting it. How many people extend LaTeX writing Pascal code rather than TeX code? Which if Pascal and TeX is the more mainstream language? Which is saner? That's so far from being even competitive that it isn't funny. ... and TeX work is confined to a fairly small hardcore group, with the mainstream of publishing moving on to other technologies. ls -R /usr/local/texlive/2011/|wc -l 115785 First let us get there, then worry. Besides, TeX has the advantage that when it was introduced it provided something that wasn't really available before, so it attracted input (both amateur and commercial) by virtue of being the only real show in town, and so built up a weight of add-on functionality that kept it relevant. So does LilyPond. Care to name another scriptable batch typesetting system for music? You can say something similar about your other example, Emacs and its extension language. It was offering new functionality; when it first
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Please. Stop. This discussion is going nowhere. And David can use his badly-paid time better for enhancing LilyPond than for discussing ideal worlds that never will happen. Whoever believes to know better than our currently most active programmer should come up with some useful code. Greetlings, Hraban --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net http://angerweit.tikon.ch/lieder/ https://www.cacert.org (I'm an assurer) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Henning Hraban Ramm hra...@fiee.net writes: Please. Stop. This discussion is going nowhere. And David can use his badly-paid time better for enhancing LilyPond than for discussing ideal worlds that never will happen. Actually, I am not as much discussing ideal worlds rather than the misconception that switching languages is all that it takes to arrive at them. Instead, we need a good system architecture. If you take a look at real architecture, it is obvious that you can't build skyscrapers like sandcastles. If you talk with hut builders, you'll find that straw and loam make for much better building material than sand. And yet you'll find a conspicuous absence of straw in skyscrapers, while sizeable amounts of sand can be found in their concrete. The architecture of LilyPond needs work to become more user-accessible. No question about that. But switching languages will not do wonders for that. Like sand, I consider Scheme as solid enough and flexible enough when used right. Whoever believes to know better than our currently most active programmer should come up with some useful code. If I were to rewrite LilyPond from scratch, I don't know what I would pick. Scheme and in particular Guile have advantages and disadvantages. I am currently looking at Goops, an object-oriented layer on top of Scheme. It introduces a different style of data structures and thinking about them, but yet is very much in the Scheme spirit. One of the problem of Scheme (and also Goops) is that it offers a lot of raw power, but that there is not really much like a standard coding style when going to more complex tasks. And you can invent anything you like is much more strenuous for people than you have established idioms for about anything you like. I am still working on figuring out a lot of how do you do X if you are a genius questions since answering them is a prerequisite to creating answers to the question how can you hope to do X if you are not a genius. There are pieces written not for, but against the violin. I admire the Bach violin partitas and sonatas because they are the opposite: they are really hard stuff, but the toughness is not self-serving. You have large passages where it is not necessary to insert any fingering instructions, because there is just one fingering that actually makes sense. I have little doubt that Bach would have been a good programmer. The stuff he wrote makes sense, and actually a lot of it still makes sense when played on a different instrument. It's astonishing how well some of the violin solo pieces transfer to lute or guitar. In some manner, the discussion about the optimal programming language is comparable to a discussion about the optimal music instrument. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 10/06/12 08:14, David Kastrup wrote: The discussion is not useful. It distracts from work needing to get done, without offering perspectives that are actually feasible since they are neither thought through nor have the resources for tackling them _if_ they made sense and were planned out. Fair enough. I'm happy to respond to any of the technical queries you've raised, if that would ever become relevant in future, but I'll bow out here. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Am 2012-06-10 um 11:58 schrieb David Kastrup: Henning Hraban Ramm hra...@fiee.net writes: Please. Stop. This discussion is going nowhere. And David can use his badly-paid time better for enhancing LilyPond than for discussing ideal worlds that never will happen. The architecture of LilyPond needs work to become more user- accessible. No question about that. But switching languages will not do wonders for that. Like sand, I consider Scheme as solid enough and flexible enough when used right. Dear David, I guess I understood what you wanted to say one of the first times. I kept quiet since. I see no sense in continuing this discussion. All the best, Hraban ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 07/06/12 05:24, David Kastrup wrote: You picked a _Scheme_ function, not a music function. That does not, I repeat _not_ at all show how you embed this thing into your LilyPond code, and we were talking about using D as an _extension_ language of LilyPond, not about its usefulness as a general purpose programming function. I don't see any point in simply embedding D as an alternative scripting language to Scheme, and I'm not proposing that. Rather, in my original post I was introducing D as a language that could be used to code all levels of LilyPond, from low-level internals to high-level stuff all the way up to scripts embedded in LilyPond input files. That seems a pretty reasonable input to a discussion where the technology and architectural choices of LilyPond were being debated, and one of LilyPond's original authors had written: If I would re-do it, I would do so in a language where you can write have the data be inside native classes, and automate generating methods (setters, getters) and hooks (property callbacks), such that the core program wouldn't need to be aware of the scripting language. Then you could make (multiple!) scripting language bindings against those data, without having to integrate the language throughout. I personally have become very enamored with Go (golang.org), btw. Sometimes I wonder how LilyPond would turn out if I started it from scratch today. I have only a very basic familiarity with Go, but if the intention would be to do a rewrite from the ground up, using a language that provides the features described here, then D would be a strong contender. I'm not asking anyone to do that rewrite. I'm simply pointing out that a possibly useful language choice exists, should a bottom-up rewrite be considered, and I tried to illustrate the general features that I think make it useful. If that information is useful to anyone -- great. If not -- let's move on. Then there's a somewhat different discussion, which is the accessibility of Scheme as a scripting language. If you want to argue that the accessibility issue is outweighed by the power and flexibility of the language, that's fine. I am not sure I disagree with you. But that doesn't alter the fact that its syntax and style is very different from the mainstream languages that users and potential new contributors are more likely to be familiar with. The principal source of contributors are musicians, not programmers. C++ is much more mainstream, and will you claim that we have more people working with the C++ parts of LilyPond than with the Scheme parts? Working with the internals is going to be heavy-duty no matter what the programming language. On the other hand it's a reasonable concern (raised by someone other than me) that if too much of the internals is rewritten in Scheme, it may be difficult to secure new contributors to the codebase. How many people extend LaTeX writing Pascal code rather than TeX code? Which if Pascal and TeX is the more mainstream language? Which is saner? That's so far from being even competitive that it isn't funny. ... and TeX work is confined to a fairly small hardcore group, with the mainstream of publishing moving on to other technologies. Besides, TeX has the advantage that when it was introduced it provided something that wasn't really available before, so it attracted input (both amateur and commercial) by virtue of being the only real show in town, and so built up a weight of add-on functionality that kept it relevant. You can say something similar about your other example, Emacs and its extension language. It was offering new functionality; when it first appeared, LISP was a much more mainstream language than it is now; and both then and now, its target user base is hard-core programmers, for whom LISP and its variants are very likely to be something they are either already familiar with or readily able to learn. LilyPond doesn't have those advantages. In terms of what it provides -- computer-based musical engraving -- it's preceded by multiple alternatives, including SCORE, Finale and Sibelius. In terms of the surrounding programming environment, LISP was no longer at the heart of mainstream programming when LilyPond was introduced, and is even less so now. In terms of user base, it's intended for musicians (who if they have encountered programming at all will probably have done so through a current mainstream language like C/C++, Java, PHP, JavaScript etc.), and music publishers (who probably don't know how to program, and if they need to hire programmers they will probably only be able to get hold of people versed in mainstream languages). That means LilyPond has much less stature to persuade others to adopt an unfamiliar or non-mainstream syntax for scripting. So while for now Scheme is the scripting language, in the event of a major, bottom-up rewrite it might be worth reconsidering the language
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On Jun 6, 2012, at 6:22 PM, Joseph Rushton Wakeling wrote: On 05/06/12 08:53, David Kastrup wrote: I would doubt that this would have been the fault of Scheme. More likely a problem of the Scheme/LilyPond interface choices, but those choices don't go away when replacing Scheme. No, it was the fault of the unfamiliar Scheme syntax. A colleague used to working with Scheme was able to solve the problems I encountered trivially without reference to anything LilyPond-specific. Hmm. The way you wrote that, it appears that the fault is not with Scheme but the with one's unfamiliarity with Scheme. This is certainly *my* problem with understanding the Scheme-based extensions in Lilypond. And yet when I look at them I can intuit some sense of the structure and processes of the extensions (I have a little experience with eLisp, which helps just slightly). Despite all the parentheses which do make one feel a bit cross-eyed, Scheme is designed to be a simple and quickly learned language which is firmly grounded in the principles of good computer programming- one of the reasons it is used in teaching beginning programmers at MIT. using pretty-printing makes the syntax a bit easier for humans to read. The first few chapters of SICP would probably be very helpful. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html There is also HTDP which is Scheme based (although they now call their specific version Racket). http://www.htdp.org/ In the early chapters, which is all the farther I have gotten, SICP is more about Scheme programming and HTDP is more about the general process of thinking about what computer programs accomplish and how to design the logic to achieve that goal. So far I am not managing to learn the syntax rules in an afternoon, though. :-( But then I am 52 and don't learn as quickly as I once did, and my only computer programming class was one semester of a general ed course which included only Fortran and punch cards ca. 1979. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 07/06/12 14:54, Tim McNamara wrote: Hmm. The way you wrote that, it appears that the fault is not with Scheme but the with one's unfamiliarity with Scheme. This is certainly *my* problem with understanding the Scheme-based extensions in Lilypond. And yet when I look at them I can intuit some sense of the structure and processes of the extensions (I have a little experience with eLisp, which helps just slightly). Despite all the parentheses which do make one feel a bit cross-eyed, Scheme is designed to be a simple and quickly learned language which is firmly grounded in the principles of good computer programming- one of the reasons it is used in teaching beginning programmers at MIT. using pretty-printing makes the syntax a bit easier for humans to read. The first few chapters of SICP would probably be very helpful. Well, it's that unfamiliarity that I'm talking about, really. My point isn't that Scheme is bad in itself but that using it means that virtually _everyone_ wanting to script or work on LilyPond has to learn a new language, syntax and set of programming paradigms, even if they are already programmers; because apart from computer science students, most people don't learn LISP dialects. This isn't a bad thing to have to do in terms of one's programming experience and education but it _is_ a potential barrier to entry for LilyPond, which I think might be avoidable. The links are useful -- thanks for sharing! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: Well, it's that unfamiliarity that I'm talking about, really. My point isn't that Scheme is bad in itself but that using it means that virtually _everyone_ wanting to script or work on LilyPond has to learn a new language, syntax and set of programming paradigms, even if they are already programmers; because apart from computer science students, most people don't learn LISP dialects. This isn't a bad thing to have to do in terms of one's programming experience and education but it _is_ a potential barrier to entry for LilyPond, which I think might be avoidable. I think that a larger barrier is actually the use of features like modules in a non-documented and non-obvious way. That's not the fault of Scheme or Guile per se. It is still definitely a barrier since you can read up all the Guile/Scheme documentation you want to without getting much wiser about how these things interact with LilyPond. There is a _lot_ of barriers involved, and quite a few that suck royally. But changing language would, in my opinion, do rather little to address that. One thing that's on my black list of uglinesses is the markup system together with the markup macro. This is non-robust, and interacts with the module system and interpretation timing in non-trivial ways. It's one of those things that you can do in Scheme quite better (or at all) than in many other languages, but where resisting the temptation would have paid off. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 07/06/12 17:31, David Kastrup wrote: I think that a larger barrier is actually the use of features like modules in a non-documented and non-obvious way. Can you explain this in greater detail? Would be useful to understand this better before replying to your earlier, longer message on the Scheme vs. D code. There is a _lot_ of barriers involved, and quite a few that suck royally. But changing language would, in my opinion, do rather little to address that. I'm not trying to pressure you to change the language in the short term. What I am trying to do is to get you to give some long-term consideration towards some of the emerging languages which might offer a way to unify the internals, high-level stuff and scripting language, and _at the same time_ offer useful new language features and a friendlier language syntax. I'm not asking or expecting you to be convinced straight away, though. :-) One thing that's on my black list of uglinesses is the markup system together with the markup macro. This is non-robust, and interacts with the module system and interpretation timing in non-trivial ways. It's one of those things that you can do in Scheme quite better (or at all) than in many other languages, but where resisting the temptation would have paid off. Again, can you explain in a little more detail? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 07/06/12 17:31, David Kastrup wrote: I think that a larger barrier is actually the use of features like modules in a non-documented and non-obvious way. Can you explain this in greater detail? Would be useful to understand this better before replying to your earlier, longer message on the Scheme vs. D code. It has nothing to do with Scheme vs D. Look in the LilyPond internals manual for everything containing module. There is a _lot_ of barriers involved, and quite a few that suck royally. But changing language would, in my opinion, do rather little to address that. I'm not trying to pressure you to change the language in the short term. What I am trying to do is to get you to give some long-term consideration towards some of the emerging languages which might offer a way to unify the internals, high-level stuff and scripting language, and _at the same time_ offer useful new language features and a friendlier language syntax. I'm not asking or expecting you to be convinced straight away, though. :-) With all due respect: I've been a system programmer for more than 30 years, have written stuff in dozens of different languages including writing object-oriented message passing stuff in assembly language (of which I know maybe a dozen, some including all the cycle counts at one time). I've written complete systems including all the firmware and compiled them with target compilers I wrote myself, bootstrapping them on systems I wrote myself. I know my way around compilers, systems and programming languages. If convincing me straight away does not work, bringing in significant amounts of new information for changing that is not likely going to be as easy as you apparently think. One thing that's on my black list of uglinesses is the markup system together with the markup macro. This is non-robust, and interacts with the module system and interpretation timing in non-trivial ways. It's one of those things that you can do in Scheme quite better (or at all) than in many other languages, but where resisting the temptation would have paid off. Again, can you explain in a little more detail? The Extending LilyPond guide has sections about markup and markup list commands and the markup macro. What are you going to bring up for the sake of convincing me when I know the weaknesses of the system better than you do? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 8/06/2012, at 1:54 am, Tim McNamara wrote: The first few chapters of SICP would probably be very helpful. http://mitpress.mit.edu/sicp/full-text/book/book-Z-H-10.html SICP does for computer programming what Linderholm's classic 'Mathematics Made Difficult' does for arithmetic -- except that in this case the authors are entirely serious. Best wishes, Matthew ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 8 June 2012 07:44, Matthew Collett m_coll...@ihug.co.nz wrote: SICP does for computer programming what Linderholm's classic 'Mathematics Made Difficult' does for arithmetic -- except that in this case the authors are entirely serious. It didn’t seem too scary to me, or at least the start of it... As far as I can tell, Scheme seems to be a good language, but not popular. But we musicians know that the relationship between ‘good’ and ‘popular’ is not simple. And Scheme is the language of Lilypond, for better or worse. To work in Germany it’s easier to learn German than to have everyone in Germany taught English. Can anyone recommend a book or website for learning Scheme as it currently exists in Lilypond? So that I won’t start using deprecated features or whatever. I’m fluent in Lua (which I like a lot). Vaughan ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
David Kastrup d...@gnu.org writes: [...] Let me summarize the gist of that long reply: My answer to the question What do you think of Scheme as LilyPond's extension language? would be the same as the famous response to the question Mr. Gandhi, what do you think of Western civilization?: I think it would be a good idea. I will not likely be nearly as skilled in effecting my goals as this rather influential historic person (it feels almost like an insult to call him a politician) was doing his: after all, there is no way to shame code into doing what it should have been doing in the first place. But one can try. And it beats starting from scratch. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
On 05/06/12 08:53, David Kastrup wrote:
I would doubt that this would have been the fault of Scheme. More
likely a problem of the Scheme/LilyPond interface choices, but those
choices don't go away when replacing Scheme.
No, it was the fault of the unfamiliar Scheme syntax. A colleague used to
working with Scheme was able to solve the problems I encountered trivially
without reference to anything LilyPond-specific.
Python is a programming language where simple cutpaste of example code
fails unless you cut and paste whole lines since leading whitespace
matters. I don't call that exactly easy to comprehend.
... which is finnicky and annoying, but doesn't necessarily make the code itself
difficult to understand or tweak. C, C++, Java, D, Go, PHP, JavaScript and even
Ruby and Python share a close enough notational style and a close enough set of
supported programming paradigms (particularly imperative and object-oriented) to
make it fairly easy to jump from one to another.
Scheme (and all other LISP dialects), Haskell and so on have a starkly different
notational style and set of programming paradigms that make them difficult to
adapt to from current mainstream programming approaches. That puts a barrier in
the way of lots of potential contributors.
Anyway, show the code. Take a snippet of LilyPond code, pretend that
LilyPond's extension language is Python, and show how it should look
like under that pretense.
I've no intention of proposing Python as the extension language, but I'll do
what you suggest with D.
Here's a Scheme function, naturalize-pitch, which was written (not by me) to
remove double-accidentals and enharmonically rewrite B#, E# and Cb, Fb. It can
be found in:
http://lilypond.org/doc/v2.15/Documentation/notation/changing-multiple-pitches#transpose
;;
(define (naturalize-pitch p)
(let ((o (ly:pitch-octave p))
(a (* 4 (ly:pitch-alteration p)))
;; alteration, a, in quarter tone steps,
;; for historical reasons
(n (ly:pitch-notename p)))
(cond
((and ( a 1) (or (eq? n 6) (eq? n 2)))
(set! a (- a 2))
(set! n (+ n 1)))
((and ( a -1) (or (eq? n 0) (eq? n 3)))
(set! a (+ a 2))
(set! n (- n 1
(cond
(( a 2) (set! a (- a 4)) (set! n (+ n 1)))
(( a -2) (set! a (+ a 4)) (set! n (- n 1
(if ( n 0) (begin (set! o (- o 1)) (set! n (+ n 7
(if ( n 6) (begin (set! o (+ o 1)) (set! n (- n 7
(ly:make-pitch o n (/ a 4
;;
Here's the D equivalent. Note that I've defined a basic object to represent a
LilyPond pitch, which has the same characteristics as the pitch object used by
the Scheme code. It's probably not how a pitch object would best be defined but
is just there to illustrate.
I've also included a few of D's safety features with assert() commands to ensure
that the variables have the properties required.
//
struct LilyPitch
{
int octave;
int notename;
double alteration;
pure this(int o, int n, double a)
in
{
assert(0 = n n = 6);
assert(-1 = a a = 1);
}
body
{
octave = o;
notename = n;
alteration = a;
}
}
pure auto naturalizePitch(LilyPitch p)
{
// Here we mimic what the Scheme function does and define separate
// temporary variables to store the octave, note name and alteration.
// We could just tweak p.octave, p.notename and p.alteration
// directly, but I choose to assume that with a properly defined
// LilyPitch we wouldn't have that possibility.
auto o = p.octave;
auto n = p.notename;
auto a = p.alteration;
// First, we disallow anything greater than +1/4-tone on E and B,
// and anything less than -1/4-tone on C and F. In other words,
// no E# or B#, no Cb or Fb.
if(a 0.25 (n == 6 || n == 2))
{
a -= 0.5;
n += 1;
}
else if(a -0.25 (n == 0 || n == 3))
{
a += 0.5;
n -= 1;
}
// Once that's dealt with, we disallow any accidental stronger than
// a sharp or a flat, on ANY note.
if(a 0.5)
{
a -= 1.0;
n += 1;
}
else if(a -0.5)
{
a += 1.0;
n -= 1;
}
// Last, we clean up the octave placement.
if(n 0)
{
o -= 1;
n += 7;
}
else if(n 6)
{
o += 1;
n -= 7;
}
// Let's check that the note really falls within the
// bounds we are looking for ...
assert(0 = n n = 6);
assert(-0.5 = a a = 0.5);
if(n == 2 || n == 6)
assert(a 0.5);
if(n == 0 || n == 3)
assert(a -0.5);
return LilyPitch(o, n, a);
}
//
Now, I don't think the naturalize-pitch Scheme
Re: Scheme syntax vs. other languages [was: Re: Appreciation / Financial support]
David Kastrup d...@gnu.org writes:
So please, try again. This time picking something that actually
solves a task in LilyPond.
Something like
Documentation/snippets/adding-extra-fingering-with-scheme.ly (which
actually does a ridiculous amount using Scheme rather than #{...#} but
let's just assume that as a given).
Or how would you write something like
applyMusic =
#(define-music-function (parser location func music) (procedure? ly:music?)
(_iApply procedure @var{func} to @var{music}.)
(func music))
in LilyPond/D? How would you call it from LilyPond?
In the snippets I see the following (it is actually rather awful code:
one would use music-is-of-type? rather than memq, and of course it does
not do to copy all properties rather than just those supported by
SkipEvent, namely duration and articulations).
The following being
#(define (notes-to-skip m)
Convert all stuff with duration (notes, lyrics, bass figures, etc.) to skips.
Scripts and dynamics are maintained.
(if (memq 'rhythmic-event (ly:music-property m 'types))
(let* ((newmus (make-music 'SkipEvent)))
(map
(lambda (x) (ly:music-set-property! newmus (car x) (cdr x)))
(ly:music-mutable-properties m))
newmus
)
m)
)
\layout { ragged-right= ##t }
foobar = \transpose c c' { c4\-^ c4-^ c4\!-^ c4-^ }
\relative c'' \context Voice {
\foobar
\applyMusic #(lambda (x) (music-map notes-to-skip x))
\foobar
{ d8 d d d d d d d }
}
from input/regression/music-map.ly.
But notes-to-skip is, in itself, general purpose programming. That's
not the interesting part. The interesting part is how to tie things
together, so assume that the function is already given.
This is a bit of an unfair case because it's obviously a function
where imperative programming is probably better suited.
It is a bit unfair since you have not even _tried_ creating a LilyPond
document where this function is defined and used. You have created a
scrap of source code dangling in the air. That is not the hard part
about an extension language.
--
David Kastrup
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Han-Wen Nienhuys hanw...@gmail.com writes: On Fri, Jun 1, 2012 at 4:50 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: Han-Wen Nienhuys writes: Let me try to rephrase things: the more functionality is moved into the Scheme layers, the less people you can find who are capable of working on it. For me, the complexity of LilyPond itself outplays learning a new programming language by far. Moreover, learning scheme has given me a very helpful and refreshing new perspective on programming. I'm wondering, do you think that learning a new language such as scheme would scare you away from hacking on LilyPond, if you discovered it? As long as you seek out new technologies, you'll always get new perspectives on programming. I, like most people, have only a limited amount of time. Learning a programming language well enough to write code that sticks to wall when you throw it, is a significant investment, and if there is a choice, I'd invest in something that will pay off beyond working on LilyPond. Scheme has very use in any context, so it's not very attractive. Emacs Lisp has very little use outside of Emacs. TeX has very little use outside of TeX, and is total crap as a programming language (much less consistent and predictable than, say, m4, let alone Scheme). Yet Emacs has created a blossoming package ecosystem, and LaTeX has sprouted an enormous package ecosystem, whereas plain TeX has remained a disconnected toy field for tinkerers. What helped LaTeX take off as compared to plain TeX? Extension mechanisms and reasonable (though neither hardwired into the core language TeX nor fabulous) modularization and encapsulation mechanisms and hooks. LaTeX2.09 created a larger ecosystem than plain TeX due to a better abtracted document language. Its redesign LaTeX2e grew a humongous ecosystem over time, and that is because _most_ packages work orthogonally without significant interference with other packages. And those that don't, like hyperref (because of missing hooks and abstractions in the core), are a maintenance nightmare. Changing languages will not save us from doing our homework. It's like complaining that we should really replace our floors with hardwood rather than the current carpet because hardwood is quite easier to keep clean. Have you tried vacuuming? Why should I when hardwood is so much easier to keep clean? If we got hardwood, would you clean it? I am sure that will be taken care of, somehow. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 05/06/12 06:10, Han-Wen Nienhuys wrote: As long as you seek out new technologies, you'll always get new perspectives on programming. I, like most people, have only a limited amount of time. Learning a programming language well enough to write code that sticks to wall when you throw it, is a significant investment, and if there is a choice, I'd invest in something that will pay off beyond working on LilyPond. Scheme has very use in any context, so it's not very attractive. The problem with Scheme is that while it's theoretically beautiful its paradigm and syntax are quite different from most current mainstream programming languages. That makes it a much harder language to ease into than most out there, and consequently harder to play around the edges of contributing or tweaking LilyPond. Some while back I remember playing around with a snippet containing a scheme function for controlling the rules of transposition. Even though I was only tweaking someone else's code it was very finnicky and difficult to get right. That almost certainly wouldn't have been the case if I'd been tweaking Java, Ruby or Python (all of which are programming languages I don't really _know_, but which are not difficult to ease into or to comprehend). Regarding new languages, while I don't want to re-open the alphabet soup discussion, my suggestion wasn't simply a casual shout-out to a cool new language; it was a carefully-considered proposal based on concerns for programming power, ease and flexibility of syntax, code efficiency and suitability for the next generation of hardware. New languages, with small current adoption, do carry a risk, but it's still possible to identify the combination of features, goals, ease of use (and adaptation) and community feel that point towards a future success. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 05/06/12 06:10, Han-Wen Nienhuys wrote: As long as you seek out new technologies, you'll always get new perspectives on programming. I, like most people, have only a limited amount of time. Learning a programming language well enough to write code that sticks to wall when you throw it, is a significant investment, and if there is a choice, I'd invest in something that will pay off beyond working on LilyPond. Scheme has very use in any context, so it's not very attractive. The problem with Scheme is that while it's theoretically beautiful its paradigm and syntax are quite different from most current mainstream programming languages. That makes it a much harder language to ease into than most out there, and consequently harder to play around the edges of contributing or tweaking LilyPond. Some while back I remember playing around with a snippet containing a scheme function for controlling the rules of transposition. Even though I was only tweaking someone else's code it was very finnicky and difficult to get right. I would doubt that this would have been the fault of Scheme. More likely a problem of the Scheme/LilyPond interface choices, but those choices don't go away when replacing Scheme. That almost certainly wouldn't have been the case if I'd been tweaking Java, Ruby or Python (all of which are programming languages I don't really _know_, but which are not difficult to ease into or to comprehend). Python is a programming language where simple cutpaste of example code fails unless you cut and paste whole lines since leading whitespace matters. I don't call that exactly easy to comprehend. Anyway, show the code. Take a snippet of LilyPond code, pretend that LilyPond's extension language is Python, and show how it should look like under that pretense. Regarding new languages, while I don't want to re-open the alphabet soup discussion, my suggestion wasn't simply a casual shout-out to a cool new language; it was a carefully-considered proposal based on concerns for programming power, ease and flexibility of syntax, code efficiency and suitability for the next generation of hardware. Fewer buzzphrases, more substance. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Tue, Jun 5, 2012 at 3:57 AM, David Kastrup d...@gnu.org wrote: I'm wondering, do you think that learning a new language such as scheme would scare you away from hacking on LilyPond, if you discovered it? As long as you seek out new technologies, you'll always get new perspectives on programming. I, like most people, have only a limited amount of time. Learning a programming language well enough to write code that sticks to wall when you throw it, is a significant investment, and if there is a choice, I'd invest in something that will pay off beyond working on LilyPond. Scheme has very use in any context, so it's not very attractive. Emacs Lisp has very little use outside of Emacs. TeX has very little use outside of TeX, and is total crap as a programming language (much less consistent and predictable than, say, m4, let alone Scheme). Yet Emacs has created a blossoming package ecosystem, and LaTeX has sprouted an enormous package ecosystem, whereas plain TeX has remained a disconnected toy field for tinkerers. It's interesting that you should note emacs and latex as successes. To me, emacs-lisp yet another idiosyncratic language that I can't be bothered to learn. Also, my experience of latex is not as rosy-colored as yours. I've had to deal with plenty of packages that could only work if \makeatletter was inserted in the correct random place. Anyway, this discussion is veering off from my original point, which was to not go overboard on Scheme, as there are fewer people that can write it. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Han-Wen Nienhuys hanw...@gmail.com writes:
On Tue, Jun 5, 2012 at 3:57 AM, David Kastrup d...@gnu.org wrote:
I'm wondering, do you think that learning a new language such as scheme
would scare you away from hacking on LilyPond, if you discovered it?
As long as you seek out new technologies, you'll always get new
perspectives on programming.
I, like most people, have only a limited amount of time. Learning a
programming language well enough to write code that sticks to wall
when you throw it, is a significant investment, and if there is a
choice, I'd invest in something that will pay off beyond working on
LilyPond. Scheme has very use in any context, so it's not very
attractive.
Emacs Lisp has very little use outside of Emacs. TeX has very little
use outside of TeX, and is total crap as a programming language (much
less consistent and predictable than, say, m4, let alone Scheme). Yet
Emacs has created a blossoming package ecosystem, and LaTeX has sprouted
an enormous package ecosystem, whereas plain TeX has remained a
disconnected toy field for tinkerers.
It's interesting that you should note emacs and latex as successes.
To me, emacs-lisp yet another idiosyncratic language that I can't be
bothered to learn.
The point is that enough people could be bothered, and that the results
of people bothering have been able to accumulate into an ecosystem that
is reusable without requiring you to touch the inside of files.
Also, my experience of latex is not as rosy-colored as yours. I've had
to deal with plenty of packages that could only work if \makeatletter
was inserted in the correct random place.
Which means exactly that you tried _reusing_ their code instead of
_using_ it in the intended way. That is, you treated LaTeX as a snippet
database rather than a function library. A successful software
ecosystem can serve _users_, not just scavengers.
LaTeX's modularization is something you can poke a stick through in
gazillions of ways, but the basic feature that you use
\documentclass[options...]{classname}
and
\usepackage[options...]{package}
to call upon functionality and mostly get it, in a way for which some
reasonably standardized documentation is available, is there.
Emacs Lisp is worse with a plethora of (require ...) or (load-file ...)
or whatever declarations, and with (define-custom ...) and friends. But
you'll find the necessary invocations at the top of the file. And you
don't need to touch the file and/or copy more than the invocation.
This is adhoc (and frankly crap) modular at an even less standardized
level than TeX/LaTeX, but the language compensates for that because it
is, while idiosyncratic, three levels of crap above TeX and actually
maintained for its purpose (TeX was only ever intended to provide enough
typesetting and programming functionality for the purpose of putting
The Art of Computer Programming through its second edition in good
style in spite of being typeset by computer).
Anyway, this discussion is veering off from my original point, which
was to not go overboard on Scheme, as there are fewer people that can
write it.
The point is that your original point is not all that relevant for the
question of being able to build, support and grow a functionality and
user base with a chance of prospering without permanent upstream feed
and care.
Scheme is a much better starting point for that than what others have
been shown to be able to work with successfully. We just need to get
our act together instead of restarting with the favorite language of the
day and still without a plan.
LilyPond is not designed to be extended, and picking a different
extension language will not magically change that. Scheme/Guile is more
than good enough, and certainly quite better than C++ for that purpose.
But as long as we don't provide a working extension framework based on
the extension language, we don't get an extension ecosystem.
If LilyPond were done in a modular and extensible manner, something like
balloons would be implemented in one load-on-demand Scheme file defining
its music functions (user interface), its events, its grobs, and its
typesetting, where at least the typesetting could ultimately be
optionally be done in a separate C++ file loading standard LilyPond
headers and using a standard API, compiled to an on-demand loadable
shared object.
The C++ angle is by far the most troublesome, and it will only be good
for a constant factor usually. With a good set of primitives available
from Scheme, you can cut the advantage of using C++ for some level down
to a level where it is feasible to just don't use it for extensions.
I've been working on the parser a _lot_, and the main point was the
ability to move basic functionality _out_ from it and into music
functions. You likely don't see a point in that since you consider
C++/bison a nicer language than Scheme. But it is not user-serviceable.
--
David Kastrup
Re: Appreciation / Financial support
On Jun 4, 2012, at 8:30 AM, Jeff Barnes wrote: From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net On 30/05/12 02:12, Han-Wen Nienhuys wrote: One of the problems of LilyPond is that C++ had very poor support for things we desperately need: reflection, automatic memory management and callbacks. How about D? Also, consider Qt. It has all of the above. Qt makes it pretty easy for devs who started out with higher-level languages to become productive in C++. See, here is the problem. There appear to be about 500 languages which could be used for writing the core application and writing ways to extend it. It seems that someone with too much time on their hands is inventing a new language every damn day. They all have their strengths and weaknesses. But here are the key things: 1. Lilypond needs to be portable to run natively on all of the major platforms: Windows, Mac and Linux/BSD/etc. with as little re-coding as possible. 2. In order to have people writing the code, the languages used should be already in wide use so that developers don't have to learn a new language and install new APIs. Mature, well-understood languages will reduce the likelihood of introducing new bugs. It becomes alphabet soup watching people toss the language of the moment into the discussion. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
From: Tim McNamara On Jun 4, 2012, at 8:30 AM, Jeff Barnes wrote: From: Joseph Rushton Wakeling joseph.wakel...@webdrake.net On 30/05/12 02:12, Han-Wen Nienhuys wrote: One of the problems of LilyPond is that C++ had very poor support for things we desperately need: reflection, automatic memory management and callbacks. How about D? Also, consider Qt. It has all of the above. Qt makes it pretty easy for devs who started out with higher-level languages to become productive in C++. See, here is the problem. There appear to be about 500 languages which could be used for writing the core application and writing ways to extend it. It seems that someone with too much time on their hands is inventing a new language every damn day. They all have their strengths and weaknesses. But here are the key things: 1. Lilypond needs to be portable to run natively on all of the major platforms: Windows, Mac and Linux/BSD/etc. with as little re-coding as possible. While I'm sensitive to David's request to end the discussion for now, there are some misconceptions about Qt that need addressing. I wish David's response were part of this message so I could address clearly both, but I'll try to reconstruct his reasons and offer counterpoint constructively. First, Qt is cross-platform and runnable on the above platforms and others as well. 2. In order to have people writing the code, the languages used should be already in wide use so that developers don't have to learn a new language and install new APIs. Mature, well-understood languages will reduce the likelihood of introducing new bugs. While Qt APIs are required, no new language is required. With Scheme and the other extension strategies, both new API's and new languages are required. It becomes alphabet soup watching people toss the language of the moment into the discussion. I understand that recommendations like this have very large scope. I don't think Qt is a language of the moment, though. It is mature and has a very large developer base. David seemed to echo your sentiments a little differently. While not explicitly clear in his response, he seemed to relegate Qt to a UI framework. While it's true that Qt is a great UI framework, it has much more value than just in UI development. It's not my job or inclination to educate folks about the extent of Qt's frameworks, but saying it's a UI development API is like saying GNU is Emacs. I'm not sure he was being serious in adding Visual Basic to the mix, but whether or not he was serious, comparing VB to Qt is disingenuous and dismissive without a fair consideration. VB isn't cross platform. There are also license differences and Qt is on the right side of that comparison. I was a little surprised that someone with a GNU background like his would have made those remarks. Regards, Jeff ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Jeff Barnes wrote: While I'm sensitive to David's request to end the discussion for now, there are some misconceptions about Qt that need addressing. That's not entirely clear. The discussion was originally about the choice of Scheme as an extension language. Qt is clearly not an answer to that question. In addition, Qt is not just a library, it is a lifestyle. You would have to throw everything out and start over. It's also not clear to me that Qt is a net win in an application that has a console user interface. First, Qt is cross-platform and runnable on the above platforms and others as well. It has the additional benefit of being enormous. While Qt APIs are required, no new language is required. With Scheme and the other extension strategies, both new API's and new languages are required. In what way does Qt represent an extension strategy? I don't think Qt is a language of the moment, though. Qt is not a language at all. It is a library. I'm not sure he was being serious in adding Visual Basic to the mix, but whether or not he was serious, comparing VB to Qt is disingenuous and dismissive without a fair consideration. VB isn't cross platform. There are also license differences and Qt is on the right side of that comparison. I was a little surprised that someone with a GNU background like his would have made those remarks. VB is, at least, a language, and an embeddable one at that. VB brings with it the .NET Common Language Runtime, which IS more or less directly comparable to Qt. It is cross-platform (via Mono), although not to the same degree that Qt is. However, this debate is now taking a nasty side-trip into religion, and that isn't going to help anyone. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
From: Tim Roberts Jeff Barnes wrote: While I'm sensitive to David's request to end the discussion for now, there are some misconceptions about Qt that need addressing. That's not entirely clear. I don't think starting from here is fair, Tim. You didn't quote enough context. The discussion was originally about the choice of Scheme as an extension language. Qt is clearly not an answer to that question. In addition, Qt is not just a library, it is a lifestyle. You would have to throw everything out and start over. It's also not clear to me that Qt is a net win in an application that has a console user interface. From the above paragraph snippet, everything except the first and last sentence should have been prefaced with IMO. But the last sentence, in particular, was a fair response to my post, so I should address it. The net win would be Qt's meta object system and the built in options for scripting: dynamic and generated script bindings. Both have their advantages and drawbacks. Refactoring for the exposed Lily api could be gradual in either case. Big gains could be realized fairly quickly though, IMO. First, Qt is cross-platform and runnable on the above platforms and others as well. It has the additional benefit of being enormous. Fair enough. Something to be considered. It's not clear to me that this is of itself a deal breaker, though, IMO. You're not saying the CLR is small, though are you? While Qt APIs are required, no new language is required. With Scheme and the other extension strategies, both new API's and new languages are required. In what way does Qt represent an extension strategy? Using C++ to extend Lily. With the benefit that there are readily available language bindings to popular languages. I don't think Qt is a language of the moment, though. Qt is not a language at all. It is a library. Then we agree? I'm not sure he was being serious in adding Visual Basic to the mix, but whether or not he was serious, comparing VB to Qt is disingenuous and dismissive without a fair consideration. VB isn't cross platform. There are also license differences and Qt is on the right side of that comparison. I was a little surprised that someone with a GNU background like his would have made those remarks. VB is, at least, a language, and an embeddable one at that. VB brings with it the .NET Common Language Runtime, which IS more or less directly comparable to Qt. It is cross-platform (via Mono), although not to the same degree that Qt is. If it would suit the platform, extensibility, and license requirements I'd consider using it. Would you stipulate that Mono is less mature than Qt? Would you agree that saying VB brings with it the .NET Common Language Runtime is overstating it a little? However, this debate is now taking a nasty side-trip into religion, and that isn't going to help anyone. It was not my intent to get religious. Please show me where I was religious about Qt and I will gladly recant. Regards, Jeff ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Jeff Barnes jbarnes...@yahoo.com writes: From: Tim Roberts In what way does Qt represent an extension strategy? Using C++ to extend Lily. C++ is not useful for extending LilyPond. It is its skeleton substance, but is not user serviceable. Qt would not change that. With the benefit that there are readily available language bindings to popular languages. There seems little point in using Qt for accessing the popular languages. However, this debate is now taking a nasty side-trip into religion, and that isn't going to help anyone. It was not my intent to get religious. Please show me where I was religious about Qt and I will gladly recant. Religion is about belief. Port some significant subsystem of LilyPond to your idea of Qt usage, and you have actual substance to talk about rather than belief. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Fri, Jun 1, 2012 at 4:50 AM, Jan Nieuwenhuizen jann...@gnu.org wrote: Han-Wen Nienhuys writes: Let me try to rephrase things: the more functionality is moved into the Scheme layers, the less people you can find who are capable of working on it. For me, the complexity of LilyPond itself outplays learning a new programming language by far. Moreover, learning scheme has given me a very helpful and refreshing new perspective on programming. I'm wondering, do you think that learning a new language such as scheme would scare you away from hacking on LilyPond, if you discovered it? As long as you seek out new technologies, you'll always get new perspectives on programming. I, like most people, have only a limited amount of time. Learning a programming language well enough to write code that sticks to wall when you throw it, is a significant investment, and if there is a choice, I'd invest in something that will pay off beyond working on LilyPond. Scheme has very use in any context, so it's not very attractive. Therefore, you should be careful with moving more and more code into the Scheme layer. If the former hypothesis was true, then maybe. Or maybe not -- most important is that things get better, simpler, easier to extend and change for the current hackers, imvho. -- Han-Wen Nienhuys - han...@xs4all.nl - http://www.xs4all.nl/~hanwen ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 30/05/12 02:12, Han-Wen Nienhuys wrote: One of the problems of LilyPond is that C++ had very poor support for things we desperately need: reflection, automatic memory management and callbacks. How about D? http://dlang.org/ This seems to me to be a great choice for much of LP's needs. C/C++ like core syntax (you can write pretty much pure C when you need to for specificity or efficiency), but with a much more elegant OO syntax than C++; automatic memory management; support for LISP-like and functional programming; much more readily suited for writing multi-threaded code; ... Their string mixin concept looks like it might also be very useful for LP: http://dlang.org/mixin.html ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 03/06/12 14:17, David Kastrup wrote: How about first getting C++/Scheme right? As I already explained, cleaning up the mess of layers and control flow will a) give a better basis for judging that approach b) make it easier to migrate individual layers to something else if desired Don't get me wrong; I'm not proposing a rewrite on the spot or even in the near future. It's just that if there _is_ at some point a desire to consider a bottom-up rebuild with a new language or framework, D is probably one to take seriously, as it offers the power and flexibility of LISP and functional languages while having a very friendly and usable syntax. But in the short term at least, I completely agree with you about getting the C/Scheme combo right (if I understood your earlier email correctly, the desire is to remove as much C++ as possible). Take a look at Goops: it offers a lot of the things the C++ class system does, with reasonable performance and much better reflection and extensibility. I am currently working on moving the property/event system there, and one will have to see what the performance impact on that will be. I'll give it a look. It's all nice to throw all sort of language names into the ring, but as long as the architecture of LilyPond is one incoherent mess, porting it is not going to clean it up. Agree about architecture being the priority. I can make no promises as my LP-wards free time is sporadic, but I would like to assist here if I can. That said, I didn't make the language suggestion casually. One of the issues with Scheme is that although it's powerful it's also an unfamiliar and not-so-easy-to-grasp scripting syntax when compared with the languages lots of people are familiar with. D has the advantage of being high-performance (as fast as C/C++ in my experience), having a syntax which is easy to switch to from C/C++/Java/C#/etc., but also having the functional/LISP-like constructs needed by LilyPond. It would be a major breaking change, though, so not to be done without very careful consideration. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 03/06/12 14:17, David Kastrup wrote: How about first getting C++/Scheme right? As I already explained, cleaning up the mess of layers and control flow will a) give a better basis for judging that approach b) make it easier to migrate individual layers to something else if desired Don't get me wrong; I'm not proposing a rewrite on the spot or even in the near future. It's just that if there _is_ at some point a desire to consider a bottom-up rebuild with a new language or framework, D is probably one to take seriously, as it offers the power and flexibility of LISP and functional languages while having a very friendly and usable syntax. But in the short term at least, I completely agree with you about getting the C/Scheme combo right (if I understood your earlier email correctly, the desire is to remove as much C++ as possible). I don't want to remove as much C++ as possible. That's about as useful as to remove as much C as possible from Emacs. The point is to consider C++ as the building language for primitives, and tie together the primitives in Scheme. At the current point, most of the control flow is inaccessible from the Scheme layer. That's not helpful for extending, and it is not helpful for understanding LilyPond from a user perspective. The C++ layer most certainly is important as underpinnings, but you can't understand LilyPond from the Scheme perspective because not just functionality/performance but also logic and control flow is tied to a large degree into that layer: you would not dare working with call-with-current-continuation, and most of the time, the Scheme stacktrace (and debugger) is not significant for finding out what happens. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On 03/06/12 17:44, David Kastrup wrote: I don't want to remove as much C++ as possible. That's about as useful as to remove as much C as possible from Emacs. The point is to consider C++ as the building language for primitives, and tie together the primitives in Scheme. OK, I misinterpreted your remarks somewhat. I had read them as meaning that (besides re-architecting things so that control flow etc. was organized from within Scheme) you wanted to strip out the object-oriented side of things and move that over to Scheme, so that what was currently C++ would be pared back to being fairly pure C. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Joseph Rushton Wakeling joseph.wakel...@webdrake.net writes: On 03/06/12 17:44, David Kastrup wrote: I don't want to remove as much C++ as possible. That's about as useful as to remove as much C as possible from Emacs. The point is to consider C++ as the building language for primitives, and tie together the primitives in Scheme. OK, I misinterpreted your remarks somewhat. I had read them as meaning that (besides re-architecting things so that control flow etc. was organized from within Scheme) you wanted to strip out the object-oriented side of things and move that over to Scheme, so that what was currently C++ would be pared back to being fairly pure C. Well, the code written in C++ needs to stay manageable as well. If you take a look at Goops, you have considerable leeway for adding a Scheme OO layer modeled along an existing C++ layer. As I said, I am going through the context/property system, and I don't intend to change the C++ code using it significantly (well, there will be a number of macros redefined and obviously things like context-property.cc and other stuff _implementing_ those interfaces are bound to go). But there are things like a let's implement the Ambitus engraver as an example in Scheme project that are sort of an academic exercise because of hand-cranking a lot of stuff. And there are a few examples in snippets and/or regtests that actually use Goops, and they are ad-hoc-ing some artificial and arbitrary structures together that make understanding matters harder for the average reader. If the context/property system has a _natural_ Goops/Scheme interface, then you have an object oriented _framework_ you can get into. Doing a full-featured engraver in Scheme, including interfaces, grobs, mobs, event-classes, whatever, is then just an exercise of following existing practice and using existing structures and mechanisms. You don't need to make it all up. Learning how to _use_ stuff is orders of magnitude easier than learning how to _invent_ stuff. Most importantly: you don't need to make design decisions. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Fri, Jun 1, 2012 at 11:20 PM, Graham Percival gra...@percival-music.ca wrote: But can we stop arguing about commercializing lilypond.org? As a result of a fair amount of arguments, we have a sponsorship page. Do you really want to re-open that debate? after only a few months? I'm pretty sick of that topic. ok, sorry. i must've missed that discussion. I didn't find any decisions here http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#policy-decisions-_0028finished_0029 i saw sponsorships on GOP todo http://lilypond.org/doc/v2.15/Documentation/contributor-big-page#policy-decisions so i thought that there were no specific policies wrt/ sponsorship page (apart from the decision to create it). Now i've found http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00124.html and it looks like the discussion happened when i was absent. So, apologies - and where can i read detailed policies? thanks, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Sat, Jun 02, 2012 at 12:30:01AM +0200, Francisco Vila wrote: 2012/6/1 Graham Percival gra...@percival-music.ca: And lilynet is a good place for experimental / unofficial stuff. Well, http://wiki.lilynet.net/index.php/Special:RecentChanges -snip problems- I am sorry, I don't really want to be unconstructive. Maintaining this kind a site eats much time and effort. ok, good point. Still, there's plenty of places that somebody could host experimental / unofficial lilypond stuff. I'm ok having a link to that other place on the sponsorship page, but other than that I'd rather not mess with lilypond.org. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Sat, Jun 02, 2012 at 04:38:24PM +0200, Janek Warchoł wrote:
Now i've found
http://lists.gnu.org/archive/html/lilypond-devel/2011-12/msg00124.html
and it looks like the discussion happened when i was absent.
As per GOP 6, it was a private email discussion so no archives are
available.
So, apologies - and where can i read detailed policies?
Detailed policy is pretty much exactly what is shown on that
webpage, plus a comment from the texinfo:
@c Format
@c @item @email{name@@adress.domain, Name}
@c area of interest (256 chars max)
I suppose I should clarify that the area of interest text can
include urls, and that only the user-visible portion of the url
counts towards the number of characters. (not that I expect the
number of characters to matter, other than clarifying that we
expect 1-3 sentences rather than a 5-page bio)
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Sat, Jun 2, 2012 at 5:37 PM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jun 02, 2012 at 04:38:24PM +0200, Janek Warchoł wrote: So, apologies - and where can i read detailed policies? Detailed policy is pretty much exactly what is shown on that webpage, ok. I think that adding a /small/ donation progress bar in David's description wouldn't be a violation of the rules. But i don't insist. End of discussion :) Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Janek Warchoł janek.lilyp...@gmail.com writes: On Sat, Jun 2, 2012 at 5:37 PM, Graham Percival gra...@percival-music.ca wrote: On Sat, Jun 02, 2012 at 04:38:24PM +0200, Janek Warchoł wrote: So, apologies - and where can i read detailed policies? Detailed policy is pretty much exactly what is shown on that webpage, ok. I think that adding a /small/ donation progress bar in David's description wouldn't be a violation of the rules. But i don't insist. End of discussion :) I'll probably see whether I manage to create some 250-byte ASCII-art progress bar donation home page that does not pose much of a risk of blowing the transfer limits of some zero-cost site if it is _that_ important to people. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Sat, Jun 2, 2012 at 5:49 PM, Janek Warchoł janek.lilyp...@gmail.com wrote: ok. I think that adding a /small/ donation progress bar in David's description wouldn't be a violation of the rules. But i don't insist. +1. I've been talking for years about a donation thermometer like they have on Blender's homepage, or a bounty tracker like they have on Haiku's website. There is no debate that lilypond.org shouldn't ever be commercialized nor monetized in any way; however there has been a sponsorship page since the LilyPond-design days, and as long as it's clean, unintrusive and honest (i.e. not promising something we can't deliver), it can only be seen as a way for our (numerous enough) fans to show their appreciation. Regards, Valentin. PS: ASCII art, way to go! ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Han-Wen Nienhuys writes: Let me try to rephrase things: the more functionality is moved into the Scheme layers, the less people you can find who are capable of working on it. For me, the complexity of LilyPond itself outplays learning a new programming language by far. Moreover, learning scheme has given me a very helpful and refreshing new perspective on programming. I'm wondering, do you think that learning a new language such as scheme would scare you away from hacking on LilyPond, if you discovered it? Therefore, you should be careful with moving more and more code into the Scheme layer. If the former hypothesis was true, then maybe. Or maybe not -- most important is that things get better, simpler, easier to extend and change for the current hackers, imvho. 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: Appreciation / Financial support
Jan Nieuwenhuizen jann...@gnu.org writes: Han-Wen Nienhuys writes: Let me try to rephrase things: the more functionality is moved into the Scheme layers, the less people you can find who are capable of working on it. For me, the complexity of LilyPond itself outplays learning a new programming language by far. Moreover, learning scheme has given me a very helpful and refreshing new perspective on programming. I'm wondering, do you think that learning a new language such as scheme would scare you away from hacking on LilyPond, if you discovered it? Therefore, you should be careful with moving more and more code into the Scheme layer. If the former hypothesis was true, then maybe. Or maybe not -- most important is that things get better, simpler, easier to extend and change for the current hackers, imvho. In my opinion, we have too many layers to keep track of for extensions. The proper subdivision should be something like: C++: functionality Scheme: structure and control flow LilyPond input language: user interface layer The problem with LilyPond is that the C++ and Scheme layers don't really have a proper separation of tasks, and so you can't escape either for actually simple extensions. I don't think it makes sense talking about different extension languages before cleaning up our act regarding this division of tasks. It is an incremental task to turn the C++/Scheme threshold into something that makes sense. And one that would, once accomplished, greatly simplify a full-blown conversion to a different extension language if it was still deemed desirable. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
2012/6/1 Jan Nieuwenhuizen jann...@gnu.org: For me, the complexity of LilyPond itself outplays learning a new programming language by far. In other words, saying Who's going to learn LilyPond? Nobody will! is more or less the same as saying Who is going to learn Scheme to contribute to LilyPond? Nobody will!. Despite of what I've been trying to convince myself for ages, at the end [possibly] LilyPond is for geeks only. Geeks among geeks are who will learn whatever it is necessary to learn for contributing. For example, contributors to LaTeX packages have to learn hardcore lowlevel TeX and all those cryptic @-commands. I am surprised on how many of them there are; the fact is that many packages exist and they are made by geeks^2. Scheme looks easy to me by comparison. Moreover, learning scheme has given me a very helpful and refreshing new perspective on programming. If one would like to seriously learn and use Scheme, which IDE for editing/running/debugging do you recommend? -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Francisco Vila paconet@gmail.com writes: 2012/6/1 Jan Nieuwenhuizen jann...@gnu.org: For me, the complexity of LilyPond itself outplays learning a new programming language by far. In other words, saying Who's going to learn LilyPond? Nobody will! is more or less the same as saying Who is going to learn Scheme to contribute to LilyPond? Nobody will!. Despite of what I've been trying to convince myself for ages, at the end [possibly] LilyPond is for geeks only. Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. Geeks among geeks are who will learn whatever it is necessary to learn for contributing. For example, contributors to LaTeX packages have to learn hardcore lowlevel TeX and all those cryptic @-commands. I am surprised on how many of them there are; the fact is that many packages exist and they are made by geeks^2. Scheme looks easy to me by comparison. It is a matter of how much you can achieve with what effort. If you get a good return of investment on your learning curve, you will go further eventually. Now learn compiling software and writing C++ is a bit of a discontinuity, and the minimum amount of C++ you need to learn before starting to be able to work on LilyPond at all appears larger to me than the minimal amount of Scheme. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Hi David, Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Kieren MacMillan wrote: Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. That is a completely accurate assessment. Given that, isn't it a wonder, when looking at this mailing list, that we can be so vocal and opinionated? ;) The reason arguments in academia are so violent is that the stakes are so low. -- Tim Roberts, t...@probo.com Providenza Boekelheide, Inc. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi David, Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. It is rather the rule than the exception that whenever somebody feels the need to rephrase what I have been writing, it ends up being utterly different. It would appear that I have problems expressing myself clearly. People creating typeset music are certainly a much smaller number than those consuming music in any form. This much smaller number will contain a higher ratio of people willing to write down basic LilyPond notation than the general populace, or rather than the ratio of people among the general populace willing to write input for any batch processing system (say, LaTeX). A full-blood composer will not let himself be turned away by the necessity to deal with whatever it takes to create scores according to his vision, like a full-blood painter will not let himself be discouraged by the necessity to deal with brushes and paints. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
From: Kieren MacMillan kieren_macmil...@sympatico.ca Hi David, Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. It sounds like it would be quite valuable to know the commonalities of this very very small very small group for positioning Lily and for future development direction. As for me, I like Lily because it sets my mind to the process of composition/arranging with the manual entry of notes. This process is mechanically more akin to the task of using pen and ink than the more visual or keyboard approaches to note entry. As I write, Lily forces me to consider music theory more directly. It also forces me to think about enharmonic considerations, meter and many other things. With the Lily domain specific language, there is a natural bridging between theoretical musical concepts and computer programming. The divide between the two isn't that large, BTW. I started my career as a musician and learned computer programming in my 30's. I've often remarked that music, especially arranging and composing, is very much like developing an application (only solo), with a well-known set of algorithms for melodic and harmonic construction. Regards, Jeff ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Fri, 01 Jun 2012 19:02:02 +0200 David Kastrup d...@gnu.org wrote: Kieren MacMillan kieren_macmil...@sympatico.ca writes: Hi David, Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. It is rather the rule than the exception that whenever somebody feels the need to rephrase what I have been writing, it ends up being utterly different. It would appear that I have problems expressing myself clearly. People creating typeset music are certainly a much smaller number than those consuming music in any form. This much smaller number will contain a higher ratio of people willing to write down basic LilyPond notation than the general populace, or rather than the ratio of people among the general populace willing to write input for any batch processing system (say, LaTeX). A full-blood composer will not let himself be turned away by the necessity to deal with whatever it takes to create scores according to his vision, like a full-blood painter will not let himself be discouraged by the necessity to deal with brushes and paints. -- David Kastrup Technically there is a distinction between composer and typesetter, like there is when writing a book: Authors may write in Microsoft Word and Comic Sans, they can give it to their publisher who then can use whatever they need, with a pro-grade typographer person, to create the real deal. The content stays, the format gets better. Similar situation with music notation. Instead of MS Word and Comic Sans you can use MuseScore here and then later give it to a pro who creates it from scratch, only keeping the content. And this is the critical point. Lilypond must be the number one tool of choice in this _step_. Everything else before and after here are just personal-union (composer and publisher is the same person) or a bonus. Therefore you all read the wrong statistics. The maximum group of people are the notation typesetters. Some work freelance, some work at publishers like Bärenreiter. But not musicians, composers or even (ridicoulus!) people who listen to music. Nils ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Tim Roberts t...@probo.com writes: Kieren MacMillan wrote: Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. That is a completely accurate assessment. Given that, isn't it a wonder, when looking at this mailing list, that we can be so vocal and opinionated? Well, returning to the topic in the subject line: on May 24th, my rally for funding my work on LilyPond had netted €165 for the month when I posted my guess that the bare minimum of €800 I needed for just subsisting would not be met this month. I have not yet corrected the balance with regard to payments intended for more than one month, but it turns out that the balance now is more like €1150. Even the subset of the subset of the subset that is reading this mailing list, vocal and opinionated or not, is making a difference for me, and certainly also for LilyPond. And a large part of this difference _is_ by being vocal and opinionated on this list. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Hi Nils (et al.), Authors may write in Microsoft Word and Comic Sans, they can give it to their publisher who then can use whatever they need, with a pro-grade typographer person, to create the real deal. The content stays, the format gets better. Similar situation with music notation. Instead of MS Word and Comic Sans you can use MuseScore here and then later give it to a pro who creates it from scratch, only keeping the content. And this is the critical point. Lilypond must be the number one tool of choice in this _step_. Everything else before and after here are just personal-union (composer and publisher is the same person) or a bonus. And now that Microsoft Word is XML-based, inter-personal communication of content in the world of publishing has become significantly easier and better. Would that we could say the same thing with music notation (especially our dear Lily)… Cheers, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Fri, Jun 1, 2012 at 7:07 PM, Jeff Barnes jbarnes...@yahoo.com wrote: It sounds like it would be quite valuable to know the commonalities of this very very small very small group for positioning Lily and for future development direction. Have you read my articles in The LilyPond Report #25, in particular this one http://news.lilynet.net/?The-LilyPond-Report-25#lilypond_s_future ? cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Message: 7 Date: Fri, 01 Jun 2012 19:18:58 +0200 From: David Kastrup d...@gnu.org To: lilypond-user@gnu.org Subject: Re: Appreciation / Financial support Message-ID: 87bol3osql@fencepost.gnu.org Content-Type: text/plain; charset=iso-8859-15 Tim Roberts t...@probo.com writes: Kieren MacMillan wrote: Who is going to learn reading notes, let alone writing them? Of course LilyPond is only for geeks, because it is just geeks who bother with writing music rather than listening to it. In other words, composers who use Lilypond are a [very, very small] subset of a [very small] subset of all people. That is a completely accurate assessment. Given that, isn't it a wonder, when looking at this mailing list, that we can be so vocal and opinionated? Well, returning to the topic in the subject line: on May 24th, my rally for funding my work on LilyPond had netted ?165 for the month when I posted my guess that the bare minimum of ?800 I needed for just subsisting would not be met this month. I have not yet corrected the balance with regard to payments intended for more than one month, but it turns out that the balance now is more like ?1150. Even the subset of the subset of the subset that is reading this mailing list, vocal and opinionated or not, is making a difference for me, and certainly also for LilyPond. And a large part of this difference _is_ by being vocal and opinionated on this list. You should have a look at the website for Ardour if you haven't already. Paul has a little bar that fills up toward a monthly total, and has an easy donation method that is highly visible. You might also want to get in touch with him to get some details on how that process has worked for Ardour. If you end up implementing something like that on the Lilypond website, I'll donate the first $100. -Jonathan -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
Francisco Vila writes: 2012/6/1 Jan Nieuwenhuizen jann...@gnu.org: For me, the complexity of LilyPond itself outplays learning a new programming language by far. In other words, saying Who's going to learn LilyPond? Nobody will! is more or less the same as saying Who is going to learn Scheme to contribute to LilyPond? Nobody will!. What I meant was: if you're [on your way to become] a geek and find LilyPond and want to contribute, learning scheme may very well be a nice bonus. If one would like to seriously learn and use Scheme, which IDE for editing/running/debugging do you recommend? We from GNU advise GNU Emacs :-) 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: Appreciation / Financial support
Jonathan Wilkes jancs...@yahoo.com writes: You should have a look at the website for Ardour if you haven't already. Paul has a little bar that fills up toward a monthly total, and has an easy donation method that is highly visible. You might also want to get in touch with him to get some details on how that process has worked for Ardour. If you end up implementing something like that on the Lilypond website, I'll donate the first $100. If we put a full-page ad for proprietary software on the LilyPond website and offer only crippled binaries for Windows/MacOSX unless you donate first, I'll be in wild protest. Anyway, I am _one_ developer of several, and it would be inappropriate to turn the LilyPond website into a personal payment collector for myself. And Paul Davis runs a decidedly larger part (and also has larger responsibilities) with the Ardour show than I do with LilyPond. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Fri, Jun 1, 2012 at 10:19 PM, David Kastrup d...@gnu.org wrote: Anyway, I am _one_ developer of several, and it would be inappropriate to turn the LilyPond website into a personal payment collector for myself. And Paul Davis runs a decidedly larger part (and also has larger responsibilities) with the Ardour show than I do with LilyPond. David's right. However, i think it would be ok to add a monthly donations progress bar on the sponsoring subpage (http://www.lilypond.org/sponsoring.html), under David's name. What do you think? To me this would be more like information than an ad. cheers, Janek ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Appreciation / Financial support
On Fri, Jun 01, 2012 at 11:05:02PM +0200, Janek Warchoł wrote: David's right. However, i think it would be ok to add a monthly donations progress bar on the sponsoring subpage (http://www.lilypond.org/sponsoring.html), under David's name. What do you think? To me this would be more like information than an ad. If David wants to have a webpage for additional sponsorship info, he can sign up for a free amazon web service account and get apache running. Or stick it on lilynet.net. Actually, it seems a shame that most of his funding details are buried in the lilypond reports, so on a personal level I'd encourage him to have some more permanent place for the latest funding info. And lilynet is a good place for experimental / unofficial stuff. But can we stop arguing about commercializing lilypond.org? As a result of a fair amount of arguments, we have a sponsorship page. Do you really want to re-open that debate? after only a few months? I'm pretty sick of that topic. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
