Re: Lilypond store?
Erik Sandberg wrote: On Wednesday 05 July 2006 15:09, Stewart Holmes wrote: Yes. Harsh this may sound, but how much of the music on Mutopia would you be satisfied to print out, and use yourself? From a quick browse through various sections, I have to say that a large amount of the music on there is fairly poorly engraved. My proposition is for much more strict quality control... after all, nobody will pay money for music unless it looks professional. I suggest that you start a discussion thread on mutopia's mailing lists: If you have constructive ideas on how to create an archive of high-quality public domain notes, then I would strongly recommend you to use your ideas to improve mutopia; if that's not possible, use mutopia as a base for creating such an archive (i.e., fork the mutopia project). Hi, I initially read this thread as a proposal for offering printed versions of scores for sale. However, on a re-read, I understand that you're proposing to offer downloads of PDF files instead. The attraction of Mutopia for me was the creation of an "open source" archive of sheet music, that people can download for free, print out, photocopy, and distribute. Rather like Project Gutenberg, but for music. If you want to create a rival archive offering pieces for download at a price, then you are of course free to go ahead. Speaking from the point of view of someone who's looked after Mutopia for the last seven years, I think cleaning up Mutopia pieces and organising them for printing would be a very time consuming task. Entering new pieces is of course even more time consuming. From a legal point of view, you will have to be careful what pieces from Mutopia you use. Many are licensed under a CreativeCommons Attribution or Attribution-ShareAlike license. Neither restricts you from selling works based on the Mutopia version, but the latter insists that you release your versions under an identical license (a bit like the GPL). My positive suggestion would be to create a new website offering high quality *printed* LilyPond-engraved music for sale based on Mutopia contributions, still licensed under "open source" licenses. We did some experiments with lulu.com a while ago, and the results were very promising, so that's one possibility. If we work with you on this, and improvements are fed back to Mutopia, then we'd be happy to have links from the relevant Mutopia music pages to your store (ie. "buy a printed copy of this music"). Of course, you can pick music from Mutopia which is already reasonably high quality and likely to be popular. If you're interested, please let me know. I would personally be very disappointed if someone were to "fork" Mutopia. Chris -- Chris Sawer - [EMAIL PROTECTED] - Mutopia team leader Free sheet music for all at: http://www.MutopiaProject.org/ ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
On Saturday 08 July 2006 18:58, Fairchild wrote: > The 3.0 processor could note the 2.4 version flag and treat the ly file in > the 2.4 way, maintaining upward compatibility without a need for > convert-ly. In what way would that be different from installing two different versions of lily? If you don't want the bugfixes from 3.0, why do you upgrade to 3.0? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Chord Name inside parenthesis
Ezequiel:
how can i make all my chord name be placed inside parenthesis
You can follow Erik's generous examples and instructions: "try
learning Scheme basics and read about tweaks in the manual, and then
try to understand exactly what I meant in my previous suggestion, and
finally try to correct the errors I made."
I did what Erik said, and came up with the attached examples -- I
believe they answer your question. [Difference between the two
examples: the second uses larger parentheses.]
Regards,
Kieren.
p.s. Graham: you're cc'ed because this is a useful tip/trick (I
think)...
__
%%% CODE SNIPPET BEGINS
\version "2.9.10"
#(define (parenthesis-ignatzek-chord-names in-pitches bass inversion
context)
(markup #:line ("(" (ignatzek-chord-names in-pitches bass
inversion context) ")")))
chordset = \chordmode
{
\set chordNameFunction = #parenthesis-ignatzek-chord-names
c1:7 g1:7
}
\score
{
\new ChordNames \chordset
}
%%% CODE SNIPPET ENDS
%%% CODE SNIPPET BEGINS
\version "2.9.10"
#(define (parenthesis-ignatzek-chord-names in-pitches bass inversion
context)
(markup #:vcenter #:line ( #:fontsize 2 "(" (ignatzek-chord-names
in-pitches bass inversion context) #:fontsize 2 ")")))
chordset = \chordmode
{
\set chordNameFunction = #parenthesis-ignatzek-chord-names
c1:7 g1:7
}
\score
{
\new ChordNames \chordset
}
%%% CODE SNIPPET ENDS
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Evolutionary User Strategery
New scores could use new features and not have to work around the bugs of earlier versions. Older scores that have been carefully tuned, compensating for earlier bugs, would continue to produce the intended result without having to be overhauled. There would be no need to maintain multiple versions. - Bruce -Original Message- From: Erik Sandberg [mailto:[EMAIL PROTECTED] Sent: Saturday, July 08, 2006 3:55 PM To: Fairchild Cc: lilypond-user@gnu.org Subject: Re: Evolutionary User Strategery On Saturday 08 July 2006 18:58, Fairchild wrote: > The 3.0 processor could note the 2.4 version flag and treat the ly > file in the 2.4 way, maintaining upward compatibility without a need > for convert-ly. In what way would that be different from installing two different versions of lily? If you don't want the bugfixes from 3.0, why do you upgrade to 3.0? -- Erik ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
Bruce: Older scores that have been carefully tuned, compensating for earlier bugs With all due respect, this implies something about Lilypond that simply isn't true. "Carefully tuned" is one thing. My scores are also carefully tuned; from your work I've seen so far, I dare say I'm far more obsessive- compulsive than you in my engraving standards. Nothing personal, mind you: I'm the most OC engraver I've ever met! ;-) That being said, I spent over an hour cleaning up your "bug- compensating code" yesterday, as an instructional example. What you were (are) doing -- e.g., adding title information directly to skipped notes in a \partial bar before the music actually begins, and then filling the \markup code with offset and spacing tweaks to move it back where it really belongs (i.e., in the header and not attached to the music) -- does not "[compensate] for earlier bugs". It's poor coding, plain and simple. Are there bugs in older (and current) versions of Lilypond? Absolutely. Will many be fixed in upcoming versions? I sure hope so. Ironically, the way that the header block acts as a music system is one of the things I hope changes in a future version... but the fact that my titles are all *in* headers already (instead of counter- intuitively attached to invisible notes between the key signature and the first visible note of my score) will make the migration very easy for me, if and when it happens. Based on the example of your work I helped you with, my conservative estimate is that 90% of your migration woes would disappear if you just wrote proper Lilypond code. I think it's quite telling that, like most on this list, I've had essentially no problems moving forward with Lilypond as it evolves and improves (n.b., I started with v1.8), and you apparently have had nothing but headaches. Ultimately, I would feel it a great loss if HW et al. decided to allow Lilypond to become bloatware in some vain quest for the Backwards Compatibility Grail. Fortunately, I know they're too smart to do that. =) Regards, Kieren. p.s. When Microsoft ruined Word for Mac v5.1 by "improving it" (v6.0 and beyond), I didn't upgrade -- perhaps you might consider taking the same approach with Lilypond? ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
RE: Evolutionary User Strategery
Kieren - With all due respect - and you are due a lot. The work you did on my score is impressive, especially that you did it so quickly. My "home made" header was for two overwhelming reasons. First, \header code could only be used once. Second, I found no way to override the default vertical positioning and font. When I started, \header didn't allow embedded \markup. This is a good example where newer capabilities are welcome, but old code should survive. As a learning experiment, I've set about to code Stances in the your style for 2.4.6, then see what needs to change for 2.8.5. I've spent about an hour just trying to convert the title line, not succeeding yet. - Bruce -Original Message- From: Kieren MacMillan [mailto:[EMAIL PROTECTED] Sent: Sunday, July 09, 2006 10:51 AM To: Fairchild Cc: [EMAIL PROTECTED]; lilypond-user@gnu.org Subject: Re: Evolutionary User Strategery Bruce: > Older scores that have been carefully tuned, compensating for > earlier bugs With all due respect, this implies something about Lilypond that simply isn't true. "Carefully tuned" is one thing. My scores are also carefully tuned; from your work I've seen so far, I dare say I'm far more obsessive- compulsive than you in my engraving standards. Nothing personal, mind you: I'm the most OC engraver I've ever met! ;-) That being said, I spent over an hour cleaning up your "bug- compensating code" yesterday, as an instructional example. What you were (are) doing -- e.g., adding title information directly to skipped notes in a \partial bar before the music actually begins, and then filling the \markup code with offset and spacing tweaks to move it back where it really belongs (i.e., in the header and not attached to the music) -- does not "[compensate] for earlier bugs". It's poor coding, plain and simple. Are there bugs in older (and current) versions of Lilypond? Absolutely. Will many be fixed in upcoming versions? I sure hope so. Ironically, the way that the header block acts as a music system is one of the things I hope changes in a future version... but the fact that my titles are all *in* headers already (instead of counter- intuitively attached to invisible notes between the key signature and the first visible note of my score) will make the migration very easy for me, if and when it happens. Based on the example of your work I helped you with, my conservative estimate is that 90% of your migration woes would disappear if you just wrote proper Lilypond code. I think it's quite telling that, like most on this list, I've had essentially no problems moving forward with Lilypond as it evolves and improves (n.b., I started with v1.8), and you apparently have had nothing but headaches. Ultimately, I would feel it a great loss if HW et al. decided to allow Lilypond to become bloatware in some vain quest for the Backwards Compatibility Grail. Fortunately, I know they're too smart to do that. =) Regards, Kieren. p.s. When Microsoft ruined Word for Mac v5.1 by "improving it" (v6.0 and beyond), I didn't upgrade -- perhaps you might consider taking the same approach with Lilypond? ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Evolutionary User Strategery
Hi, Bruce: First, \header code could only be used once. If this was true at some point [can someone confirm what version this changed?], you could very easily -- with good abstracted code -- have used three different score files (each with their own \header block). Second, I found no way to override the default vertical positioning and font. I seem to recall that you could always use LaTeX markup commands, no? This is a good example where newer capabilities are welcome, but old code should survive. Actually, the old *code* survives just fine... ;-) Good luck, Kieren. ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Fw: Lilypond store?
My intention is to offer downloads of PDF files. My plan was to source from public domain sources, such as archives of old sheet music, and indeed parts of Mutopia which are under certain licence. I'm not sure I understand why I would want to sell printed music - surely, here, I would not be able to compete with publishers selling similar material. In selling downloadable PDF files, you are removing this overhead, allowing you to reduce prices, and be competitive with other places selling sheet music. Also, I don't really have the time to print out & post much sheet music, and would not be able to offer the print quality of a publisher. Unless... are there online services that can print & deliver music? Lulu.com looks interesting - it would eliminate the need for hosting/setting up an online store... but whether the disadvantage of being on a site with a large amount of other work is big enough, I'm not sure. I'd be interested to hear your thoughts, Chris. I initially read this thread as a proposal for offering printed versions of scores for sale. However, on a re-read, I understand that you're proposing to offer downloads of PDF files instead. The attraction of Mutopia for me was the creation of an "open source" archive of sheet music, that people can download for free, print out, photocopy, and distribute. Rather like Project Gutenberg, but for music. If you want to create a rival archive offering pieces for download at a price, then you are of course free to go ahead. Speaking from the point of view of someone who's looked after Mutopia for the last seven years, I think cleaning up Mutopia pieces and organising them for printing would be a very time consuming task. Entering new pieces is of course even more time consuming. From a legal point of view, you will have to be careful what pieces from Mutopia you use. Many are licensed under a CreativeCommons Attribution or Attribution-ShareAlike license. Neither restricts you from selling works based on the Mutopia version, but the latter insists that you release your versions under an identical license (a bit like the GPL). My positive suggestion would be to create a new website offering high quality *printed* LilyPond-engraved music for sale based on Mutopia contributions, still licensed under "open source" licenses. We did some experiments with lulu.com a while ago, and the results were very promising, so that's one possibility. If we work with you on this, and improvements are fed back to Mutopia, then we'd be happy to have links from the relevant Mutopia music pages to your store (ie. "buy a printed copy of this music"). Of course, you can pick music from Mutopia which is already reasonably high quality and likely to be popular. If you're interested, please let me know. I would personally be very disappointed if someone were to "fork" Mutopia. Chris -- Chris Sawer - [EMAIL PROTECTED] - Mutopia team leader Free sheet music for all at: http://www.MutopiaProject.org/ ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Chord Name inside parenthesis
Kieren Thanks a lot! You`re the best! I still dont uderstand it, ill
read about it, but it works great!
On Jul 9, 2006, at 9:52 AM, Kieren MacMillan wrote:
Ezequiel:
how can i make all my chord name be placed inside parenthesis
You can follow Erik's generous examples and instructions: "try
learning Scheme basics and read about tweaks in the manual, and
then try to understand exactly what I meant in my previous
suggestion, and finally try to correct the errors I made."
I did what Erik said, and came up with the attached examples -- I
believe they answer your question. [Difference between the two
examples: the second uses larger parentheses.]
Regards,
Kieren.
p.s. Graham: you're cc'ed because this is a useful tip/trick (I
think)...
__
%%% CODE SNIPPET BEGINS
\version "2.9.10"
#(define (parenthesis-ignatzek-chord-names in-pitches bass
inversion context)
(markup #:line ("(" (ignatzek-chord-names in-pitches bass
inversion context) ")")))
chordset = \chordmode
{
\set chordNameFunction = #parenthesis-ignatzek-chord-names
c1:7 g1:7
}
\score
{
\new ChordNames \chordset
}
%%% CODE SNIPPET ENDS
%%% CODE SNIPPET BEGINS
\version "2.9.10"
#(define (parenthesis-ignatzek-chord-names in-pitches bass
inversion context)
(markup #:vcenter #:line ( #:fontsize 2 "(" (ignatzek-chord-names
in-pitches bass inversion context) #:fontsize 2 ")")))
chordset = \chordmode
{
\set chordNameFunction = #parenthesis-ignatzek-chord-names
c1:7 g1:7
}
\score
{
\new ChordNames \chordset
}
%%% CODE SNIPPET ENDS
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
melismatic left-alignment with \lyricmode
Dear Lilypond users and developers,
I am using 2.8.3 to engrave chant for TTB. I normally use \lyricmode for
such music because it gets the lyric-extenders right regardless of which
voice has the melisma. But now I am noticing that it isn't getting the
left-alignment right. Lyrics are only left-aligned under melismata if there
is a melisma in the topmost voice. Here is my example:
\version "2.8.3"
global = { \set Score.timing = ##f \key bes \major }
\score {
\context ChoirStaff <<
\context Staff = top << \clef "G_8"
\context Voice = tenone \relative c' { \voiceOne \global c4 d8([
c]) bes4( a) g a bes2 a g a \fermata }
\context Voice = tentwo \relative c { \voiceTwo \global f4 f f2 f4 f
f( g) g( f) f( ees) d2 \fermata }
>>
\context Lyrics \lyricmode { In4 that day2 __ all4 his thoughts2 __
shall __ per -- ish. }
\context Staff = bottom << \clef "bass" \relative c { \global
{ bes4 bes bes2 c4 c d( c) c( bes) c2 d \fermata }
}
>>
>>
\layout { \context { \Staff \remove "Time_signature_engraver" \remove
"Bar_number_engraver" }
\context{ \Lyrics \override LyricSpace #'minimum-distance =
#.8 }
}
}
As you can see, the lyrics "that" and "day" are left-ligned (i.e. when
tenor1 has the melisma) but "thoughts shall perish" are not left-aligned.
The last words are instead center-aligned under the first tenor's
half-notes.
Am I doing something wrong? I've not noticed this before. I know that I can
left-align specific lyrics with a \once \override maneuver, but I'd rather
avoid that since it would happen quite often.
Monk Panteleimon
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: navigating web documentation
([EMAIL PROTECTED] Hmm, never heard of it ... trying bug-texinfo) >> Has anyone considered putting the navigation links at the bottom You're the first person to suggest it that I know of. It sounds reasonable to me, although it would look kind of funny on very short nodes, as so many are. Also, I think it might be confusing in the all-on-one-page-html output, since it would be right next to the pointers of the "next" node. Have to try it, I guess. A patch would be most welcome :), else I'll get to it as soon as I have a chance. I think it's "Alt-P" for previous, 'Alt-n' for next, 'Alt-u' for up. Maybe it should be mentioned somewhere in the texinfo output. Sure, I suppose at least the main keyboard shortcuts could/should be in the manual. I know some open source web software can do this. I'm not sure who wrote this, but whoever did, just in case you're not already well aware, GNU is about freedom, rather than "open source". http://www.gnu.org/philosophy/free-software-for-freedom.html Anyway, thanks for the suggestions. Karl Date: Fri, 07 Jul 2006 13:11:43 +0200 From: Han-Wen Nienhuys <[EMAIL PROTECTED]> To: Trevor Baô a <[EMAIL PROTECTED]> CC: Paul Scott <[EMAIL PROTECTED]>, lilypond-user@gnu.org, [EMAIL PROTECTED], Karl Berry <[EMAIL PROTECTED]> Subject: Re: navigating web documentation Trevor Baô a schreef: > (I second this, especially since I've been reading pages continuously > through much more with the newer manual ...) > > On 6/29/06, Paul Scott <[EMAIL PROTECTED]> wrote: >> Has anyone considered putting the navigation links at the bottom of our >> wonderful! (Thanks, Graham and others) documentaion pages in >> addition to at the top? I usually find myself scrolling to the bottom >> of the page (some of which are quite long) and then having to scroll >> back up to the top to go somewhere else. I know some open source web >> software can do this. I recommend the keyboard. I think it's "Alt-P" for previous, 'Alt-n' for next, 'Alt-u' for up. Maybe it should be mentioned somewhere in the texinfo output. Karl? ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: navigating web documentation
Karl Berry wrote: ([EMAIL PROTECTED] Hmm, never heard of it ... trying bug-texinfo) >> Has anyone considered putting the navigation links at the bottom You're the first person to suggest it that I know of. It sounds reasonable to me, although it would look kind of funny on very short nodes, as so many are. I don't see why. Also, I think it might be confusing in the all-on-one-page-html output, since it would be right next to the pointers of the "next" node. Intelligently enough those navigation links are not included in the all-in-one-page-html output. Have to try it, I guess. A patch would be most welcome :), else I'll get to it as soon as I have a chance. I think it's "Alt-P" for previous, 'Alt-n' for next, 'Alt-u' for up. Maybe it should be mentioned somewhere in the texinfo output. When Han-Wen pointed the above out I realized I was not concerned about my original request any more. I prefer keystrokes to the mouse any way. Sure, I suppose at least the main keyboard shortcuts could/should be in the manual. Agreed. I know some open source web software can do this. I'm not sure who wrote this, but whoever did, just in case you're not already well aware, GNU is about freedom, rather than "open source". http://www.gnu.org/philosophy/free-software-for-freedom.html Don't know what your point is. I was just suggesting that there was already free code to do what I had originally suggested (at least for the HTML version). Anyway, thanks for the suggestions. You're welcome for the part I played in this, Have fun, Paul ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
