Re: Version control tools
On 07/01/14 14:51, Urs Liska wrote: I don't think it would be advisable to encourage any _new_ user to learn SVN or CVS (if it isn't for a specific project of interest), but for your use case this is surely a valid question. One way in which svn can still be useful is in cases where you want the code but don't care about having a local copy of the version history. Example: recently I needed the latest gcc trunk source. Cloning via git-svn or bzr-svn proved extraordinarily slow and painful simply because the history was so large; taking a svn checkout was much quicker and easier, and (obviously) also used far less disk space; and it was completely adequate to purpose, because all I wanted was the ability to keep the code up to date, not to commit to it myself. I do wonder if this is one of the reason why some projects keep svn as the main VCS, using git or other DVCS mirrors for those who want to use them. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
On 08/01/14 21:13, David Kastrup wrote: Actually, that seems like a mischaracterization to me. It's the single file logs which aren't cheaper than the multi-file logs. You could be right. In any case, the Facebook devs are claiming wins for all change-related commands, including status, diff, update and commit: https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/ At the current point of time, due to a discussion about version control on the Emacs developer list, I am working on git blame which is ridiculously slow. For the file src/xdisp.c, it takes about 2 minutes on my computer. I've cut it down by some 20 or 30% on the first attempt, but with my current approach, I should eventually get it down to few seconds at most. At the current point of time, it segfaults almost instantaneously. One out of two ain't bad... Ridiculous that this code has not been sensibly improved over the last 10 years or so... It's a surprise to me, certainly. What do you think of the Facebook developers' contention that Git's internals would be difficult to work with if serious scaling gains are desired? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Version control tools
On 08/01/14 19:40, Yann wrote: With hg, each clone of a repository IS a complete repository itself. So your "working copy" is a repository itself (the main folder just contains a hidden .hg folder with all the history data). I feel this is an advantage over svn when working locally, as your data and the history are at the same place. Exactly, as with git (which Lilypond uses) and bzr (a very nice tool as well, but now sadly somewhat neglected). If reddit is to be believed, it looks like hg has picked up a bunch of recent interest and investment from Facebook in order to optimize things like single-file diffs (which in git are no less expensive than whole-repo diffs). So for those interested in these tools, it might be worth giving it a try. Perhaps the DVCS landscape is not as settled as it has looked recently ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 08/12/13 22:42, Janek Warchoł wrote: My experience says otherwise (maybe because my choir is not professional): we continued to sing this moment badly for the next 5 years. Well, then your complaint is certainly valid! :-) I have seen it about 10 times already, in scores coming from different people. I can send you more examples in private. Question -- were these all or mostly vocal works? I don't remember any similar examples from my own use of Finale, but it's been quite a long while, and of course I was producing instrumental works. I have a feeling the inclusion of lyrics might be affecting the spacing. Well, if we're speaking of hand-written stuff, then yes. But as far as the "engraved" output from notation software, i havent' seen much worse problems. I have, and in a published score at that, but I think it was the fault of an earlier version of one of these notation programs, and almost certainly a publisher who didn't know how to use it (and obviously didn't care about quality control). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 07/12/13 20:21, Urs Liska wrote: I think fixing the Finale part (reliably) will be much more problematic, at least with this kind of music where the complexity leads to that amount of catastrophic results as in the Finale version. That's why you want to run the test, to see if a good and enthusiastic Finale user can rise to the challenge! :-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 07/12/13 19:54, Urs Liska wrote: But once we're going to compete with people from other tools' mailing lists it will probably become a real (and therefore less informative) competition. Well, if you couch it in terms along the lines of, "Hey, we're just trying to improve our software here, we all want the best software" and make it a friendly game rather than a "Hey, we're better than you!" exercise, I don't see that it need get too serious (at least in the sense of unfriendly competition). Anyway, there's a limit to how competitive it can get simply by virtue of the fact that Lilypond can be tweaked in response to how it does in such a competition, whereas with Finale, the development team has to take notice :-) Personally I would approach the Finale community with an invitation that gives the impression that you expect to come out worse in this comparison (because after all, it's about productivity rather than default engraving quality), but that you hope to learn something from the exercise. Then, if it's true, appropriate gratitude can be shown and lessons can be learned -- while if Lilypond comes out ahead (in which case, it should also be approached with humility rather than triumphalism), hopefully a few Finale users will start taking Lilypond more seriously. The important thing to recognize is that Finale and Sibelius users are not the competition. They're fellow dreamers about excellence in music notation software. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 07/12/13 20:05, Urs Liska wrote: I have to throw in a comparison: http://lilypond.ursliska.de/uploads/pics/07_02.png http://lilypond.ursliska.de/uploads/pics/finale2008_one-system.png These are an excerpt from a copyright piece, but I've got permission to display in the context of a tutorial and of a blog post (they're in my plain text essay on the blog). I think this is a very good example for the fact that LilyPond often manages to produce legible layout even if it fails. Actually the only thing that's _really_ wrong with this example is the long slur - but that's of the kind I wouldn't expect any automated engraving to manage. Finale (admittedly 2008 - but LilyPond is 2.13 too IIRC) managed to clash about every conceivable grob in this case. Yes, but you're comparing default behaviour to default behaviour. I think we can all agree that Lilypond almost invariably wins in that comparison. The reason I proposed a competent-user-vs-competent-user comparison is that a competent user wouldn't leave those clashes in place but would manually tweak them. If those manual tweaks are quick-and-easy to make, then those faults of default behaviour may be considered much less serious. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 07/12/13 19:39, SoundsFromSound wrote: I could assist with Finale 2014 though I hesitate to call myself an 'expert' in Finale. Power user maybe, but no expert. Does that help? I think that "power user" would be fine for the kind of test run I proposed. I mean, so long as you don't let your affection for Lilypond bias your performance ... :-) After all, the fundamental purpose of a trial like this is to have some kind of estimate of the relative productivity that capable users of the software can enjoy. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 07/12/13 19:18, Janek Warchoł wrote: Have you looked at "Eja Mater awful Finale.pdf"? Do you consider the issues marked in red minor? They actually make it very difficult to sing the rhythm correctly! That one example in bar 69 is very "ouch", but it's the kind of problem that would be an issue for sightreading only -- you'd fix it and move on. I agree it's nastier for choral singing (where everyone has the score) compared to instrumental playing, where you'd have just the single part and so only the conductor would have to handle that rhythmic clash. I have to say that I do wonder if that was user error, though -- because I never came up with such a catastrophic misalignment when I was using Finale. At a guess, perhaps caused by the user entering more notes than could fit in the bar, then deleting some of them, or otherwise correcting note lengths? The one in bar 80 doesn't strike me as much of an issue. An irritation but not in any way a serious problem, because it isn't out of sync with anything else horizontally. I was far more concerned about the placement of the dots on the dotted 8ths, because that _did_ seem like something that could jar the reading of the single line parts, even when you "know" the rhythm. I don't mean to dismiss your concerns here, but I think that these problems are small fry in the scale of the kinds of illegibility or ambiguity or simply reading difficulty that there can be in parts put in front of musicians. You probably haven't seen some of the hand-written parts (from reputable publishers!) that I have ... :-) Do you have a spare expert Finale user? Because the problem is that on the *LilyPond* mailing list it's hard to find expert Finale users. We'd have to hire someone, and that costs money. No, but I imagine that if you went on the Finale mailing list and said, "Hey, we're trying out this challenge as part of a drive to test and improve our usability, anyone up for it?" you'd get some volunteers. You don't need a super-hot-whizzkid-who-works-for-Bärenreiter, you just need someone who is competent and capable and knows their way around the software. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: on marketing
On 07/12/13 18:07, Jan Nieuwenhuizen wrote: Beethoven's 104 Piano Sonatas That would be 32 :-) But 104 separate movements in total ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 07/12/13 17:55, Phil Holmes wrote: Patches welcome. Should I take that as conceding the argument in principle? :-) I know it's frustrating to see so much discussion and no code, but one reason people discuss so much is because they want to make sure there is a solution that will satisfy everyone. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 07/12/13 17:43, Phil Holmes wrote: So we have to have even more large files residing on the server, when we already have enough. This assumes that it isn't possible for the basic installer to be a lightweight tool that contains nothing itself, but that downloads and installs selected individual components. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 07/12/13 17:14, Phil Holmes wrote: I've already said I oppose this, and I'll restate this. I think it's unfortunate that your opposition consists of just saying "no", rather than trying to work out if there are ways to get what you want _and_ get what other people are suggesting. For example, your objection is based on the assumption that every time there's a new Lilypond release, you'll have to go to the Lilypond website, download a new installer, and install over the old version, remembering each time to deselect the install components you don't want. You assume that (for example) it's not possible for the installer to auto-detect your existing implementation and by default select only the installed components to upgrade; or that it's not possible for the Lilypond install to include an upgrade tool which alerts you to the existence of a new release and downloads and installs the updated components for you. All of this requires somebody to look into how to achieve these things, and to implement them. People shouldn't be discouraged from exploring these possibilities by pre-emptive judgements about what they will come up with. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 07/12/13 16:52, David Kastrup wrote: The last time I thought that was when I wanted to compare how much worse Emacs fared when using it for working on LaTeX files compared to a specialized simple text editor called Kile or something. Emacs hit in at over 16MB with my current work session (granted, containing quite more than just a LaTeX file). Then I started Kile and it swallowed about 90MB of memory, mostly because it pulled in half a dozen libraries and demons, getting those KDE parts up that it needed for operation. Don't underestimate specialized simple text editors. Indeed, but still small fry compared to what Lilypond can eat up on some scores :-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 07/12/13 16:49, Janek Warchoł wrote: you're probably right. as i said, i don't know this stuff. Well, in this case I think it's not about what you know -- it's about what you think is best to do. If it turns out that the easiest way to organize things is to have one install bundle for all platforms, fine, but as things are you already have differences in how things are set up in the Windows vs. Linux installers. The thing to focus on probably just needs to be, what's the best way to serve a new user of Lilypond on this platform? And in that case, providing Frescobaldi as part of the default install on Windows makes sense (but as I said, with the option to deselect it there for users who have other preferences). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 06/12/13 23:37, Janek Warchoł wrote: Well, i'm not familiar with this area, but keep in mind that one has to find a free, open-source solution that works for every platform we support (Win, Mac, various Unixes) and can be automated. It's not enough to go and create one installer - we need software that would recreate such installer, without manual intervention, for every release. I don't see why you assume that. There's no particular reason why you need an identical bundled install for every platform -- different platforms come with different expectations on the part of users, so it should be fine to have e.g. a Windows installer that bundles Lilypond with an appropriate IDE, whereas on GNU/Linux you just install Lilypond itself. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience
On 06/12/13 00:47, Mark Stephen Mrotek wrote: Since I am not a programmer, I am not sure why, yet when I double click a .ly file in Windows 7 Frescobaldi opens (rapidly) and displays the code. I would imagine that when you install Frescobaldi, it updates the Windows file config such that Frescobaldi becomes the default program with which to open files with the .ly extension. That _will_ be quick, because it's just opening a text file in a specialized text editor. It's not the same as running Lilypond itself on an input file. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 06/12/13 20:02, Urs Liska wrote: Some more aspects to this: How reliably can these faults be fixed? What happens to the fixes if you screw up with a tweak. What if the layout changes because of corrections or a different paper format? How can someone else fix issues in a score? etc. etc. Yes, all fair questions. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 06/12/13 17:59, Ryan McClure wrote: While I think this is a good idea, I have a few reasons to hesitate. We don't want to just promote LilyPond to expert users; wouldn't we want any user to switch over? Any professional can make anything look good. An expert Micro$oft Paint user could probably reproduce the Mona Lisa if given enough time. Yes, "if given enough time". The point of the comparison is to show the productivity of users of the software, measured in terms of the quantity of quality output they can produce in a fixed space of time. The reason to go to expert users is so that you don't bias the outcome from unfamiliarity or ignorance of the software. What LilyPond does better than Finale/Sibelius is more excellent default engraving. How many times have people used Finale and gotten that dreaded last-bar-on-its-own-page problem? I believe the best test would be using ONLY defaults for Finale, Sibelius, and LilyPond to show what the programs can do--not what experienced users can do. I disagree, because the faults of default Finale output are not serious faults if they're quick and easy to fix. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: engraving comparisons and other "promotional" materials
On 05/12/13 21:18, Janek Warchoł wrote: as promised, here are engraving comparisons that i hand out to musicians i meet: What Finale version are you using to generate these examples? I hate to say this, but from my point of view (as a Lilypond user and enthusiast) I think that rather than favouring Lilypond, this rather supports the contention that in general Finale's output is "good enough". I presume what you have there is untweaked Finale engraving, and many of the issues you identify are very minor or most likely easily fixed. The only thing that I can see that really irritates and really seems dangerous from a performing perspective is the dot on the dotted 8th notes, whose regular misplacement does create some potentially nasty reading ambiguities. If you want a real comparison, give two expert users -- one of Finale, one of Lilypond -- the same score and give them an hour to engrave as much as they can, with the goal that every single bar they engrave is perfect. Then compare what they achieve. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A thought on Windows Experience (was: useability, promoting, etc)
On 04/12/13 19:02, Phil Holmes wrote: For me, I'd say that we should not install Frescobaldi as a pre-requisite of running Lily on Windows. I'm a heavy Windows user, and would not want another program installed by default. I've not used it, but I do understand that many people feel it's excellent - so an option would be to promote it more heavily for Windows users? Yes, but arguably the default configuration should be what is best for new users, and installing Frescobaldi does make a certain amount of sense here -- it's an excellent dedicated "IDE" for Lilypond that really makes it easier to understand the process of creating scores. The way many Windows installers work is that they present you as a user with a list of components to select to be installed, of which some will be selected (or not) by default. There's no reason not to have Frescobaldi bundled with the installer but deselectable if you don't want it. I am willing to look at improving the Windows experience, although this would need to wait until my degree finishes next Summer. However, there's one thing I don't know: what should happen when you double-click a .ly file in Explorer: open an editor or compile the file? Open the file, I'd say. It'd be pretty intrusive if simply double-clicking on a text file in Explorer was to cause the launch of a process that might take a very long time, consume a large amount of system resources, and generate a large new file to write to disk. It's also at odds with the way in which source files for other markups and languages are treated when opened via the file browser. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
On 04/12/13 11:18, David Kastrup wrote: It's not really a discussion: I am just reiterating points already made a lot of times with regard to Free Software. Corporate parents can easily become a liability rather than an asset, and when that happens, you are powerless as a user. Yes, I'm very familiar with those arguments, and in the general sense I strongly agree with them. It's just that in practice, based on experience, I find that the weight others will give to those arguments tend to vary a great deal based on context. So, if you're trying to promote your software solution to other people, you need to tailor the message with that in mind. For example, the risk of your software ceasing to be maintained or developed is often (for good reason) not seen as a high risk by users of major proprietary software tools. The risk of a business decision being taken that undermines the software's usefulness is taken much more seriously, but even then that risk gets offset against costs of migration, and the perceived maintainability of alternatives. In that context having a corporate body to deal with is generally considered a major plus (and a volunteer community, often something of a negative) regardless of the licensing situation, because it generally attests to the economic sustainability of the software in question. So I'm not disagreeing with you or the general free software philosophy, I'm just pointing out that -- like free-as-in-beer -- not all of these benefits are necessarily perceived as such by prospective users. And I think one particular point you raised fits that bill. So we need to get LilyPond into the shape where an average programmer caring about mongolic double flute music can do what is needed to let LilyPond support it nicely without too many unexpected road blocks. Yes. Generally speaking whenever I consider some development idea in Lilypond, I quickly come up against the realization that the investment of time required just to work out how to _start_ doing it is extremely large, and doesn't bring with it a lot of transferable knowledge. So, it's difficult to justify putting that effort in compared to (say) providing an overview of what I want and offering a bounty. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
On 04/12/13 10:33, David Kastrup wrote: Uh, the original developers of Sibelius made Avid an offer for buying Sibelius back. The offer was turned down. Happy to have this discussion if you want it, but I think it's getting away from the point I wanted to make. It's simply that I don't see the risk of proprietary software stopping being maintained or developed as one that is appealing to many current Finale/Sibelius users. The risk of the software being sold to an irresponsible or greedy investor, or the risk of development being messed around with for commercial reasons, is a different risk (and an argument that IMO carries much more weight). I understand that we may have simply been talking about the same thing in different words, though. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
On 03/12/13 22:47, David Kastrup wrote: You are aware that the Sibelius development team has been laid off due to financial problems of their parent company in spite of Sibelius having a paying market and turning a profit? Yes, fully. But there is still _a_ Sibelius development team, there is still commercial support and maintenance available, etc. etc. The worries are obvious, but only time will tell how damaging this really is to the software. Well, you can't lay them off, and you can't prohibit them from continuing to work on their software like the original authors of Sibelius who have no right to do anything with the sources written by themselves any more. And you can't prohibit anybody else from working on LilyPond in order to meet a company's needs. You should not take my words as an endorsement of non-free software, merely a recognition of the factors that many users take into account. Whether or not we like it, there is a general perception that commercially-backed software (whatever the licence) is in general more viable and future-proof than volunteer-driven efforts. Yes, the processes of contribution-based free software "break" in different ways to the processes of commercial proprietary software -- there are different risks and different benefits. But the fact is, someone using Sibelius now does not have to worry about the product being discontinued. Even if Avid decided to discontinue the product, its userbase, brand value and commercial viability would mean that someone would step in to buy it. By contrast, I do worry about what happens to Lilypond if for example you find yourself indisposed. I think we can all agree it would be a severe blow. :-) No question about that. I think a necessary step would be to move to GUILE2 first because the costs and tradeoffs of refactoring stuff between C++ and Scheme will be different, so this is more or less a prerequisite to make decisions and be able to factor in their costs. Makes sense to me. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: promoting LilyPond
On 02/12/13 16:00, David Kastrup wrote: How about companies which cannot risk getting locked in to software that may stop being maintained in future? I'm not sure that's a selling point, either. As long as there's a paying market, commercial software tends to keep getting maintained. By contrast the risk with Lilypond is that it's vulnerable to the continuing contributions of a fairly small set of core volunteers. At any rate, we need to pitch LilyPond to _ourselves_ and listen what annoys us. Particularly when explaining LilyPond to others and/or pitching it to them. A good rule of thumb is, to ask "What is easy to do by hand but hard to do with Lilypond?" But you can also add to that the question, "What is easy to do with Finale/Sibelius but hard to do with Lilypond?" and "What is hard to do with Finale/Sibelius and can we find a way to make it easy?" I don't suggest just casually asking those questions but really documenting extensively the evidence and experience of users. Some of those things will come up against David's "play to your strengths" remarks -- there are going to be things which are unavoidably difficult in order to make some other things very easy, and those will not be the same between Lilypond and WYSIWYG engraving software. But on the other hand, I am not convinced that the most practical way to improve Lilypond's future is not to look inside and focus on making sure the internal design of Lilypond's codebase is optimal from a future-development-and-maintenance point of view. Graham pointed out to me not so long ago that a problem with new enthusiastic contributors is that they can come, "fix" some issue and in the process break so much stuff that it costs far more time to correct it than to just reject the contribution out of hand and have one of the existing developers do the work. Trying to think about how the codebase could be refactored so that this isn't likely to happen seems to me to be a potentially productive way to expand and engage the Lilypond community. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Other programming languages & LilyPond
On 02/12/13 22:20, David Kastrup wrote: Scheme _is_ its scripting language. How much scope is there for creating a stable "scripting API" which could be used via Scheme (default) or any arbitrary language of choice, so long as someone writes bindings for that language? I ask because in our earlier discussion about tweaking, we discussed how large numbers of tweaks render a score effectively tied to a given version of Lilypond. But if there can be a promise, "This scripting API will be future-proof," then maybe that kind of impact can be reduced, and a side benefit would be the potential to script with languages other than Scheme. Obviously any such API would cover only a subset of the possible tweaks to Lilypond, but that'd be effectively the point, separating tweaking into "safe" and "unsafe" things to mess around with. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 01/12/13 15:09, immanuel litzroth wrote: 1) I don't seem to run into many of these problems with lilypond and I do transcriptions of small ensembles *and* export all the voices separately (that's including drums) -- I almost never have to clean up for readability issues, and don't have the time to do it for aesthetic issues. Lilypond is generally better at automatically placing most musical elements in the right place. There are usually fewer score --> parts discrepancies in Lilypond-engraved works as a result, but the general problem is still something that needs care and attention. Don't forget, too, that part of the reason you get good results out of Lilypond is because _you_ are the one using Lilypond and you know what it is that you want to achieve in the score. Part of the reason you know that you rarely have to clean up for readability issues in the parts is because ... you actually check the parts. It's probably more than can be said for your Sibelius-using suppliers. :-) After all, if they'd given a toss about the parts, that guitar part would have at least had a cue melody line in it ... 2) The contention was that this stuff would be easier in Sibelius. Not that you can get it right there too. Sibelius doesn't get things automatically right as well as Lilypond does, but it's usually much, much easier to correct or customize them when it doesn't give you what you want, which in turn means that it's easier to get what you want in general. But the lack of automation does make you vulnerable to idiots who don't do proper quality control or who have no clue about what is wanted. I don't know if you use or have used Sibelius, but if you're judging it solely on the grounds of the bad parts you get from bad suppliers, you're not really assessing the software at all. The real measure of engraving software shouldn't be, "How readily does it stop an idiot from getting it wrong?" but, "How readily does it let a user achieve the notation they want to achieve?" For the record, I'm not speaking out in favour of Sibelius in any general sense here. I just think that one should try and understand why it is that software like this has the user-base and staying power that it does. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 01/12/13 14:56, immanuel litzroth wrote: Here's a nice example. That's almost certainly someone writing to full score (which has particular spacing properties) and auto-exporting to parts without ever actually looking at them. Surprise to surprise, the horizontal spacing issues are different in an individual part than in a full score, particularly if (as in this case) the part is _all_ chords with no notes to space things out. (Although why they don't in that case put in a cue melody line, I can't imagine. Makes no sense to me.) I would imagine these pieces are meant to be performed by ad-hoc ensembles which are not necessarily consistent in instrumentation. So probably what happens is, Random Engraver takes all the possible instrument choices, throws them into one giant full score, gets it looking sort of all right there, and then exports the parts without a second thought. It's a recipe for disaster. This is not really a fault of Sibelius -- similar problems can happen with Lilypond if you proofread full score but not individual parts. (For example, imagine a hairpin that's spread over quite a wide horizontal space in the score, but a fairly narrow space in the individual part: it may need a custom tweak to look right in the second case.) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 01/12/13 14:13, immanuel litzroth wrote: I follow a music education program that requires me to play in a combo 1 hour a week. The scores there are prepared by paid professionals, usually in Sibelius. They are invariably late, and usually unreadable when they arrive. Chords on top of each other, confusing spacing and layout, although they are normally just a melody (if even that) without any articulation marks and some chords. Sounds to me like, regardless of the software involved, you are paying the wrong professionals. Out of curiosity, what form do the scores arrive in -- paper, PDF, ... ? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 01/12/13 14:00, Kieren MacMillan wrote: I disagree somewhat… and so do most of my Finale- and Sibelius-using friends and colleagues, who complain endlessly about how much time it takes to tweak scores and parts. How does that compare to their reaction to Lilypond? I would guess amazement at how much Lilypond gets right, but frustration with how relatively complicated it is to enter a score and see the results? And probably overwhelming frustration when they hit the point of wanting to tweak something? What *is* true is that beauty in engraving is less of an issue to most people than just getting it done. Actually, what matters to most end user is to have something “good enough”… and, I’m sad to say, Finale and Sibelius do that (for them) with almost no tweaking at all. Yes, and this is overwhelmingly true of most things in life. "Easy to get it good enough" almost always wins over "difficult but gets it perfect". When I compare Finale/Sibelius output with hand-copied (not hand-engraved!) parts from earlier years, which was the norm for a lot of new works, there is very rarely any contest. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 01/12/13 12:49, David Kastrup wrote: I don't think this sort of preplanning works out well. Mostly it just leads to people going away until the stuff they are not interested in is done. We need to figure out better ways to work on parallel and partly conflicting goals. Yes, I guess that's a risk. :-( Perhaps if you start by getting all the key developers to commit to trying to communicate and discuss with all the others exactly how their part of the backend works ... ? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 01/12/13 09:45, David Kastrup wrote: Finale output is ugly to the degree where it is distracting readability, particularly for instrumentalists. Sibelius' corporate parent has fired its core developer team in the UK, including its original authors. Steinberg does not yet have a finished product on market. Most other players are fringe players. The situation is not really all that unfavorable for LilyPond. The default output of Finale is indeed ugly, and I was reminded that Sibelius too has its problems when I recently received a score from a friend which would surely have looked much better done in Lilypond. The thing is, though, both are so easy to tweak, it doesn't matter. My Bärenreiter scores engraved (presumably) with Finale may be less beautiful than the obviously hand-engraved earlier publications, but they are entirely satisfactory so far as reading goes. Most practical readability problems arise because of publishers (or composers) who put inadequate work into copyediting parts, not because of the software used. I don't say this to discourage anyone, but just to note that what matters to the end user is very often the facility to get the score _just as they want it_, not the ability of the program to automatically second-guess their desires. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Supporting my work on LilyPond financially
On 30/11/13 21:40, David Kastrup wrote: The backend is much less coherent, so expertise is harder to acquire, people tend to work with partial knowledge, and progress is a lot more fragile. We need to get those four months down, and yes, a shouting match is not going to help. What will help is refactoring and rearchitecturing, and that needs people with a thorough programming background. Is it perhaps worthwhile having a purely "backend cycle" where _all_ development effort is focused on turning the backend into something that's easy to work with? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: text accidentals [was Re: film score example]
On 30/11/13 12:30, Janek Warchoł wrote: We'll see how to split the amount between sponsors when i'm finished - i originally intended to do just flat, natural and sharp, so doing all microtonal accidentals may take me extra time. Why don't we split the task? Regular accidentals first as a proof-of-concept, all current accidentals second as an extension of the work. Two separately sponsored pieces of work. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: film score example
On 30/11/13 00:03, Janek Warchoł wrote:
2013/11/29 David Kastrup :
Why not use the Unicode charpoints, like B♭, F♯ and so on? They are
_supposed_ to go well with the text font and kern properly.
because *we* have the most beautiful musical font in the world? ;-)
I've looked at the output of
\markup { B♭ F♯ }
and it is *hideous* (see attached). Totally unusable.
But if you go with text + Lilypond accidental glyphs, you have the challenge
that the optimal combination will vary depending on the text font. Not all of
us stick with the default, you know :-)
That said, I agree with you that the use of these combinations of Unicode glyphs
does not seem to work well (I tried out a few different fonts in LibreOffice
just to compare and contrast; uck).
2013/11/29 Joseph Rushton Wakeling :
Actually, I wonder if rather than special glyphs, it might be better to have
a function like \pitchText which takes a Lilypond pitch and transforms it
into an optimized textual form: so e.g. \pitchText{bf} or \pitchText{fs} or
whatever. (I'm using English note-names here.)
Hmm. IMO, we should first fix \flat, \sharp and \natural and then
think about writing such function (since it would use these commands).
Amusing example for the size and baseline problems you mentioned: try,
\markup{"Here are some accidentals: " \natural \sharp \flat}
... and see what you get :-)
It's just that so far as I can see the ways one might want flat/sharp/natural
signs to be used in text are sufficiently different that no matter what the
default position and size, there may need to be tweaking for a particular use.
Hence why I suggest a dedicated function for pitch texts.
Anyway, let's be in touch off-list about sponsoring the text accidentals work
you propose.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: film score example
On 29/11/13 15:45, David Kastrup wrote: Why not use the Unicode charpoints, like B♭, F♯ and so on? They are _supposed_ to go well with the text font and kern properly. Should fit nicely with the idea of a \textPitch function I floated in the other email. Are there any international-note-names issues that need to be taken into account with this approach, though? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: film score example
On 29/11/13 15:34, Janek Warchoł wrote:
What do you think about \at function that David wrote?
(see snippet here
https://github.com/openlilylib/snippets/tree/master/input-shorthands/articulations-not-aligned-with-notes)
The syntax is a bit awkward, but this function already does exactly
what we want: allows to insert dynamics and other things in the middle
of the note's duration. I think it's very nice.
Not familiar with it. Will check it out and see how it goes -- thanks! :-)
Thanks to David's work on issue 3330
(http://code.google.com/p/lilypond/issues/detail?id=3330) the spacing
between B and flat symbol is better since 2.17.19 (see attached). Of
course, the accidental still has wrong size and baseline - i think i
could handle that by creating special versions of accidentals for use
with text (see
http://lists.gnu.org/archive/html/lilypond-devel/2011-09/msg00353.html).
Would you like to sponsor this? For $20 i could add special
accidentals to LilyPond font and adjust \flat, \sharp and \natural
commands to use them (and maybe others like \semiflat, if i'll have
time).
Yup, sure. How do I go about sending you the money?
Actually, I wonder if rather than special glyphs, it might be better to have a
function like \pitchText which takes a Lilypond pitch and transforms it into an
optimized textual form: so e.g. \pitchText{bf} or \pitchText{fs} or whatever.
(I'm using English note-names here.)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: film score example
On 13/09/13 05:54, Curt wrote: - Hairpins are surprisingly difficult. Most instruments do not have a natural decay, so hairpins don't necessarily start or end right at the note boundaries. It's necessary to use "fake voices" in these cases. Even with this, it didn't support having a decrescendo end at the Fine bar - I had to make it end at a note value before the Fine bar. And if you have ties over these fake voices, you have to know about \set tieWaitForNote = ##t This is for me one of the single most frustrating things with Lilypond. Hairpins that don't begin or end with a notehead or rest are such a typical musical notation, so easy to do by hand or with a WYSIWYG score editor, and really annoying and finnicky to do with Lilypond. - The alignment of the flat sign in text markup like "Clarinet in Bb" is difficult. I gave up on this one because the approach to make it look right felt too hard-coded. I "solved" this in some scores by defining an entity \Bflat that was the B combined with the flat sign in the right relative position and size. Imperfect but doable. - It was extremely hard to specify a subito dynamic right after a hairpin. This is a relatively common use-case, but I had to pull in a pretty complicated scheme function, and modify it, to make it work as expected. This one requirement probably took around six hours. If I recall right, doesn't this stem from the fact that default minimum hairpin length is expected to _include_ the dynamic mark's width? So any dynamic mark which contains more than 1 letter can mess up the display of the hairpin (I've even seen cases where the hairpin itself was so narrow it was pretty much a single vertical line -- the angle between its arms was a full 180 degrees!). I think the solution here is probably that there be a real minimal length for the hairpin alone -- this matches what one sees in e.g. the Henle hand-engraved scores, where (if you remember the video that was posted) the very smallest hairpins are not hand-engraved but stamped with a custom die. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Discussion: automatic engraving and single-source publishing
On 26/11/13 11:01, David Kastrup wrote: Sure. For that reason, I consider much of the time spent on tweaking and tweaking tools a waste of lifetime better spent on trying to get the automatisms right. Of course, that option is harder and requires different resources. But it only needs to be done once. I don't think it's helpful to see these things in opposition. Virtually all practical engraving scenarios involve needing to make _some_ tweaks -- any difficulty in doing so is a block to the usability of Lilypond and hence a block to growing the user base. A growing user base corresponds to a much broader range of engraving scenarios and hence feedback that helps drive automation. Put it another way: your ability to automate is always limited by your ability to grasp the range of user requirements and to implement solutions for them. It makes you the bottleneck. Facilitating users' ability to easily customize everything by contrast frees them from the limits of your own vision and time constraints. In one aspect of this, Lilypond is already one of the best tools, because it liberates the user so very greatly. But in terms of the _ease_ of enjoying that freedom, it's far too limited, particularly when it comes to "trivial" tweaks. I think that you personally are quite right to focus your efforts on automation, but it doesn't mean that the efforts to build friendly tweaking tools are a waste of time or resources ill-spent. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
On 14/11/13 15:05, Jan-Peter Voigt wrote: there is an update of this snippet in the mail archives and I will post my version later. Fantastic, thank you! :-) You're right, but I would take this as a proposal to add this as a standard command to lily. Yes, I agree. In fact for optimal usability, I think it should be an on-by-default feature, as the most likely use-case for voices sharing a staff is for the rests to be combined where possible. One can always compare, who does it best. But IMO the metric of doing it good,better,best is not a one-dimensional one. Oh, sure. It's just that I get uncomfortable whenever I see people respond to news of a good feature in another piece of software with remarks along the lines of, "Hey, but we do [other feature] better" or "Hey, you can already do that by [complicated method that's much harder than the other software]". I think that it's always very important to try and understand why people see value in other software, and what things it provides that one's own tools don't. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Learn from Finale 2014 (seriously)?
On 14/11/13 11:16, Jan-Peter Voigt wrote: there is a snippet in LSR: http://lsr.dsi.unimi.it/LSR/Item?id=336 which did this for a long time. "Please note that multi-measure rests are not automatically combined." In addition, it hardly matches the ease of the Sibelius/Finale features if the user has to copy-paste a bunch of Scheme code into their project to achieve the desired result. I'm not trying to bash anyone's work, just to note that when comparing to other projects, one should not focus on who did it first, one should focus on who does it best -- and how to match that best performance. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ferneyhough-style Interruptive Polyphony
On 06/11/13 17:06, Urs Liska wrote: Really? From my experience publishers don't have/make problems with giving a free licence to use such an excerpt for such a purpose. IIRC stuff in the LSR is supposed to be dedicated to the public domain, and there's no way I can see to do that. Anyway, if it is workable, great. Just thought it ought to be emphasized that there is a copyright/permissions issue here. Yes. But I would prefer the original one (which in this context means the originally posted one). Yes, me too. I would imagine it should work well with your own Lilypond examples project? ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ferneyhough-style Interruptive Polyphony
On 06/11/13 18:55, David Kastrup wrote: That would be the case even if Ferneyhough were not British to start with. Your other points are fine, but what's Ferneyhough's nationality got to do with it? FWIW, he's been resident in the US for 25+ years now, and his publisher is German ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ferneyhough-style Interruptive Polyphony
On 05/11/13 07:44, Werner LEMBERG wrote: Please submit this snippet to the LSR! He can't, it's the actual beginning of Ferneyhough's score and so under copyright. The notation is cool, though, and I'm sure it's easy to come up with a similar example that is original. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Globally disable transposition
On 04/11/13 08:56, David Kastrup wrote: Ugh. Why not #(define-music-function (parser location p1 p2 m) (ly:pitch? ly:pitch? ly:music?) m) Thanks for the improved version! I'm not exactly fluent in Scheme -- combine that with needing to work out which of Lilypond's variable types to use, and it's not easy to just come up with something on the spot. Better, but I'd use ly:pitch? instead of ly:music? here. And frankly: I have my doubts the results will sound great in all cases. I can see a number of potential issues -- e.g. if you have some parts that are written (in Lilypond) in concert pitch with both \transposition and \transpose statements, and some that are written in transposed pitch with a \transposition statement, things could get nasty. But for my current use case, it's satisfactory. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Globally disable transposition
On 03/11/13 17:44, Urs Liska wrote:
But you should be able to define a music function that simply prints the music
it is passed. Use parameters for the two pitches and ignore them.
Can't try out because I'm on the phone, but you should be able to go that way.
Ahh, of course. Here's what I came up with -- seems to work:
transpose = #(define-music-function
(parser location arg1 arg2)
(ly:music? ly:music?)
#{ #}
)
transposition = #(define-music-function
(parser location arg)
(ly:music?)
#{ #}
)
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Globally disable transposition
On 04/11/13 00:05, Jim Long wrote:
I'm not sure that this suggestion meets any of your criteria
(especially \transposition), but:
\version "2.17.26"
music = \new Staff \relative e' { e b' g b, e1 }
unTmusic = \withMusicProperty #'untransposable ##t \music
\score {
<<
\transpose e f \music
\transpose e f \unTmusic
>>
}
Nice thought, but it doesn't really work for me, because it requires that the
#'untransposable property be inserted _inside_ the music. That means having to
insert that statement inside many different staff contexts, whereas I would like
a way to globally disable transposition across the entire score with a single
instruction.
What you suggest could work for a single instrument part, but not for a
multi-instrument score where it would be nice to be able to switch between
transposed and concert pitch versions.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Globally disable transposition
On 03/11/13 16:55, Urs Liska wrote:
Does it work if you redefine it with
transpose = {}
?
Nope. Remember that transposition statements are things like:
\transpose bf c' { ... }
and
\transposition bf
So, if you just define transpose and transposition as empty music, Lilypond will
interpret the bf c' and the bf as being notes.
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Globally disable transposition
Hello all, Is there a quick and easy way of disabling transposition (i.e. the effects of both \transpose and \transposition commands) for an entire Staff, StaffGroup or Score? Thanks & best wishes, -- Joe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Project Completed(-ish): 120 R.H. Studies by Giuliani
On 06/09/13 17:26, Kale Good wrote: Hello all, I haven't had a chance to do a serious proof read of this yet; I wanted to do it today but some other work came up, so I'm sending it out more than a little unfinished. All the notes and fingerings are there (or should be), but I haven't tweaked layout at all yet. This is my first big project, so feedback is very helpful. Seems to be an issue with stem lengths in various places e.g. No. 18 bar 2, the stems of the higher notes in the chords do not descend all the way to the stem of the lowest note. Similar things occur in Nos. 23, 36, 42-44, 48-50, 66, 70, and 73-80 (these are the ones I spotted, there may be others). This trick of doing the higher notes in a separate voice with long stem also seems to backfire on screen reading as sometimes it looks like the stem of the upper notes is fatter than the lower ones, or offset horizontally (even though on zooming in, this isn't the case). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Off-topics : vibrato
On 04/24/2013 04:36 PM, Owain Sutton wrote: > Another common option is simply indicating 'vib.', 'senza vib.', 'molto vib.' Depends how precise a visual indicator you want to have of the type of vibrato, particularly with respect to precise indication of the 'vertical' extent (i.e. the range of pitch variation) and the timing of changes in vibrato. If you want a general indicator, this is fine, if you want to be more precise about its speed or range, wiggly-line notation is better. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Cropped output (à la -dpreview) possible in Finale and Sibelius
On 04/09/2013 06:26 PM, Urs Liska wrote: > When I used Finale one had to draw a rectangle with the mouse that then was > exported. > Needless to say that this is a poor way to consistently line up music > fragments > in a text document. I doubt this is the way a hardcore professional engraving person would do it though -- most likely they'd output the entire page to PostScript and then do the crop in a graphics program, which would allow precision of cropping every time. I haven't used Finale or Sibelius in quite a while either, but the other possibility might be to do the export via their scripting interfaces. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
On 04/07/2013 06:51 PM, Stjepan Horvat wrote: > I realy like git too..Once i tried to make my own git server on my private > web-server so when i finish the work i can send the customer his pdf folder > link..but..that didnt work becouse you cant see actual files on git web > server..like you can on github.. In principle that's perfectly possible, you just have to set up the git repo on your web server to be a fully-fledged repo (i.e. has checked out files) rather than the bare-bones repo it tries to create by default. The trouble with that is that git (rightly) is cautious about allowing you to push to a remote repo with files checked out, so you can't just create a regular repo and push to it. There are a number of ways round this -- here's one I came across just today: http://toroid.org/ams/git-website-howto ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
On 04/07/2013 09:23 AM, David Kastrup wrote: > Have you tried with LilyPond PDFs? I think they tend to compress on the > object level which _might_ work reasonably with some of git's packing > techniques. No. I did take a look inside them before writing my previous email -- they certainly have more multi-line, plain-text content than some other PDFs I've worked with, so they'd probably compress/diff better than some files I've worked with. Most of my experience here is with PDF/EPS files coming out of gnuplot, where the PDF output tends to have a large amount of what seems to be difficult-to-diff content, whereas the EPS files are almost entirely plain-text and so diff very nicely indeed. > Packing actual executables could possibly also work with reasonable > overhead. Never tried, I'm afraid. :-( > There would be an advantage to a repository storing _complete_ compiled > versions of LilyPond: it would make "git bisect" for the purpose of > finding a regression in code or documentation a snap. It's bit more complicated to set up, but wouldn't a good solution be to have a separate repo for built files, and add a system that tracks when commits are pushed to the source repo, and then automatically builds, and commits the output to the build repo? You could use the --author, --date etc. options to git commit to ensure the details match. So, then you should have two mainline version histories that are absolutely in sync, allowing you to do the regression-tracking you're looking for but without blowing up the overall version history size for the source tree. But, bearing in mind that the on-disk size of the PDF docs is about 50MB (as reported by aptitude show lilypond-doc-pdf) and that of the HTML docs is about 90MB, then even allowing for some diffability of that material you'll be seeing a hefty cost to keeping those files versioned. I imagine that most of the disk-space cost of the HTML docs is actually PNG or other binary graphics files, which in my experience are the really nasty ones to version. On the other hand, some people apparently use git to version their home directory, so perhaps it doesn't scale quite as badly as I think ... http://entrenchant.blogspot.it/2011/03/using-git-to-synchronize-and-backup.html The other problem you can face with source and binaries versioned in the same tree is simply that sometimes people will make a tweak to a source file but not rebuild before committing. And you can imagine the converse happening -- someone making a tweak to source, rebuilding, finding it doesn't work so not committing the source, but accidentally committing the built file ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: lilypond source and music sheet database
On 04/06/2013 10:50 PM, Janek Warchoł wrote:
> The things is, use git for tracking source files, not pdfs. If you
> put \version statements in all your .ly files, you can always recreate
> a pdf with appropriate LilyPond version.
>
> Actually, it might make sense to track some pdfs as well, but i'd say
> only the versions that are somewhat final, and i'd create two
> repositories: one with sources, in which all pdfs would be ignored,
> and another one with finished ("published") versions of pdfs - ones
> that are supposed to change rarely.
Good call. The trouble with versioning binary or binary-ish files is not so
much about diffs in the sense of being able to see what has changed (e.g. bzr
with the qbzr plugin does nice side-by-side before and after comparison of
graphics files) but that because it can't be diff'd, each new version almost
always adds an amount of data the size of the entire file to the version
history.
So, if you keep updating the version of a particular binary file, you wind up
with a repo whose size is out of all proportion to the size of the checked-out
tree :-(
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/04/2013 02:50 PM, Alexander Kobel wrote: > Then, everybody is free to use "my-app.C" constraint to my terms, since they > are > imposed on this very file. However, nobody would be allowed to use /GSL/ to > compile this program, because GPL considers "my-app.C" a covered work > /whenever > used with a GPL'ed implementation/ of the GSL api. So in essence, the source > is > useless for purposes other than code study to anyone but me, since I am the > only > one free to re-license my own creation under a different license (even without > explicitly stating it). People will compile the program with GSL, of course, > but technically they are not allowed to do so You're allowed to use GPL-licensed works in any way you see fit on your own computer, including compiling against works with incompatible licenses (e.g. compiling a Linux kernel with proprietary drivers included). You find yourself in violation of a license only when you start conveying covered works to others. So, recipients of my-app.c could compile it against GSL on their own system, but not share the resulting binary with others. > Still, I agree that a more trustworthy source for the interpretation is > required. And I hope it turns out that the above situation is actually not > true... I've broken my own resolution and replied on-list because I thought it was important to correct your misunderstanding publicly, but if you'd like to discuss this further, feel free to take it off-list. Though I understand if you don't consider my point of view to be trustworthy enough. :-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/03/2013 01:08 PM, Wols Lists wrote: > Dare I suggest you look at section zero? The second paragraph of which > says, and I quote: You're talking about GPL version 2, not GPL version 3. Compare: https://www.gnu.org/licenses/gpl-2.0.html ... where the second paragraph of Section 0 is exactly as you describe, with: https://www.gnu.org/licenses/gpl.html ... which is the current and (to this case) relevant version of the GPL. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/03/2013 01:14 AM, Anthonys Lists wrote: > If your work does not include any of their work, then you don't need any > permission to not copy their work! :-) But I'm not talking about copying. I'm talking about the right to use. > And if you read the GPL, version 2 (I presume 3 has similar wording) says "the > use of this work is outside the scope of this licence". The GPL explicitly > rejects anything to do with the USE of the work. You presume wrongly. Section 2 of GPLv3 opens with: "All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable _provided the stated conditions are met._" [my emphasis]. Section 8 (Termination) opens with: "You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11)." And Section 9 (Acceptance not required for having copies) reads (again, with my emphasis): "You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. _However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License._ Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so." > And what law will they use to use you? Oh - that's right, they'll use > copyright > law! Yes, because under the terms cited above, I will have lost my license to use the work itself. > At which point, they will have to show, to the Judge, that your work is > LEGALLY > a derivative of theirs. No, they have to show that it is a covered work as defined by the GPL, and that by conveying it to others I have violated the terms of the license which grant me the right to use it. That in itself simply means that I am not legally allowed to use the program any more -- and if I accept this and don't use it, they don't have a case. But if I _do_ continue to use it, then they _do_ have a case. Note that I could also avoid the license violation by making a clean-room re-implementation of the GPL-licensed work which can be used with my program. > What I do know is that the GPL grants permissions that - absent the licence - > you wouldn't have. > > And if the law says you don't need those permissions, then you don't need that > licence! I know of no law that says you do not need the permission of the copyright holder to use a computer program. Even in the case of GPLv2, the your right to use the program rests on their explicit statement granting you that right. > Let's say I write a licence that Joseph Wakeling owes me £500 per month for > not > using my code. I give you a copy. I now claim you owe me £500 for the month of > April. How am I going to enforce it? It seems fairly obvious you think I'm stupid, but do you really think I'm daft enough to accept software that comes with a license like that? :-) > (Oh, by the way, my understanding of the GPL has changed a fair bit over the > years. Mostly as a result of discussing the niceties on Groklaw, so I think > most > of my misunderstandings have been pretty much clue-by-four'd by now :-) But > this > isn't a case of understanding the GPL, it's a matter of understanding the law. > The law says "you don't need a licence" so that's the end of it!) Forgive me, but I'm not very inclined to respect your "understanding of the GPL" if it extends to "presuming" that v3 has similar wording to v2, without actually bothering to read it. :-) And v3 is the relevant version here. Anyway, as David said elsewhere, I don't think anything I can say will change your mind, so I think I'll bow out here (... he said to a sigh of relief from probably everyone on the list ...). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/03/2013 01:22 AM, David Kastrup wrote: > Yes, it is. The terms of use of a proprietary program generally presume > a binding contract _restricting_ the scope of rights normally granted > with the legitimate purchase of media. > > The difference is that the proprietary vendor needs to establish that > such a contract has been entered, and he has the burden of proof that > his contract conditions have been violated. > > With a license (such asthe GPL), the burden of proof that he had license > to do as he did lies with the user of software. > > That's quite a different playing ground. Sure, but whichever playground you're in, there can be conditions whose violation removes your right to play. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/03/2013 01:45 AM, Tim McNamara wrote: > Is that in fact correct? The quibbles here is what constitutes derivation. > If you write a program that calls a library during its function, is that > program derived from the library? Or is the library just a resource that the > application uses? I think in fact and by tradition the latter situation is > what applies. I don't think that "derivation" in the traditional copyright sense is the correct term to consider here. A program that calls a GPL-licensed library during its function is a defined as "covered work" in the terms of GPLv3, and your right to use a GPL-licensed work is conditional on your compliance with its terms on the distribution of "covered works". > Make no mistake about it, the law has priority over the GPL in any court case. Oh, I'm not disputing that. It's just that this general and correct assertion doesn't tell you anything about whether the GPL is actually in contradiction with the law. > Especially if the court determines, as would quite possibly be the case, that > the GPL has overreached (which in some ways it has). Absent a court ruling, it seems difficult to me to assert that. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 11:38 PM, Anthonys Lists wrote: > On 02/04/2013 22:01, Joseph Rushton Wakeling wrote: >> (Function names and APIs are generally considered to be uncopyrightable.) >> However, I think the consensus of opinion about free software licensing would >> be that, in distributing to you this little program, purely in source code >> form, not compiled or linked in any way, I am still obliged to offer it to >> you >> under licensing terms that are GPL-compatible, or else lose my right to use >> the GNU Scientific Library. > > You've just answered your own question. You have just said that this program > does NOT contain ANY copyrighted content from the gsl. > > As such, it is not a derivative work. That's what the law says. If the gsl > people want to stop you using their library, they need the law on their side. My right to use the GNU Scientific Library is conditional on following certain obligations -- if I breach those obligations, I lose the right to use the GNU Scientific Library. One such obligation relates to the licensing that must be applied if I distribute any work that matches the GPL definition of a "covered work". It's no different in principle from what happens if I breach the terms of use of a proprietary program. My right to use the Flash plugin, for example, is conditional among other things upon my not trying to reverse-engineer it. Of course, in the case of the GNU Scientific Library, one way I could avoid violating the license would be to prepare a clean-room re-implementation of the library for use with my program. But in the absence of such a re-implementation, I think I'd reasonably be held in violation. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 11:57 PM, Anthonys Lists wrote: > On 02/04/2013 22:47, Joseph Rushton Wakeling wrote: >> Indeed, and a consequence of distributing a "covered work" under >> GPL-incompatible terms is that you lose the permissions granted under that >> license. > > EXCEPT EXCEPT EXCEPT THE LAW SAYS YOU *DON'T* *NEED* ANY PERMISSION !!! What, I don't need permission to use a computer program written by someone else that is still in copyright? I get to use the GNU Scientific Library _only_ because its authors have granted me permission to do so. That permission is conditional on my adhering to a number of conditions. One of those conditions is that if I distribute what the GPL refers to as a "covered work" -- in this case, a work based on the GNU Scientific Library, such as my little program -- I must do so under a GPL-compatible license. If I break that condition, I lose the permission granted to use the GNU Scientific Library. That doesn't mean its authors can sue me for distributing my little piece of code under a proprietary license. It means they can sue me if I continue to use the GNU Scientific Library. > Sorry for shouting, but just go ask a lawyer. ANY lawyer with a half-way > decent > grasp of copyright. I suggest it's not me who doesn't understand copyright, but you who doesn't understand the niceties of the GPL. I'll happily accept proof that I'm wrong, but shouting at me (or making general assertions about the relative priority of the GPL versus the law) doesn't count as proof :-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/03/2013 12:01 AM, Anthonys Lists wrote: > But as I understand it, the lawsuit as actually sued said "apis are copyright" > and you would have needed a licence to use the apis - to use Oracle's Java. That's exactly in line with what David said. Google were providing a clean-room re-implementation -- the only thing it had in common with Oracle's Java was the API. Oracle couldn't sue on the basis of code duplication, so they tried to stop Google distributing their implementation by claiming copyright violation on the basis of duplication of the API. And (rightly) lost. That's a different situation from the one we have been discussing here, which is code that _uses_ (not implements) functions whose only existing implementation is in a GPL-licensed program. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 11:25 PM, David Kastrup wrote: > Uh, so far I have just seen fantasizing about TeX users having similar > concerns. I did post a link before: http://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages Sure, it's not a huge wellspring of concern, but as you say, that's ... > Hardly surprising since in the TeX world the GPL is not used frequently. I imagine that if it were more widely used there would probably have been some kind of formal pronouncement on this issue years ago. > Are you sure you are not getting carried away with a self-made view of > the situation? There is that risk. :-) Look, let me try and calm things down: I am not seeing this as some massive horror that is going to haunt Lilypond, if for no other reason than that I can't see a single Lilypond developer trying to claim GPL violation against a user distributing source for their scores. By "warning sign" I meant simply a sign that the concern is not unique to me, or to Lilypond. I simply think this is a question to which it would be useful to have a concrete answer. However, I'll readily plead guilty to getting carried away in debating licensing issues in general. No just on this ocasion, either ... :-) > Feel free to ask the SFLC, but I don't see the point in trying to spin > this out of proportion before even doing so. Any email I write will be calm and carefully laid out. What I really, really want is for my concerns to be proven unfounded -- the second best as far as I can see is to get clear and useful advice. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 11:28 PM, Anthonys Lists wrote: > A derivative work is whatever the LAW says it is (whatever that is :-). NO > open > source licence defines the term "derivative work", although they may give > their > own interpretation of what they think it is. The actual GPL term is a "covered work", and is specified reasonably precisely. My little program calls functions from an explicitly GPL-licensed library -- not from an API with multiple different implementations -- ergo, it's based on a GPL-licensed work and is a "covered work" in the terms of the GPL. > The whole point of open source licences is they are LICENCES. They GRANT > PERMISSIONS. Indeed, and a consequence of distributing a "covered work" under GPL-incompatible terms is that you lose the permissions granted under that license. So, if I'd tried to put a proprietary license on that bit of C code I shared, for example, I'd have been violating the terms of the permissions granted me on the GNU Scientific Library; so I'd have lost my right to use the GNU Scientific Library; and if I continued to use it, I could be sued for using copyrighted software without permission. _That's_ where issues of copyright violation come in, not in the question of whether my piece of code is strictly derivative in the sense of copyright law. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 11:17 PM, Anthonys Lists wrote: > So as long as Google stuck to using interfaces that the kernel devs explicitly > published to user space, then using those header files EXPLICITLY does NOT > create a derivative work, and therefore the GPL can NOT cross that boundary. That's exactly the point. What Google did was to take the kernel's header files documenting those public interfaces (which contain GPLv2 licenses) and strip out EVERYTHING BUT the documentation of the interfaces (and, I think, various macros, type definitions, etc.), and provide those new headers under the Apache license. This was considered to be legit, rather than a GPL violation, precisely because those aspects of the headers are considered to be "facts" rather than copyrightable elements. See e.g.: http://www.theregister.co.uk/2011/03/29/google_android_and_the_linux_headers/ http://www.itworld.com/open-source/140916/android-sued-microsoft-not-linux ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 10:33 PM, David Kastrup wrote: > Since I can't share your concerns, I can't give you any advice what to > ask the SFLC in order to address them. That's quite up to you. Fair enough. I was concerned that you might actively disapprove of my doing so, in which case I'd have wanted to try and find an alternative way of addressing my concerns that was also satisfactory to you. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 09:50 PM, Tim McNamara wrote:
> On Apr 2, 2013, at 12:47 PM, Joseph Rushton Wakeling wrote:
>> But now suppose that bobjones.ly defines a number of new functions, \bobFoo,
>> \bobBar, etc., and that you use them on a number of occasions throughout your
>> own .ly file. Is the issue so clear any more?
>
> I think again that these are references only and that this causes no problem
> with copyright and the GPL; what will happen for anyone else who tries to
> compile my .ly file is that it will fail.
>
>> If that's not good enough, suppose that you don't just use Bob Jones'
>> functions
>> in your .ly file, but you actually construct new functions of your own that
>> use
>> Bob's functions. Can you still say there's no issue?
>
> Interesting question. Insofar as I am not actually copying any of the "Bob
> Jones.ly" code into my .ly file, I still think "no." It is still only a
> reference to copyrighted content, not the copyrighted content itself; if my
> music functions actually contain code from "Bob Jones.ly" then yes, there is
> a problem.
>
> I can write a novel that tells the reader to go and read paragraph 3 on page
> 241 of "Of Mice and Men" without violating Steinbeck's copyright. I can even
> write the sentence before and after the reference in such a way that they
> make no sense of the reader doesn't read the paragraph in question, and still
> not violate Steinbeck's copyright. That's basically what \include does. If
> someone takes my .ly file and tries to compile it in the absence of having
> "Bob Jones.ly," the compilation will just fail. On the other hand, if I copy
> Steinbeck's paragraph into my novel without permission, I have violated the
> copyright.
OK, now let's consider a specific example. Here's a bit of C code that
generates 100 random numbers and calculates their sum.
//
#include
#include
double random_number_sum(const gsl_rng *r, size_t n)
{
size_t i;
double x = 0.0;
for(i=0; i<10; ++i)
x += gsl_ran_flat(r, 0.0, 1.0);
return x;
}
int main(void)
{
size_t n = 100;
gsl_rng *r = gsl_rng_alloc(gsl_rng_default);
double x = random_number_sum(r, n);
printf("The sum of %lu random numbers in [0, 1) is %g\n", n, x);
gsl_rng_free(r);
return 0;
}
//
Let's go through it line by line. The first line tells the compiler, when
compiling, to make use of the standard library header describing input and
output. That doesn't matter -- it's a system library and therefore irrelevant
as far as licensing is concerned. The second line tells the compiler to make
use of the header file describing the functions from the GNU Scientific Library
(GSL) that implement random number distributions.
Then you have a function which takes as part of its input a pointer to the
gsl-defined random number generator type, and which calls internally the GSL
function to generate a pseudo-random number from a uniform distribution.
Inside the main() function, there are calls to the GSL functions to allocate and
free memory in which to store a random number generator.
Now, just as in your case, I've not copied either stdio.h or gsl_randist.h.
I've not given them to you, either. It's just an instruction to your compiler
to look for these files when trying to build the program, and if you try and
compile this program without those files present on your system, the compilation
will fail.
Nor does this program contain any copyrighted content from those files.
(Function names and APIs are generally considered to be uncopyrightable.)
However, I think the consensus of opinion about free software licensing would be
that, in distributing to you this little program, purely in source code form,
not compiled or linked in any way, I am still obliged to offer it to you under
licensing terms that are GPL-compatible, or else lose my right to use the GNU
Scientific Library.
The point is not that my program is derivative in the sense of copying content
from gsl_randist.h, but that it is a "covered work" in the language of the GPL
-- that is, a work based on the GPL-licensed program -- and I am only licensed
to distribute covered works under terms that are compatible with the GPL.
Now, I cannot personally see the distinction between what I have done with my
daft little bit of C source code, and what I have described to you in terms of
functions defined in a .ly file.
(Since I do in fact want to keep using the GNU Scientific Library, I should
probably say
Re: Lilypond \include statements and the GPL
On 04/02/2013 08:53 PM, David Kastrup wrote: > LilyPond is a GNU program and so follows the licensing policies of the > GNU project. Sure, but I don't see that this prevents you from making a permissive licensing choice for parts of your program where this is appropriate -- I imagine the GNU project would appreciate the importance of code copyleft not accidentally overreaching to users' compositions. If you're restricted to GNU licenses, the GNU All-Permissive license might be an appropriate choice. Anyway, I would really appreciate your input on whether (and what) to write to the Software Freedom Law Center. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 07:33 PM, Tim McNamara wrote: > If I do not copy the actual file into my .ly file but only have the \include > statement, I have not violated copyright. It would be up to any subsequent > user to obtain the copyrighted Bob Jones file to use with \include or to come > up with a workaround. > > Merely stating > > \include "Bob Jones.ly" > > in my own .ly file does not violate copyright because it does not reproduce > or distribute the "Bob Jones.ly" file itself. IMHO copyright is only a > problem if I copy the "Bob Jones.ly" file into my .ly file, in which case I > would probably also not be using \include. But now suppose that bobjones.ly defines a number of new functions, \bobFoo, \bobBar, etc., and that you use them on a number of occasions throughout your own .ly file. Is the issue so clear any more? If that's not good enough, suppose that you don't just use Bob Jones' functions in your .ly file, but you actually construct new functions of your own that use Bob's functions. Can you still say there's no issue? When you add to that the fact that the particular case we're concerned with involves copyleft licensing which gives a particular and precise definition to what is considered a "derivative work", it really doesn't seem to me possible to just write this off. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 07:07 PM, Urs Liska wrote: > My suggestion would be to either have a sort of "lilypond license" or > (better) an explicit exception/clarification stating that the use of > functions defined in the LilyPond distribution (either implicit or through an > explicit include) do not require the user's LilyPond source files to be > distributed under the GPL. Maybe with an explanation that this is because > user's .ly files don't constitute source code from which an application can > be compiled. New licenses are a bad idea, in general -- they tend to create confusion as well as adding extra maintenance weight to the project. An exception is not much better inasmuch as it's a custom solution for one project. It's far better to find a licensing solution that is generic to the problem under consideration. For the cases we're considering -- OLLib and the .ly files bundled with Lilypond -- the _simplest_ method that I can see is to license them permissively. Boost, Apache, BSD/MIT/X11 and the GNU All-Permissive Licence are all options here (potentially LGPL as well, but then issues may re-arise the moment someone copy-pastes a function rather than getting it via \include). But that's bypassing the problem, rather than understanding it. Yes, most of us dedicated to free software prefer copylefting as much as we can, but there are times when the simplicity and flexibility of permissive licenses outweighs any possible protection, especially (as here) where the likelihood of anyone incorporating the work into a proprietary product is minuscule. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 05:07 PM, Alexander Kobel wrote: > This certainly applies to compiled code, with the GPL'ed library statically > linked, and also (I stand corrected) with dynamic linkage, AFAIU. I still > cannot see how it /could/ possibly apply to source code: Well, the examples you cite consider a particular case -- which is a program using an API which has multiple different implementations, some under copyleft licenses, some not. In that case, I don't dispute your case that the source code could be distributed standalone without any obligation in respect of its licence. (Of course, anyone wanting to distribute it linked against a particular copyleft library would have to obtain their copy under a compatible license.) But many (most?) cases of using a library involve using a _specific_ library, of which there is only one implementation, and there that library's licensing does come into play. For example, if I write a program that calls functions in the GNU Scientific Library, which is GPL'd, it doesn't matter if I distribute only source code; it's still a derivative work of the GNU Scientific Library under the terms of the GPL, and must therefore be released under a GPL-compatible license. Note, "GPL-compatible license", not necessarily the GPL itself. This actually adds a lot of flexibility in licensing choices. > In that sense, I have the feeling that the source code license cannot > interfere > with the library license, unless parts of the library are copied in the source > code. The source might be useless without the library, but still. E.g., is > it > really the case that the boost project would never be allowed to include > wrappers to GPL'ed libraries? The Boost license is GPL-compatible, so there's no issue for them. Your point is accurate though inasmuch as, if the wrappers weren't used when my program was built, there would be no copyleft obligation on it. > I see your point, but I don't see how what you explained to be the GPL notion > could actually be enforced... I'm not sure I understand you, but anyway, this is getting to the point where it should probably be taken off list if we want to take the discussion further. Let's focus on the case which is of concern -- Lilypond input files. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 04/02/2013 03:52 PM, David Kastrup wrote: > The main difference is "work as a whole" vs "mere aggregation". If you > include some file as a form of invoking its documented interface, you > form no new combined work. Indeed, which if I recall right is how Google was able to provide non-GPL'd header files describing the Linux kernel API for use in Android. (If I'm wrong, let's not get into the reasons why -- it's another huge can of worms...:-) > If, however, you include a file, then patch > and access its internals, you are creating a new derived version of its > contents, and that would be covered by the GPL. Quite. > With regard to linking executables, the FSF is of the position that > linking generally constitutes creating a derived work (whether linking > statically or dynamically), potentially via contributory infringement, > thus forming a fundamental difference between LGPL and GPL. I find that > somewhat audacious, but short of actually decisive court precedents, > most people (and corporations) prefer not putting this theory to the > test. Surely the fundamental aspect of it here is not whether traditional copyright would consider a new work derivative of the GPL'd library it links to, but that the terms of use of a GPL'd library state that you lose your rights to use and distribute that library if you distribute work that links to it under GPL-incompatible terms. Anyway, back to the key issue -- would you like me to draft an email to the Software Freedom Law Center? The fact that this issue is of concern also to people in the TeX community makes me feel that it's something they should probably be alerted to. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 03/30/2013 01:02 AM, Alexander Kobel wrote: > On the other hand, user C /should/ be allowed to distribute source code under > whatever license he wants to /as long as he doesn't ship the GPL libraries > with > it./ It's useless without them, but anybody who wants to run or compile the > code is free to download the necessary GPL'ed stuff. If I write a computer program which uses functions from a GPL'd library, it doesn't matter whether I distribute an executable or just source code, and it doesn't matter whether I distribute the source code alongside the GPL'd libraries or as an individual file. It's a derivative work under the GPL and must be licensed accordingly when distributed. See: https://www.gnu.org/licenses/gpl-faq.html#IfInterpreterIsGPL Perhaps you are thinking of e.g. the case with UNIX shell scripts, where e.g. I can write a script that calls GNU sed without having to license my script under the GPL. But this is because there's no dynamic linking that takes place when I do so -- I'm starting an independent process and receiving its output. See e.g.: https://www.gnu.org/licenses/gpl-faq.html#GPLAndPlugins ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 03/29/2013 11:26 AM, Janek Warchoł wrote: > On Thu, Mar 28, 2013 at 7:26 PM, Joseph Rushton Wakeling > wrote: >> but aside from that I think there are >> probably several other ways in which it could be done, including ensuring >> that >> all files intended to be \include'd are licensed under something more >> permissive >> (LGPL, BSD, Boost, Apache, ...), or adding a simple exception or >> clarification >> to Lilypond's license akin to the GPL font exception. > > +1 ... though such licensing would only solve the immediate problem. It'd be nice to have a clear understanding of the actual relationship between GPL and Lilypond (and indeed, GPL and TeX). > An example came to my mind: imagine someone typesetting a score and > using one (just one) function from OLLib. Distributing whole OLLib > together with the score just to have this one functionality would be > inconvenient, so he'd like to actually paste this function from OLLib > into his file. Can he do this? I think that such usage should be > permitted (and not resulting in the final score being copylefted), as > long as the function is clearly marked and attributed. Point of clarification: this isn't about the "final score" in the sense of the PDF output. This is about what are his obligations if he chooses to distribute the .ly source file of his score. > BTW, what about snippets from documentation and LSR? "This document shows a selected set of LilyPond snippets from the LilyPond Snippet Repository (LSR). It is in the public domain." http://lilypond.org/doc/v2.17/Documentation/snippets/index.html I remember this well because I remember being asked to dedicate my snippets to the public domain when submitting them to LSR. That said, it might be worth clarifying whether people submitting snippets direct to the Lilypond docs are formally asked to dedicate them to the public domain. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 03/29/2013 10:39 PM, Urs Liska wrote: > First of all, I think we have quite a consensus on what we intend - which is > a good start. Yup. :-) > I slightly disagree, although your considerations are valuable and give some > good insights in the situation. > I think the 'ambiguity' Joe is talking about is the ambiguity of LilyPond's > input files being 'user documents' and at the same time compilable source > code. Interestingly, it seems that TeX people are developing similar licensing concerns -- see e.g.: http://tex.stackexchange.com/questions/69007/the-gpl-and-latex-packages > I would say that the whole LilyPond input file should be considered as a > 'user document', and that the author should be completely free to decide upon > its licensing, whether or not he uses included functions from LilyPond's > distribution. > But as this discussion shows it's not really clear how GPL's licensing model > applies for that somewhat ambiguous situation. So it might actually be > necessary to clarify that. The problem is that while I think we can all agree on _intent_, the strict letter of the license may mandate something different. This is not easy to understand and seems to me to be very much a niche case -- your remark that .ly input files can be simultaneously both user documents and source code seems to me to capture the essence of the problem, which is shared with TeX. I feel that possibly the best solution here is probably to approach the Software Freedom Law Center and ask their advice. If people are interested in taking that approach I will draft an email (which could be sent by me or by someone closer to the core of the project, depending on preference). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 03/28/2013 08:28 PM, Tim McNamara wrote: > My understanding is always been that the GPL applies to the software used to > produce a file, not to the file itself. I think (at least in this case) you mean "process", not "produce". You can draw an analogy to e.g. shell scripts, where the fact that the bash shell is GPL-licensed doesn't mean that shell scripts must also be GPL'd. However, I'm not 100% convinced here because I think the situation of putting in an \include to a GPL'd .ly file, and calling functions defined in that file, might well make your own .ly file specifically a derivative work. > Therefore, the GPL would not apply to the users' .ly files; the user has the > option of specifying under what license any such files might be published. That rests on the assumption that there is a separation between GPL'd interpreter and the source file that's being interpreted. PHP is a nice example -- the license of my PHP files can be independent of the license of PHP itself (which as it happens is a dual-license between GPL and a custom license). But when I start making calls in PHP to a written-in-PHP library that is GPL'd, I think things become rather different. I think the \import "somefile.ly" situation could be more analogous to this second situation _where the .ly file defines functions that are used in your own .ly file_. Hence it's an area of licensing concern. And as I've stressed before, this licensing issue would kick in only if you distributed your .ly file -- not if you distributed the graphical score produced by processing it. I will be away over the Easter weekend so not able to answer emails, but I'd like to continue this discussion afterwards. Thanks & best wishes, -- Joe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Lilypond \include statements and the GPL
On 03/28/2013 06:35 PM, David Kastrup wrote: > I don't see that. \include is an instruction, not an actual inclusion. > As opposed to dynamic linking, there is no combined entity being formed > for the sake of execution where one could possibly claim "contributory > infringement". The inner workings of english.ly and its interoperation > with LilyPond proper are not being accessed or questioned, either. I take the point about instruction vs. real inclusion, i.e. that what the \include command is saying is "read this set of instructions when processing this file through Lilypond" rather than "include this material in the final product". But I feel it's still an unnecessary ambiguity. english.ly isn't the best example of this, but suppose instead you have a .ly or .ily file that defines a new command, and you use that new command throughout your own .ly file? The point here is that there is certainly not a combined entity coming out of the running of your .ly file through the lilypond interpreter, but there _may_ be a combined entry in the form of your .ly source file containing calls to functions defined in GPL-licensed files. >> I can't imagine it's intentional that Lilypond copyleft should extend >> so far as the .ly files of scores created by users, but as things >> stand I'm concerned that this may be the strict letter of the >> licensing. > > I don't see that, short of _actual_ inclusion of english.ly etc. Personally I feel it would be nice to resolve any potential ambiguity. Obviously the best way to do this is just to show that I'm definitively wrong in my interpretation (this would be nice:-), but aside from that I think there are probably several other ways in which it could be done, including ensuring that all files intended to be \include'd are licensed under something more permissive (LGPL, BSD, Boost, Apache, ...), or adding a simple exception or clarification to Lilypond's license akin to the GPL font exception. I should add that the underlying motivation here is licensing clarity for some of Urs and Janek's work on useful toolboxes for Lilypond. It's clearly desirable that these kits be copylefted as far as any code derivative is concerned, but it's obviously not intended that the copyleft extend to users' .ly files. I was convinced that this issue must already have been systematically discussed with respect to Lilypond's own files, hence my questions ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Lilypond \include statements and the GPL
Hello all, A question which has come up, and where I'm not sure what the answer or intention is. Lilypond is licensed under the GPL and reading through the license file, I didn't come across any granted exceptions (IIRC the fonts have an exception for embedding them into a document). So, how does this affect things when e.g. you \include a file in your personal Lilypond project? While I can't see it affecting distribution of a PDF or other graphical version of the score produced, the lack of an exception surely means that any .ly file distributed would be obliged to be released under the GPL or a compatible license. (For example, english.ly is explicitly licensed under GPLv3+ without any exception. Yes, I know that these days you should use \language "english", but that's beside the point.) I was sure this must have been discussed previously, but cannot find anything in past mailing list discussions. So can anyone advise on whether this was indeed discussed before -- and if so, what were the conclusions? I can't imagine it's intentional that Lilypond copyleft should extend so far as the .ly files of scores created by users, but as things stand I'm concerned that this may be the strict letter of the licensing. I'd welcome being pointed to obvious reasons why I'm wrong. Thanks & best wishes, -- Joe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Suggestions for participating institutions?
On 03/26/2013 09:52 AM, David Kastrup wrote: > I met a former colleague in the bus to Chemnitz, and he is at least > knowledgeable about EU research programmes. Do people here have ideas > about possible institutions who could be made to participate? Imperial College, London has a fairly close relationship with the right-next-door Royal College of Music, including cross-disciplinary research collaboration. In this case it might be worth seeing if something could be set up between RCM and the IC computer science department. I don't have any contacts for this, unfortunately, but I can ask around UK friends/colleagues for thoughts and advice. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ferneyhough-style flared hairpins?
On 03/04/2013 05:29 PM, Trevor Bača wrote: I'm considering sponsoring the work and I'm curious to know if there would be any other adopters if the feature were implemented. ... could we make this a 2-in-1 to also cover his brackets-to-show-extent-of-dynamic notation? This actually couples with his hairpins (I'm sure you can find an obvious example in Adagissimo). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Ferneyhough-style flared hairpins?
On 03/04/2013 05:29 PM, Trevor Bača wrote: Is anyone else out there using Ferneyhough-style flared hairpins? I'd probably use them if they were available. I'm considering sponsoring the work and I'm curious to know if there would be any other adopters if the feature were implemented. Actually my mental model for Lilypond's effectiveness largely consists of a case-by-case assessment of how easy it is to achieve a given Ferneyhough notational choice :-P So I'd be very happy to see this feature added, especially as I think it'd be unique among notation solutions. (Ferneyhough's more recent scores, prepared using Finale, don't use this notation.) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 03/02/2013 07:45 PM, Urs Liska wrote: AFAIK (but I'm not a lawyer either) you can't renew the copyright of the music but only on editions. That's why one sometimes has to pay royalties for really old music. This is UnitedStatesian copyright law, which has historically had some amusing deviations from European norms ... :-) At least as it was laid out in the early 20th century, copyright was for a fixed 28-year term and could be renewed for another 28 years. One of the major historical differences between US and most European copyright regimes was that in the US, copyright had to be registered. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 03/02/2013 08:02 PM, Urs Liska wrote: But let me make a further suggestion: As I already mentioned in an earlier thread I'm going to write a paper on plain-text, git-driven work-flows, and I would be pleased if I could use this project as example material for that. The motivation for the paper is a presentation at my university, but of course I'll release it publicly as part of our openLilyLib tutorials series. So it would make sense to host our Berg engraving also within this project. I can give you write access to https://github.com/openlilylib/openLilyLib (you may look at that but it's not really in a release state ...), and you could put the material in a subfolder of OLLexamples. One remark that is independent of the above suggestion: You should really take care of creating a nice Git history right from the start, because that's something we might want to present someday. Well, of course -- already working on that basis. :-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
"dodecaphonic-first" accidental style
Hello all, Taking a look at Berg Op. 5 (see Sibelius-related discussion) I realized that it uses a slight variant of the "dodecaphonic" accidental style: every note has an accidental, but only for its _first_ appearance in the bar. Any advice on how to achieve this automatically? Thanks & best wishes, -- Joe ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 03/02/2013 06:43 PM, Jethro Van Thuyne wrote: "Renewed copyright 1952 by Helene Berg". How long did/does such a renewal run? Well, this is the discussion on the subject on IMSLP's forums: http://imslpforums.org/viewtopic.php?f=13&t=3503 I believe that typical terms of copyright renewal were for 28 years: http://www.publicdomainsherpa.com/copyright-renewal.html ... with 1952 corresponding to the appropriate date for the 1924 publication of the UE edition. But there might be some complications down to the fact that the original 1920 publication was outside the US. My personal understanding (but I am not a lawyer and this is not legal advice:-) is that it boils down to this: -- The work was first published outside the US in 1920 -- The work clearly enjoyed 2 full terms of copyright protection in the US (testified to by the copyright renewal); -- So, the work _should_ fall under the no-copyright-for-pre-1920-works rule, and wouldn't be eligible for copyright restoration because it did enjoy a full term of copyright protection in the US. The fact that IMSLP haven't received a takedown notice obviously should not be read too deeply into, but it's unlikely this would have been tolerated if Universal Edition had a case to make. There is also now a Henle Urtext edition, which there most likely would not be if the 4 Pieces were still in copyright. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 03/02/2013 06:30 PM, Urs Liska wrote: I also thought of Berg already. Maybe also his songs? (could prove useful for me when having to play transpositions ...) But the Clarinet Pieces are beautiful too. Good point. Well, tell you what. If I put together a rough version of the 4 Pieces and get it up on GitHub, why don't we take it from there? By "rough version" I mean all notes, articulations etc. entered, but with no tweaks or custom scripting, just to see what Lilypond comes up with on its own. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 03/02/2013 06:27 PM, Joseph Rushton Wakeling wrote: Alban Berg 4 Pieces for Clarinet and Piano. Out of copyright in the US (pre-1922 publication) and Europe (more than 70 years since composer's death). On IMSLP here: http://imslp.org/wiki/Special:ImagefromIndex/12907 To me this is a really lovely example of engraving -- a really complex piece of music with complicated notation, beautifully rendered. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 03/02/2013 06:22 PM, Urs Liska wrote: OTH we might take this as an opportunity to do something else as a showcase project. I wouldn't suggest Goldberg Variations but rather something complex from the end of the 19th century (i.e. just out of copyright). Maybe something for string quartet too or another ensemble instrumentation (to be able to break it down in a number of more manageable tasks)? Alban Berg 4 Pieces for Clarinet and Piano. Out of copyright in the US (pre-1922 publication) and Europe (more than 70 years since composer's death). ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: How can I do this ...
On 03/01/2013 06:17 PM, Guy Stalnaker wrote: Is it possible to modify the brace from a GrandStaff or the positioning of the brace for the PianoStaff version so that it is more like the B&H engraving? I know the example from the LP documentation is acceptable (the Peter's Edition of the Bach is engraved in this manner) but I, personally, like how B&H do it -- I like that lovely brace. Just place the \new Staff = "PedalOrgan" statement inside the << >> brackets of the PianoStaff, rather than outside. A PianoStaff is a grouping of staves -- you can put as many staves inside it as you like. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 02/28/2013 06:20 PM, Adam Spiers wrote: I strongly disagree, unless your definition of "difficult" ignores the time dimension of such a project. http://www.joelonsoftware.com/articles/fog69.html It can go horribly wrong, yes, but it doesn't have to. Git for example was a from-scratch attempt at DVCS -- if Linus Torvalds had started from e.g. Arch or Darcs, it's unlikely that we'd have had the innovative DVCS that we see today. Know-how and experience do not enable large, functional code-bases to be magically constructed in short time spans. They help increase velocity and quality, but any new code-base takes a long time to grow. Yes, but it takes even longer if you begin from the wrong starting point. Neither Lilypond nor MuseScore really does what this team seem to be aiming for -- there would be such a level of redesigning that you might as well start from scratch. but because they are writing a completely new codebase, they do not have to be constrained by historical mistakes or backwards compatibility. Nor would they be constrained by these if they started with LilyPond. Lilypond's existing architecture is a constraint, its existing syntax is another constraint. And much as I admire Lilypond, I doubt its design is entirely free of mistakes ... ;-) Finally we can agree on something ;-) But Daniel Spreadbury already admitted that they haven't even looked at the LilyPond and MuseScore code, therefore they have dismissed the possibility even before doing a technical feasibility study. Well, of course not. They won't want to risk the possibility of GPL'd code influencing what they write. The simplest legal defence against accusations of copying is, "I've never looked at that code." But the bottom line is, their licensing choices and their reasons for building a project from scratch are fairly orthogonal. The opportunity to use someone else's code is advantageous if someone else's code provides functionality you need or that fits well into your architectural concept. Personally, I doubt that Lilypond's design choices fit well with a piece of software that's designed to provide real-time WYSIWYG engraving, and MuseScore's data structures are likely to be far too limited compared to what the former Sibelius team are setting out to do. It's a shame that the opportunity to do so was taken away from them by a firm corporate decision to build a proprietary project, but I suspect that even with firm backing for a free software package, they'd have chosen to start from the ground up. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: #'stencil vs. #'transparent
On 02/28/2013 02:11 PM, Daniel Rosen wrote:
I'm typesetting a piece of vocal music, and I want to have a melisma without a
slur being drawn. I tried \override Slur #'stencil = ##f, but when I compiled
it, the output appeared as if I had written \override Slur #'transparent =
##t--in other words, it occupies space, contrary to the description of the
stencil property at
http://www.lilypond.org/doc/v2.16/Documentation/notation/visibility-of-objects.
Is this a bug?
Something similar happens if you set the stencil of a dynamic mark to ##f --
try:
{
c'4\< \once \override DynamicText #'stencil = ##f d'\f\> c'\! r |
c'4\< d'\> c'\! r |
}
___
lilypond-user mailing list
lilypond-user@gnu.org
https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 02/28/2013 02:30 AM, Adam Spiers wrote: I don't follow your logic here at all. Being large and complex doesn't rule it out from being a starting point. If it *wasn't* large, there wouldn't be as much to gain from starting with it vs. starting from scratch. You make two rather big assumptions -- first, that writing a big application from scratch is difficult (for a highly-skilled team, it's not necessarily). Second, that starting from scratch is necessarily a bad thing. In fact, starting afresh can be very desirable. It's not actually "from scratch" because this team has huge amounts of knowhow from their years of experience, but because they are writing a completely new codebase, they do not have to be constrained by historical mistakes or backwards compatibility. They have a great opportunity to make new architectural and design choices. Building on top of other people's code is a good thing only if that code really supports what you want to do -- and there's probably more than a few free software projects that have had cause to regret deriving from an existing code base which in the long run turned out to not really be suitable. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Advocating non-free softwares
On 02/27/2013 11:41 AM, Han-Wen Nienhuys wrote: I am and have been ambivalent about being part of the GNU project. It has come with a lot of harping about how we should say things (like insisting on naming Linux as "GNU/Linux"), with little in return. At the risk of opening up a can of worms, I've long felt there was something of an inconsistency in Lilypond's relationship to GNU and GNU policy in any case. The most obvious oddity is that LP requires contributors to use a non-free software service -- Google Code -- to track bugs. I'm not saying "You have to ..." or taking a pro/anti-GNU position, it just strikes me as odd. In fact the divergence between LP and GNU was stronger a few years ago, when I got rather aggressively put down during a list discussion on C/C++ coding style for suggesting the GNU style guidelines -- this has clearly since changed... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
On 02/22/2013 09:02 PM, Henning Hraban Ramm wrote: I think his point was that _no_ file format ever describes exactly how the finished score would appear No? We have PDF. Maybe they have too. >:->> Write once, read many, edit difficult ;-) ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: Hushing up Sibelius news?
(Apologies to David, I hit "Reply" instead of "Reply List" when first writing this response.) On 02/22/2013 12:10 AM, David Kastrup wrote: If the file format describes exactly how the finished score will appear, what will happen with the spacing when transposing? Presumably it is ingrained into the file, so how will everything get retrofitted? I think his point was that _no_ file format ever describes exactly how the finished score would appear -- it depends on the internal algorithms of the software that processes the file format. Reading between the lines, I think that what may be being suggested there is that, to make the format "useful" they would have to provide not just spec for the format, but also spec for how that format should be interpreted by an application -- and surprise surprise, they want to keep those algorithms a closely guarded secret ... ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 19th-cent. accidental notation
On 02/18/2013 03:17 AM, Luca Rossetto Casel wrote: Yes, in most cases brackets are indeed unnecessary. But I know some over-accurate editions that aim to reproduce the original text as faithfully as possible, giving evidence to every critical intervention - for example, the Ricordi critical edition of Verdi's works. Well, Ricordi have a karma debt to pay after some of the very unfaithful editions they produced in the last century ... ;-) Generally I think it's a good thing to be as clear as possible about editorial interventions, but I'm not sure that modernizing the _style_ of accidental placement really counts as an "intervention" in that sense. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 19th-cent. accidental notation
On 02/17/2013 04:48 PM, Luca Rossetto Casel wrote: In present editions, this notation is generally uniformed to the modern one - eventually putting the added alterations in parentheses or brackets. Is this really a case where brackets would be used? The typical reason for inserting a bracketed accidental would be a case where the accidental is missing in all sources, but musical context makes it almost certain that the accidental should be there. The situation described here is slightly different as it isn't so much a _missing_ accidental in the real sense, as a different stylistic convention for placement of accidentals. It seems like the sort of circumstance where most editors and editions, including Urtext, would feel comfortable placing the accidentals without comment or brackets. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: 19th-cent. accidental notation
On 02/17/2013 01:10 PM, Javier Ruiz-Alma wrote: I found an accidental notation rule in 1803 music introductory textbook by M. Clementi, says accidental was also omitted on the following bar it when happened to be first note played of same pitch as prior bar accidental (explicit example shown involves non-tied notes). Seemed intuitive in the context of several of the pieces (see attached sample), so I've been applying [\once \override Voice.Accidental #'stencil = ##f] as needed in the typeset. Just wondered if there were some classical notation gurus that could educate me on how common this practice was (i.e. non-tied accidentals carrying over to first note of following bar). I think this is a case in a modern edition where an editor would see no problem in inserting the accidental. A good player of music of the period would surely identify the correct note to play no matter what, but there's no reason to be ambiguous. You're not altering the musical text by doing so. Following modern practice in this context is akin to notating tuplets with the "square" bracket rather than the earlier slur-like one -- the historical notation is unacceptably ambiguous and you're not actually interfering with the musical text by removing the ambiguity. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
Re: A must-see for anybody on this list
On 02/14/2013 05:32 PM, Urs Liska wrote: Maybe I'll get in touch with you before. I already intended to present the outline of the presentation here and ask for feedback - I think it's an issue that concerns many of us ... (The presentation is due at the end of April, so it will be some time still). That'd be great. There's a paper I'm working on right now (not oriented towards music) which I'll try and share with you when it's done -- might be useful despite its different orientation. From the discussion on this list I assume that there are two very different 'stages' to this. One is the raw musical content, which seems to be quite easily converted (I think something like an XSLT-like transformation of LilyPond's music stream). If one wants to also export LilyPond's layout qualities it would be much more intricate because at the time LilyPond makes its layout decisions that music stream isn't available anymore. What I was thinking of was e.g. how well the conversion process would preserve articulations, ornaments, etc. Some layout aspects here have "raw musical content" value, e.g. think of a turn that is placed on the second half of a note. Preparing a "manuscript" with LilyPond isn't the way to go because nowadays many (most) publishers won't pay engraving staff when they also can get editors doing that work for free. (This actually is the reason I didn't get a contract for editing a few works for UE). True with composers too, I think. I remember about 14 years back a friend told me that his publisher had got in touch with him and said, "OK, we're going to buy you a copy of Finale. The quid pro quo is that now you do all your own score preparation." Then again, when you go to many 20th-century works, the score is often just a facsimile of the composer's fair copy. ___ lilypond-user mailing list lilypond-user@gnu.org https://lists.gnu.org/mailman/listinfo/lilypond-user
