Re: New version of articulate available
There's now a new version of Articulate on the NICTA website. The only change is the licence --- this version (1.6) is released under GPL version 3.0, so there should be no barrier to distributing it with Lilypond. As usual, it's available from http://nicta.com.au/people/chubbp/articulate Sorry i can't give a link to the direct download file, as the CMS generates such links in ways I can't fathom. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/29 Peter Chubb lily.u...@chubb.wattle.id.au: There's now a new version of Articulate on the NICTA website. The only change is the licence --- this version (1.6) is released under GPL version 3.0, so there should be no barrier to distributing it with Lilypond. As usual, it's available from http://nicta.com.au/people/chubbp/articulate Thank you, I will set up a new patch. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Mon, Mar 21, 2011 at 11:46:21AM +0100, David Kastrup wrote: Peter Chubb lily.u...@chubb.wattle.id.au writes: I'll do it if I have to to get it merged, but i was hoping it wouldn't be necessary. The GPLv3 states under 5 Conveying modified source versions I don't see articulate.ly as a modified source version, unless I misunderstand that term. c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. To clarify, this only refers to something called modofied source version, right? I mean, the docs are under GPL FDL 1.3+; this paragraph doesn't somehow require that the docs are placed under GPLv3, right? Graham Isn't that precisely the question? You wrote: It is not even Graham clear that Peter can release/distribute it under GPL version Graham 2.0 unless it will work unmodified with a version of Lilypond Graham released under GPL version 2.0 It will so work. It was written to use the public interfaces provided by version 2.12, which is GPL version 2.0. If it is written using _public_ interfaces, it can be reasonably considered an independent work and distributed separately. As I claim. But making it an _integral_ part of Lilypond will not be feasible. You're talking about moving the code into a C++ performer, right? I'm not talking about that. I'm talking about putting it in ly/, as an optional include. That's not integral. And if you think this kind of nonsense is stifling industry and innovation rather than furthering it, don't tell me. I think this is nonsense, not because of the copyright law (although that certainly *is* nonsense!), but because as far as I can see, articulate.ly only uses public interfaces[1], is not an integral part of lilypond, and thus all these concerns are not valid. [1] with that slight quibble about the 4-6 lines of scheme code that he copied from FeatherDurations or whatever, which I believe isn't even called at the moment. Those should be removed or rewritten. That's preaching to the choir. Tell your congressman. Neither Peter nor I have congressmen. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Graham Percival gra...@percival-music.ca writes: On Mon, Mar 21, 2011 at 11:46:21AM +0100, David Kastrup wrote: Peter Chubb lily.u...@chubb.wattle.id.au writes: I'll do it if I have to to get it merged, but i was hoping it wouldn't be necessary. The GPLv3 states under 5 Conveying modified source versions I don't see articulate.ly as a modified source version, unless I misunderstand that term. The whole Lilypond of tomorrow is a modified source version of today, containting parts that various authors licensed as their personal contribution under the GPLv3 to the Lilypond project. And are you going to guarantee that articulate.ly is not going to be changed by anybody but the original copyright holder? How are you going to lock it down against modification? c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it. To clarify, this only refers to something called modofied source version, right? I mean, the docs are under GPL FDL 1.3+; this paragraph doesn't somehow require that the docs are placed under GPLv3, right? I don't claim that I understand the FSF stance with regard to mixing FDL and GPL in Emacs (neither does Debian, by the way). For Lilypond, the manual is not as thoroughly hyperlinked and integrated into the operation of the program, anyway. Considering them separate makes more sense here. But making it an _integral_ part of Lilypond will not be feasible. You're talking about moving the code into a C++ performer, right? Into _anything_ being run as an integral and substantial part of Lilypond operation. I'm not talking about that. I'm talking about putting it in ly/, as an optional include. That's not integral. The XEmacs project has gone through about 18 months of pain in order to get their library code based migrated to GPLv3. Those are mostly distributed as separate packages (in the package tree), maintained in a separate repository, that usually are just loaded by explicit demand of the user. The XEmacs project is not particularly sympathetic towards the goals and opinions of the FSF and is most certainly not a GNU project. And if you think this kind of nonsense is stifling industry and innovation rather than furthering it, don't tell me. I think this is nonsense, not because of the copyright law (although that certainly *is* nonsense!), but because as far as I can see, articulate.ly only uses public interfaces[1], is not an integral part of lilypond, and thus all these concerns are not valid. If we document it as an integral part of Lilypond and distribute it as an integral part of Lilypond and distribute it as an integral part of Lilypond, that seems like a bit of a stretch. Apart from that, any artificial measures designed to _not_ make it appear an integral part of Lilypond are going to be a mistake and nuisance, because it or the equivalent of its functionality certainly _should_ become an integral part of Lilypond. And shooting the messenger is not going to particularly help. Neither is postponing thinking about license problems. I am maintainer of AUCTeX which is in a kind of legal limbo with regard to copyright assignments (and consequently not fit for mainline Emacs inclusion) because it has been decades in development before anybody bothered thinking about that kind of stuff. Some old contributors can't be reached anymore, probably partly because they have died and their legal heirs can't be reached or bothered. It's a mess that is not, I repeat, not improving over time by ignoring it. The longer you ignore it, the more of a mess it becomes. And bashing me is not going to change the situation one bit, even though you appear to consider it a useful approach to the problem. You don't need to rely on my judgment which you consider faulty. You can instead ask licensing at fsf.org which has the advantage that you will actually be put in contact with lawyers with relevant experience. Somewhat helpful may also be URL:http://www.gnu.org/prep/maintain/html_node/External-Libraries.html#External-Libraries which talks about the separate/integral issue in the context of copyright assignments. While the situation regarding articulate.ly is not about assigning copyright, it still is about the question when and when not a module is to be considered a part of the whole, in the legal sense employed by the GPL. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
David == David Kastrup d...@gnu.org writes:p David Graham Percival gra...@percival-music.ca writes: On Mon, Mar 21, 2011 at 11:46:21AM +0100, David Kastrup wrote: The GPLv3 states under 5 Conveying modified source versions I don't see articulate.ly as a modified source version, unless I misunderstand that term. David The whole Lilypond of tomorrow is a modified source version of David today, containting parts that various authors licensed as their David personal contribution under the GPLv3 to the Lilypond project. David And are you going to guarantee that articulate.ly is not going David to be changed by anybody but the original copyright holder? You can do that now under GPLv2. But I've talked to the lawyers, and will arrange a new release this week under GPL v3.0. I still can't put in `or later'. But that should do for now. But making it an _integral_ part of Lilypond will not be feasible. You're talking about moving the code into a C++ performer, right? David Into _anything_ being run as an integral and substantial part David of Lilypond operation. It will never be this. and to avoid any future issue I'd much rather have it in a `contrib' directory, so it's clear it's distributed with lilypond but is not a core part of lilypond. It would then fall under the `collection' rules in the GPL. This would also be useful for other snippets/scheme/ly libraries. Currently we don't have a `contrib' tree. Moving articualte functionality into a performer (which I think is the right approach long-term) isn't a copyright issue, because you can't just copy the code (scheme into C++?). The *only* tricky bit, the only part of articulate that contains any substantial IP, is calculating trill timings. And it's a real hack full of mostly but not perfect heuristics, and should probably be redesigned anyway. Peter C -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Peter Chubb lily.u...@chubb.wattle.id.au writes: Moving articualte functionality into a performer (which I think is the right approach long-term) isn't a copyright issue, because you can't just copy the code (scheme into C++?). Scheme performers are desirable at one point of time, but their structure would likely be different from yours. The *only* tricky bit, the only part of articulate that contains any substantial IP, is calculating trill timings. And it's a real hack full of mostly but not perfect heuristics, and should probably be redesigned anyway. Heuristics are usually more or less mathematics and not subject to copyright. Copyright protects the expression of an idea, not the idea itself. So translating the program flow into another language is a problem, writing down the heuristics and implementing it in the appropriate manner for some language independently isn't (short of patents). Large companies needing to steer clear of problems let one set of people read the problematic code and write out the principles and specs, and another set write new code according to specs. A so-called clean room implementation. Not that we needed to get as absurd as that. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Tue, Mar 22, 2011 at 04:08:18PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: On Mon, Mar 21, 2011 at 11:46:21AM +0100, David Kastrup wrote: The GPLv3 states under 5 Conveying modified source versions I don't see articulate.ly as a modified source version, unless I misunderstand that term. The whole Lilypond of tomorrow is a modified source version of today, containting parts that various authors licensed as their personal contribution under the GPLv3 to the Lilypond project. So it's legally impossible for us to have part of the source tree that's public domain (i.e. the snippets), part under FDL, part under GPLv3, and part under the MIT license? I do not believe that simply having something in the same tarball (or git tree) means that they must have the same license. If that were true, then any attempt at a distribution (be it linux, freebsd ports tree, macports) would go beserk. And are you going to guarantee that articulate.ly is not going to be changed by anybody but the original copyright holder? Dump a comment at the top. If anybody ignores that comment, it's their fault. To clarify, this only refers to something called modofied source version, right? I mean, the docs are under GPL FDL 1.3+; this paragraph doesn't somehow require that the docs are placed under GPLv3, right? I don't claim that I understand the FSF stance with regard to mixing FDL and GPL in Emacs (neither does Debian, by the way). For Lilypond, the manual is not as thoroughly hyperlinked and integrated into the operation of the program, anyway. Considering them separate makes more sense here. IMO, considering a lot of things to be separate makes sense. If there is some legal reason why things cannot be separate, then please share it. Clearly if you compile C++ together, they are not separate. Other than that, it seems to me that something is separate if we consider it to be separate. With regards to articulate.ly, you seem to want to consider it to be not separate, whereas I want to consider it to be separate. I have not heard any kind of legal test to decide if something is separate or not. But making it an _integral_ part of Lilypond will not be feasible. You're talking about moving the code into a C++ performer, right? Into _anything_ being run as an integral and substantial part of Lilypond operation. Yes. And I claim that having a file ending in .ly in a tarball does *not* consistitute to be an integral and substantial part. Or, in other words, I think we can consider them to be separate. I'm not talking about that. I'm talking about putting it in ly/, as an optional include. That's not integral. The XEmacs project has gone through about 18 months of pain in order to get their library code based migrated to GPLv3. Those are mostly distributed as separate packages (in the package tree), maintained in a separate repository, that usually are just loaded by explicit demand of the user. articulate.ly would be in the source tree (along with MIT-licensed stuff), but would still just loaded by explicit demand of the user. IMO, that counts as separate, and not an integral and substantial part. Would you feel better if we created a directory called: ly/not-an-integral-part/ to store such files? I think this is nonsense, not because of the copyright law (although that certainly *is* nonsense!), but because as far as I can see, articulate.ly only uses public interfaces[1], is not an integral part of lilypond, and thus all these concerns are not valid. If we document it as an integral part of Lilypond So we document it as a non-integral part. and distribute it as an integral part of Lilypond and distribute it as an integral part of Lilypond, that seems like a bit of a stretch. So we put it in the ly/not-an-integral-part/ directory. Apart from that, any artificial measures designed to _not_ make it appear an integral part of Lilypond are going to be a mistake and nuisance, because it or the equivalent of its functionality certainly _should_ become an integral part of Lilypond. I'm not talking about whether somebody might want to add code to a Performer. I'm talking about the articulate.ly, created by Peter, which is not going into a Performer or anything like that. And shooting the messenger is not going to particularly help. Neither is postponing thinking about license problems. I'm not shooting you. I'm stating, for the record, which might matter in some weird universe in which somebody tries to sue somebody over this, that I see no legal reason why a text file in a directory of a tarball, which is not compiled with other stuff, and which requires explicit user request to include, should count as an integral part of lilypond. It is not loaded by default. Users can include non-GPL'd .ly files at their whim. Our source tree contains other non-GPL'd files. Somewhat helpful may also be
Re: New version of articulate available
Peter Chubb lily.u...@chubb.wattle.id.au writes: Graham == Graham Percival gra...@percival-music.ca writes: Graham On Sun, Mar 20, 2011 at 04:23:12PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: The suggestion that a .ly file would somehow be a derivative work of lilypond is ridiculous. Depends on how interlocked and crossdependent it is with internals of Lilypond and whether or not stuff has been cross-copied. Graham If there's no allowances for interoperability, and if the Graham amount of interlocked-ness (how do we measure this?) of Graham articulate.ly means that it's a derivative work, then any Graham serious use of scheme functions in lilypond would Graham automatically mean that the music must be GPLv3 or later. I wrote articulate in 2008. At that time, Lilypond was released under GPL v2.0. Therefore at that time there was no conflict. Yes and no. You certainly were not in breach of Lilypond's license. However, Lilypond as a whole was licensed under the GPLv2.0 or at your choice, any later version. That means that even at that time, code in articulate.ly, licensed under GPLv2.0 only, would have to be kept separate from Lilypond proper. You could have released your own variant of Lilypond integrating articulate.ly under GPLv2.0 only. There's no in principle reason why it shouldn't be relicensed under GPL3.0, except it means another round with our lawyers to get a release signed, which I really don't want to have to do. I very much imagine so. Here is my personal estimate of the situation, and it will be quite easy to ask the FSF copyright clerk for reconfirmation or a more qualified opinion. First please bear in mind that there is no point in shooting the messenger. I am _reporting_ the situation as I think it is. I am not creating the situation. First thing to note is that _currently_, any licensing problems are pursued in civil courts by request of the copyright holder. So unless a copyright holder takes action, there are no liabilities. Note that the U.S. currently tries to change the laws, turning copyright violations into a felony, meaning that district attorneys might pursue them _against_ the wishes of the copyright holders (like they can pursue rape or blackmail against the wishes of the victims). URL:http://news.cnet.com/8301-31921_3-20043421-281.html Don't berate me, berate your congressman. And do it in time. Currently, we are still talking about civil court and action taken by request of any copyright holder. Lilypond is currently licensed under GPLv3, or, at your choice, any later version released by the FSF. That is not likely to amuse company lawyers because that introduces an unknown into the equation. The FSF is limited in what future versions of the GPL might be: when they receive copyright assignments (for mission-critical software like GCC or Emacs), they give out a written contract specifying that future versions of the license will guarantee access by the public and granting the copyright holder no specific rights over the public (of course, as long as the copyright holder is the _sole_ copyright holder, he implicitly has the option to relicense under any license he wants to). So the FSF is quite limited in scope about what or any later version can mean. At the same time, the legal/computational landscape changes: nowadays there are effective ways to render the promises of the GPLv2 to the end user moot by reverting to software patents and/or digital rights management. The FSF tries keeping the GPL effective and users in charge of obtaining the source needed to understand and modify their software copies. Changes to the GPL are done in order to keep a pool of essential and copylefted software available and dependable to the public. One project with a _large_ pool of GPLv2 only software is XEmacs. They are trying to upgrade to GPLv3+, and are almost there (it is important so that they can keep updating packages that are part of Emacs, which has changed to GPLv3+ years ago). It is a total mess, annoying lots of people, but they are close to getting there. It also means weeding out code for which one can't round up the necessary people, either because they have dropped off the landscape or because nobody knows who they were. Or because they refuse to be bothered. Of course, everybody curses the FSF for coming up with new versions of the GPL, and nobody bothers cursing the politicians for coming up with utterly ridiculous copyright and patent laws tailored to the whims of the big industry lobbies, necessitating new GPL versions in order to keep free software availability. Shoot the messenger all over. I'll do it if I have to to get it merged, but i was hoping it wouldn't be necessary. The GPLv3 states under 5 Conveying modified source versions c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will
Re: New version of articulate available
On 11-03-21 04:46 AM, David Kastrup wrote: snippage of licensing issues occureth By one of those delightful synchronicities, the following came up in today's AWAD: usufruct *PRONUNCIATION:* (YOO-zuh-fruhkt, -suh-) http://wordsmith.org/words/usufruct.mp3 *MEANING:* /noun/: The right to use and enjoy another's property without destroying it. *ETYMOLOGY:* From Latin ususfructus, from usus et fructus (use and enjoyment). Earliest documented use: 1646. *USAGE:* It is currently in the process of purchasing perpetual usufruct rights to a number of plots. Budlex Prepares for Large Residential Project; Warsaw Business Journal (Poland); Jan 17, 2011. A Word A Day is found at http://wordsmith.org/ and highly recommended! Colin -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Henning == Henning Hraban Ramm hra...@fiee.net writes: Henning Am 2011-03-18 um 11:47 schrieb Graham Percival: On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote: Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Why not? That's certainly how I'd start going about this. I haven't looked at it, so I might notice some problem with that approach when I see a patch. Or other people might notice some problem with the approach. But that's definitely how to begin. Henning I wouldn’t make articulate default – I try it with every song Henning I typeset and like the result not always. Henning E.g. chords get shortened, that sounds ugly, esp. with organ Henning or the like. Or would I’ve to mark all chords tenuto? Of Henning course I can \articulate only some voices - but therefore it Henning must not be default. The default phrasing is non-legato. If you want chords to slur into each other, articulate needs to know that --- so put them under a slur or a phrasing slur. Henning Didn’t check: Does articulate handle fermatas/ritardandos? It handles ritardandos if they're marked rall. or rit. Fermatas are still on the to-do list. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/18 Francisco Vila paconet@gmail.com: 2011/3/18 Graham Percival gra...@percival-music.ca: On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote: Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Why not? That's certainly how I'd start going about this. I haven't looked at it, so I might notice some problem with that approach when I see a patch. Or other people might notice some problem with the approach. But that's definitely how to begin. The attached patch includes and documents the Articulate script. I've not checked, but is the license compatible with that of lilypond? A simple line stating this file has the same license as the lilypond package would serve. -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On 20 March 2011 09:55, Francisco Vila paconet@gmail.com wrote: I've not checked, but is the license compatible with that of lilypond? A simple line stating this file has the same license as the lilypond package would serve. According to the header of the articulate.ly script, it is GNU General Public License, version 2. IIRC LilyPond is GNU GPL version 3. Maybe Peter could change its script license to version 2 or later or version 3, so it would be effectively compatible. I'm glad that articulate is finally somewhat included officially into LilyPond, since I asked for it 9 months ago and it is a popular request on the LilyPond French Users mailing list. Many thanks! Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On 20/03/2011, at 7:55 PM, Francisco Vila paconet@gmail.com wrote: 2011/3/18 Francisco Vila paconet@gmail.com: 2011/3/18 Graham Percival gra...@percival-music.ca: On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote: Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Why not? That's certainly how I'd start going about this. I haven't looked at it, so I might notice some problem with that approach when I see a patch. Or other people might notice some problem with the approach. But that's definitely how to begin. The attached patch includes and documents the Articulate script. I've not checked, but is the license compatible with that of lilypond? A simple line stating this file has the same license as the lilypond package would serve. It's released under GPL version 2.0 Its copyright is held by myself and by my employer, NICTA, who reserve the right to release it under other licences at other times, and who wish the notice of copyright in the file to be retained. I also assert my moral right to be identified as the original author of the code, Ultimately I expect all this not to be an issue, as the articulate script is really a hack. Its functionality should really be part of the Performer context. And I'm hoping that now that attention has been focussed more on good MIDI output, someone will start hacking on that code to make the articulate script obsolete. Peter C ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On 3/20/11 2:55 AM, Francisco Vila paconet@gmail.com wrote: 2011/3/18 Francisco Vila paconet@gmail.com: 2011/3/18 Graham Percival gra...@percival-music.ca: On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote: Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Why not? That's certainly how I'd start going about this. I haven't looked at it, so I might notice some problem with that approach when I see a patch. Or other people might notice some problem with the approach. But that's definitely how to begin. The attached patch includes and documents the Articulate script. I've not checked, but is the license compatible with that of lilypond? A simple line stating this file has the same license as the lilypond package would serve. Actually, if it's part of the LilyPond distribution, it should have a standard LilyPond header. Peter, are you OK with giving this code to LilyPond? Thanks, Carl ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/20 Peter Chubb pe...@chubb.wattle.id.au: On 20/03/2011, at 7:55 PM, Francisco Vila paconet@gmail.com wrote: I've not checked, but is the license compatible with that of lilypond? A simple line stating this file has the same license as the lilypond package would serve. It's released under GPL version 2.0 Its copyright is held by myself and by my employer, NICTA, who reserve the right to release it under other licences at other times, and who wish the notice of copyright in the file to be retained. I am not an expert and can not decide if we can include it given that discrepancy. I also assert my moral right to be identified as the original author of the code, If your file says that, it will be respected. Don't bother about being a part of a commit done for another person. Ultimately I expect all this not to be an issue, as the articulate script is really a hack. Its functionality should really be part of the Performer context. And I'm hoping that now that attention has been focussed more on good MIDI output, someone will start hacking on that code to make the articulate script obsolete. Peter C -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/19 Federico Bruni fedel...@gmail.com: Il giorno ven, 18/03/2011 alle 16.54 +0100, Francisco Vila ha scritto: The attached patch includes and documents the Articulate script. there's a typo in line 76 of the patch: +etc., and take rallentendo and accelerando into account. s/rallentendo/rallentando Thanks; the published patch for revision already includes this. http://codereview.appspot.com/4277067 -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Francisco Vila paconet@gmail.com writes: 2011/3/20 Peter Chubb pe...@chubb.wattle.id.au: On 20/03/2011, at 7:55 PM, Francisco Vila paconet@gmail.com wrote: I've not checked, but is the license compatible with that of lilypond? A simple line stating this file has the same license as the lilypond package would serve. It's released under GPL version 2.0 Its copyright is held by myself and by my employer, NICTA, who reserve the right to release it under other licences at other times, and who wish the notice of copyright in the file to be retained. I am not an expert and can not decide if we can include it given that discrepancy. Not likely to work well. It is not even clear that Peter can release/distribute it under GPL version 2.0 unless it will work unmodified with a version of Lilypond released under GPL version 2.0. If it doesn't, the question is whether it counts as being a derivative of Lilypond. If Peter and/or his employer can't be persuaded to release this as GPL3+ (which does not touch their right to release and distribute it, in parallel, under any license they want to unless the code depends on the work of others), I strongly suggest not distributing it with the rest of Lilypond since any crosspollination, namely people using the code, its structure, documentation and whatever else will constitute a licensing violation of Peter's and his empoyer's licensing choice. Since that is an accident waiting to happen even if inclusion of articulate.ly could conceivably count as mere aggregation, we need to steer clear. Any other GPLvx.0 only (where x includes 3) bombs waiting to happen in the Lilypond code base? -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Sun, Mar 20, 2011 at 11:24:42AM +0100, David Kastrup wrote: Not likely to work well. It is not even clear that Peter can release/distribute it under GPL version 2.0 unless it will work unmodified with a version of Lilypond released under GPL version 2.0. If it doesn't, the question is whether it counts as being a derivative of Lilypond. The suggestion that a .ly file would somehow be a derivative work of lilypond is ridiculous. Writing a C++ to be compiled with gcc does not constitute a derivate work of gcc. Writing an html file to be displayed in Firefox does not consistute a derivative work of firefox. Creating graphics in GIMP does not constitute a derivative work of gimp. etc. articulate.ly is a 668-line .ly file containing a bunch of scheme. It is absolutely not a derivative work of lilypond. I strongly suggest not distributing it with the rest of Lilypond since any crosspollination, namely people using the code, its structure, documentation and whatever else will constitute a licensing violation of Peter's and his empoyer's licensing choice. The documentation was written by Francisco. I agree that this could cause a problem if anybody (other than Peter or a NICTA employee) ever tried to port these functions into a Performer. Since that is an accident waiting to happen even if inclusion of articulate.ly could conceivably count as mere aggregation, we need to steer clear. articulate.ly is an optional include. It's less aggrevated than the public domain snippets which we include in the manual. I can't imagine how anything that we (potentially) distribute could be more mere aggrevation than articulate.ly. Any other GPLvx.0 only (where x includes 3) bombs waiting to happen in the Lilypond code base? A few quick greps suggests that we have some 2.0 or later stuff, which isn't a problem. texinfo.tex, the big contender in my mind for 2.0, is 3.0 or later. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Sun, Mar 20, 2011 at 10:07:09AM +0100, Xavier Scheuer wrote: I'm glad that articulate is finally somewhat included officially into LilyPond, since I asked for it 9 months ago So what? I have been pointing out that it would be easy to add for 2 years. And on the more general topic of useful scheme functions it would be nice to include, I've been trying to recruit interested workers since 2007. Nobody's been interested. We are having this discussion because Francisco spent approximately 60 minutes working on this. Apparently you didn't care enough about this issue to spend 60 minutes working. So don't snark at everybody else who *also* didn't want to bother spending the time on this. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Henning! Nice work so far! Would be nice to have those things too. How difficult would be to have precise and smooth cresc. and dim. within the same note? But in this case you would have to know the instrument, given that a piano could not change the dynamics unless the next note is played. At the same time a violin would have total control of dynamics, if in the same note or a group of notes. Maybe it's more complicated to implement , for example, a dim . and a crescendo. which have a rhythmic aspect. For example: a short and sudden dim. followed by a smooth and long crescendo with the same note. Cheers! ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On 20 March 2011 15:39, Graham Percival gra...@percival-music.ca wrote: So what? I have been pointing out that it would be easy to add for 2 years. And on the more general topic of useful scheme functions it would be nice to include, I've been trying to recruit interested workers since 2007. Nobody's been interested. I was not here in 2007. We are having this discussion because Francisco spent approximately 60 minutes working on this. Apparently you didn't care enough about this issue to spend 60 minutes working. So don't snark at everybody else who *also* didn't want to bother spending the time on this. No, I do not really care about this issue. As I said in the second part of my sentence (that you did not quote in your reply above), this is a popular request by French users _other than me_ on the LilyPond French Users mailing list. I forward requests form French users to the international list, I report bugs from French to the appropriate place, but I do not solve/fix everything I am aware of. The goal of my message above was to thank Francisco to take care of this, and to express the gratitude of the French community for which this improvement will be warmly welcome. My goal was not to snark (BTW this verb was not in my English-French dictionary), nor to wake up the grumpy, unpleasant, abrupt Graham. Cheers, Xavier -- Xavier Scheuer x.sche...@gmail.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Graham Percival gra...@percival-music.ca writes: On Sun, Mar 20, 2011 at 11:24:42AM +0100, David Kastrup wrote: Not likely to work well. It is not even clear that Peter can release/distribute it under GPL version 2.0 unless it will work unmodified with a version of Lilypond released under GPL version 2.0. If it doesn't, the question is whether it counts as being a derivative of Lilypond. The suggestion that a .ly file would somehow be a derivative work of lilypond is ridiculous. Depends on how interlocked and crossdependent it is with internals of Lilypond and whether or not stuff has been cross-copied. Writing a C++ to be compiled with gcc does not constitute a derivate work of gcc. If the code is part of a C compiler based on gcc, things are not reasonably separate to warrant talking of mere aggregation without examining the details. A .ly file that represents some score certainly is separate from Lilypond. A .ly file that is intended to run as an integrated part of Lilypond when typesetting, however: I would not be able to call that a separate work without analyzing the source. Writing an html file to be displayed in Firefox does not consistute a derivative work of firefox. Writing a renderer in Javascript intended to do part of the display job of Firefox certainly results in an overall work that cannot in all cases considered the Javascript renderer a separate and independent work from Firefox. Creating graphics in GIMP does not constitute a derivative work of gimp. etc. articulate.ly is a 668-line .ly file containing a bunch of scheme. It is absolutely not a derivative work of lilypond. That is not the question. The license of Lilypond _and_ the license of articulate.ly _demand_ that the work _as_ _a_ _whole_ (with all its parts) be licensed under the GPLv3+ or GPLv2, respectively. If those works can't be reasonably considered independent, distributing them as one work intended to do one job is in breach of the respective licenses. I can't imagine how anything that we (potentially) distribute could be more mere aggrevation than articulate.ly. aggregation, please. See above. Any other GPLvx.0 only (where x includes 3) bombs waiting to happen in the Lilypond code base? A few quick greps suggests that we have some 2.0 or later stuff, which isn't a problem. texinfo.tex, the big contender in my mind for 2.0, is 3.0 or later. texinfo is not operating interlocked with or as a part of Lilypond, but used as a separate independent documentation compiler as far as I can tell, even though calling it is part of the build process. So I don't think its license, whatever it may be, should provide a problem as long as we don't put a general everything in this tarball is distributed under license xxx claim somewhere. Lilypond-book's calls of various TeX engines also don't exercise anything but their standard exposed and published API, so this also just constitutes mere aggregation with regard to the licenses. That it (and other components) are written in Python is also not an issue. And so on. I don't see that articulate.ly can be considered independent and separate like that. I'd have to look at it to tell. Since there is no published or generally accessible Midi API in Lilypond (I'd certainly want for one to be there), I have my doubts. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On 11-03-20 03:27 AM, Francisco Vila wrote: 2011/3/19 Federico Brunifedel...@gmail.com: Il giorno ven, 18/03/2011 alle 16.54 +0100, Francisco Vila ha scritto: The attached patch includes and documents the Articulate script. there's a typo in line 76 of the patch: +etc., and take rallentendo and accelerando into account. s/rallentendo/rallentando Thanks; the published patch for revision already includes this. http://codereview.appspot.com/4277067 I've added issue 1568 to track the status of this enhancement, Francisco. Colin Campbell Bug Squad -- The test of our progress is not whether we add more to the abundance of those who have much, it is whether we provide enough for those who have too little. -Franklin D. Roosevelt, 32nd US President (1882-1945) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Sun, Mar 20, 2011 at 04:23:12PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: The suggestion that a .ly file would somehow be a derivative work of lilypond is ridiculous. Depends on how interlocked and crossdependent it is with internals of Lilypond and whether or not stuff has been cross-copied. If there's no allowances for interoperability, and if the amount of interlocked-ness (how do we measure this?) of articulate.ly means that it's a derivative work, then any serious use of scheme functions in lilypond would automatically mean that the music must be GPLv3 or later. That's crazy. If that's actually true -- which I doubt -- then I would argue in the strongest possible terms that we should add a using the lilypond scheme API does not require that the music is placed under the GPLv3, similar to our font exception. My personal stake is that I'm using scheme to extract music events from lilypond for Vivi. I was planning on placing Vivi under the GPLv3, but I *don't* like being forced to do so. If using lilypond scheme actually means that -- and if we don't add an exception to allow the use of scheme code and calling ly:music-functions in our own .ly files -- then I'll seriously look at dropping lilypond input and use musicxml instead. A .ly file that represents some score certainly is separate from Lilypond. A .ly file that is intended to run as an integrated part of Lilypond when typesetting, however: I would not be able to call that a separate work without analyzing the source. Please examine articulate.ly in detail and give your opinion about whether it is legal for Peter (and NICTA) to place that work under the GPLv2. This is a very serious allegation, and I think we should clear it up immediately, before even thinking about any patches. I will admit that one comment in articulate.ly says: % Gradually speed up a piece of music. Stolen from the feather % code in % the Lilypond base. % Overflows moment and causes infinite Lilypond loop, or segv % --- DON'T USE #(define (ac:accel music factor) Since articulate.ly was primarily written in 2008, I would expect this to have come from the GPLv2 version of lilypond (as it was until Fall 2009... actually, the stable 2.12 version is still under GPLv2). And it that DON'T USE comment is accurate, then perhaps the entire function should be removed to avoid confusion. articulate.ly is a 668-line .ly file containing a bunch of scheme. It is absolutely not a derivative work of lilypond. That is not the question. Isn't that precisely the question? You wrote: It is not even clear that Peter can release/distribute it under GPL version 2.0 unless it will work unmodified with a version of Lilypond released under GPL version 2.0 If articulate.ly is not a derivative work, then he (and/or his employer) are free to choose any license they wish. If, for some reason, articulate.ly *is* a derivative, then he (and/or his employer) are *not* free to choose any license. At the moment, I don't care about the patch. I'm shocked at the suggestion that Peter's research might be illegal, and I would like you to clarify this as soon as possible. Please example articulate.ly in detail, and give your opinion as to whether it consititutes a derivate work. - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Graham == Graham Percival gra...@percival-music.ca writes: Graham On Sun, Mar 20, 2011 at 04:23:12PM +0100, David Kastrup wrote: Graham Percival gra...@percival-music.ca writes: The suggestion that a .ly file would somehow be a derivative work of lilypond is ridiculous. Depends on how interlocked and crossdependent it is with internals of Lilypond and whether or not stuff has been cross-copied. Graham If there's no allowances for interoperability, and if the Graham amount of interlocked-ness (how do we measure this?) of Graham articulate.ly means that it's a derivative work, then any Graham serious use of scheme functions in lilypond would Graham automatically mean that the music must be GPLv3 or later. I wrote articulate in 2008. At that time, Lilypond was released under GPL v2.0. Therefore at that time there was no conflict. There's no in principle reason why it shouldn't be relicensed under GPL3.0, except it means another round with our lawyers to get a release signed, which I really don't want to have to do. I'll do it if I have to to get it merged, but i was hoping it wouldn't be necessary. Graham Isn't that precisely the question? You wrote: It is not even Graham clear that Peter can release/distribute it under GPL version Graham 2.0 unless it will work unmodified with a version of Lilypond Graham released under GPL version 2.0 It will so work. It was written to use the public interfaces provided by version 2.12, which is GPL version 2.0. And that is why GPL v2.0 was chosen as the licence when I went through the rigmarole I had to to get clearance to release it. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au http://www.ertos.nicta.com.au ERTOS within National ICT Australia ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Il giorno ven, 18/03/2011 alle 16.54 +0100, Francisco Vila ha scritto: The attached patch includes and documents the Articulate script. there's a typo in line 76 of the patch: +etc., and take rallentendo and accelerando into account. s/rallentendo/rallentando ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Am 18.03.2011 02:13, schrieb Graham Percival: On Fri, Mar 18, 2011 at 01:56:05AM +0100, Martin Tarenskeen wrote: But let's stay on-topic: Keep up the good work with your articulate script. Any chance articulate will be an integrated, built-in functionality in Lilypond in the future ? I estimate it would take about 5 hours from a Frog. I've been estimating this for the past few years, but nobody's even attempted to tackle it yet. How whould you like to see the script included? Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Regards, Marc So, I guess not much chance. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Marc Hohl m...@hohlart.de writes: Am 18.03.2011 02:13, schrieb Graham Percival: On Fri, Mar 18, 2011 at 01:56:05AM +0100, Martin Tarenskeen wrote: But let's stay on-topic: Keep up the good work with your articulate script. Any chance articulate will be an integrated, built-in functionality in Lilypond in the future ? I estimate it would take about 5 hours from a Frog. I've been estimating this for the past few years, but nobody's even attempted to tackle it yet. How whould you like to see the script included? Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... I should think the idea would be that nothing at all changes for the user interface (except possibly for additional tweaks and settings becoming available and hopefully documented) except that the MIDI output improves its similarity to the score. -- David Kastrup ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote: Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Why not? That's certainly how I'd start going about this. I haven't looked at it, so I might notice some problem with that approach when I see a patch. Or other people might notice some problem with the approach. But that's definitely how to begin. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
Am 2011-03-18 um 11:47 schrieb Graham Percival: On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote: Just adding articulate.ly in ly/ and giving one example in the docs is probably not what you expect ... Why not? That's certainly how I'd start going about this. I haven't looked at it, so I might notice some problem with that approach when I see a patch. Or other people might notice some problem with the approach. But that's definitely how to begin. I wouldn’t make articulate default – I try it with every song I typeset and like the result not always. E.g. chords get shortened, that sounds ugly, esp. with organ or the like. Or would I’ve to mark all chords tenuto? Of course I can \articulate only some voices - but therefore it must not be default. Didn’t check: Does articulate handle fermatas/ritardandos? Greetlings from Lake Constance --- fiëé visuëlle Henning Hraban Ramm http://www.fiee.net http://angerweit.tikon.ch/lieder/ https://www.cacert.org (I'm an assurer) ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/18 Graham Percival gra...@percival-music.ca:
On Fri, Mar 18, 2011 at 09:17:47AM +0100, Marc Hohl wrote:
Just adding articulate.ly in ly/ and giving one example in the docs
is probably not what you expect ...
Why not? That's certainly how I'd start going about this. I
haven't looked at it, so I might notice some problem with that
approach when I see a patch. Or other people might notice some
problem with the approach. But that's definitely how to begin.
The attached patch includes and documents the Articulate script.
--
Francisco Vila. Badajoz (Spain)
www.paconet.org , www.csmbadajoz.com
From 783b15d3ff1d45cda9856b68cc80aa13a397d90b Mon Sep 17 00:00:00 2001
From: Francisco Vila francisco.v...@hispalinux.es
Date: Fri, 18 Mar 2011 16:52:31 +0100
Subject: [PATCH] Include and document the Articulate script by Peter Chubb.
---
Documentation/notation/input.itely | 57 +++-
ly/articulate.ly | 668
2 files changed, 724 insertions(+), 1 deletions(-)
create mode 100644 ly/articulate.ly
diff --git a/Documentation/notation/input.itely b/Documentation/notation/input.itely
index 131b445..1a4afab 100644
--- a/Documentation/notation/input.itely
+++ b/Documentation/notation/input.itely
@@ -1686,6 +1686,10 @@ what was entered. This is convenient for checking the music; octaves
that are off or accidentals that were mistyped stand out very much
when listening to the MIDI output.
+Standard MIDI oputput is somewhat crude; optionally, an enhanced and
+more realistic MIDI output is available by means of the Articulate
+script.
+
@c TODO Check this
The midi output allocates a channel for each staff, and one for global
settings. Therefore the midi file should not have more than 15 staves
@@ -1908,6 +1912,13 @@ within a score block defined with a @code{\score} command.
@cindex MIDI, chord names
@cindex Rhythms in MIDI
@cindex MIDI, Rhythms
+@cindex Articlulate scripts
+@cindex MIDI, articulations
+@cindex articulations in MIDI
+@cindex trills in MIDI
+@cindex turns in MIDI
+@cindex rallentando in MIDI
+@cindex accelerando in MIDI
@c TODO etc
The following items of notation are reflected in the MIDI output:
@@ -1926,11 +1937,22 @@ player that supports pitch bend.)
@item Lyrics
@end itemize
+Using the Articulate script, a number of items are added to the above
+list:
+
+@itemize
+@item Articulations (slurs, staccato, etc)
+@item Trills, turns
+@item Rallentando and accelerando
+@end itemize
+
+
@unnumberedsubsubsec Unsupported in MIDI
@c TODO index as above
-The following items of notation have no effect on the MIDI output:
+The following items of notation have no effect on the MIDI output,
+except those enabled by the Articulate script when it is used:
@itemize
@item Rhythms entered as annotations, e.g. swing
@@ -2273,4 +2295,37 @@ set.
Because the general MIDI standard does not contain rim shots, the
sidestick is used for this purpose instead.
+@node The Articulate script
+@subsection The Articulate script
+
+A more realistic MIDI output is possible when using the Articulate
+script. It tries to take articulations (slurs, staccato, etc) into
+account, by replacing notes with sequential music of suitably
+time-scaled note plus skip. It also tries to unfold trills turns
+etc., and take rallentendo and accelerando into account.
+
+@unnumberedsubsubsec Using the Articulate script
+
+To use the Articulate script, you have to include it at the top of
+your input file,
+
+@example
+\include articulate.ly
+@end example
+
+and in the @code{\score} section do
+
+@example
+\unfoldRepeats \articulate
+ all the rest of the score...
+
+@end example
+
+After altering your input file this way, the visual output is heavily
+altered, but the standard @code{\midi} block will produce a better
+MIDI file.
+
+@knownissues
+Articulate shortens chords and some music (esp. organ music) could
+sound worse.
diff --git a/ly/articulate.ly b/ly/articulate.ly
new file mode 100644
index 000..3e98c8e
--- /dev/null
+++ b/ly/articulate.ly
@@ -0,0 +1,668 @@
+%
+% Copyright (C) 2008, 2009, 2010, 2011 NICTA
+% Author: Peter Chubb peter.chubb AT nicta.com.au
+% $Id: articulate.ly,v 1.6 2011-03-15 22:46:11 peterc Exp $
+%
+%
+% This program is free software; you can redistribute it and/or modify
+% it under the terms of the GNU General Public License, version 2,
+% as published by the Free Software Foundation.
+%
+% This program is distributed in the hope that it will be useful,
+% but WITHOUT ANY WARRANTY; without even the implied warranty of
+% MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
+% See the GNU General Public License for more details. It is
+% available in the Lilypond source tree, or at
+% http://www.gnu.org/licenses/old-licenses/gpl-2.0.html
+%
+% This script tries to make MIDI output from LilyPond a little more realistic.
+% It tries to take articulations (slurs, staccato, etc) into account, by
+% replacing notes
Re: New version of articulate available
Francisco Vila wrote Friday, March 18, 2011 3:54 PM The attached patch includes and documents the Articulate script. Looks pretty good! My only comment is that it might be better to suggest two \score blocks, one for printing without \articulate and \midi, and one for playback with \articulate and \midi and without \layout. Trevor ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Fri, Mar 18, 2011 at 04:54:12PM +0100, Francisco Vila wrote:
The attached patch includes and documents the Articulate script.
Looks pretty good, but I'd like to have a rietveld issue for
easier commenting.
+and in the @code{\score} section do
+
+@example
+\unfoldRepeats \articulate
+ all the rest of the score...
+
+@end example
Is this necessary to use articulate.ly ? I kind-of assumed that
this would only be necessary if you wanted to, umm, unfold the
repeats?
+After altering your input file this way, the visual output is heavily
+altered, but the standard @code{\midi} block will produce a better
+MIDI file.
Maybe we should beef up the use a separate score block for midi
stuff... but that's something that we can work on after getting
the initial patch accepted.
Cheers,
- Graham
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/18 Graham Percival gra...@percival-music.ca: On Fri, Mar 18, 2011 at 04:54:12PM +0100, Francisco Vila wrote: The attached patch includes and documents the Articulate script. Looks pretty good, but I'd like to have a rietveld issue for easier commenting. I will try to do that, I've never done it. Gimme some time -- Francisco Vila. Badajoz (Spain) www.paconet.org , www.csmbadajoz.com ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
New version of articulate available
Version 1.5 of the Articulate scripts is now available from
http://www.nicta.com.au/people/chubbp/articulate/
This version adds support for mordents --- thanks to Patrick Karl who
reported the issue.
The next big thing I'd like Lilypond to do is to handle dynamics in
MIDI better. The problem is things like:
\version 2.13.55
\score {
\relative c' {
\set Staff.midiInstrument = clarinet
\tempo 8=44
\cadenzaOn
fis'8\ppp \ ~ fis2. ~ fis8 \!\ \bar |
}
}
(from Messiaen's `Abime des Oiseaux', bar 13) -- a smooth crescendo
over almost the full range of the instrument. Lily renders it in
three steps. And the original is more like:
\score {
\relative c' {
\set Staff.midiInstrument = clarinet
\tempo 8=44
\cadenzaOn
fis'1 \\
{ s8\ppp \ ~ s2. ~ s8 \!\ }
\bar |
}
\layout{}
\midi{}
}
but that renders really badly.
--
Dr Peter Chubb peter DOT chubb AT nicta.com.au
http://www.ertos.nicta.com.au ERTOS within National ICT Australia
All things shall perish from under the sky/Music alone shall live, never to die
___
lilypond-user mailing list
lilypond-user@gnu.org
http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Fri, 18 Mar 2011, Peter Chubb wrote: (from Messiaen's `Abime des Oiseaux', bar 13) -- a smooth crescendo over almost the full range of the instrument. I love that piece ! Which is remarkable, since I hate most clarinet music with a few exceptions including Mozart's Clarinet Concerto and this Messiaen piece. :-) -- Martin ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Fri, 18 Mar 2011, Peter Chubb wrote: (from Messiaen's `Abime des Oiseaux', bar 13) -- a smooth crescendo over almost the full range of the instrument. Martin I love that piece ! Which is remarkable, since I hate most Martin clarinet music with a few exceptions including Mozart's Martin Clarinet Concerto and this Messiaen piece. :-) Hmm. You should try listening to some of Carl Maria von Weber's clarinet music. My personal favourite is his op 33, `Variationen über ein Thema aus Silvana' Hmm? I am afraid it was exactly the music of C.M. von Weber that started my aversion against clarinet music. When I was studying piano at the conservatory von Weber was played often by Clarinet players. They loved it, but all those fast and high notes and scales were only getting on my nerves. That single long crescendo note Messiaen wrote impressed me much more! But let's stay on-topic: Keep up the good work with your articulate script. Any chance articulate will be an integrated, built-in functionality in Lilypond in the future ? -- Martin___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Fri, Mar 18, 2011 at 01:56:05AM +0100, Martin Tarenskeen wrote: But let's stay on-topic: Keep up the good work with your articulate script. Any chance articulate will be an integrated, built-in functionality in Lilypond in the future ? I estimate it would take about 5 hours from a Frog. I've been estimating this for the past few years, but nobody's even attempted to tackle it yet. So, I guess not much chance. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
2011/3/17 Graham Percival gra...@percival-music.ca: I estimate it would take about 5 hours from a Frog. I've been estimating this for the past few years, but nobody's even attempted to tackle it yet. It is a feature that already works... would be nice to have! :-) Are there any downside? increased rendering time? anyknown bugs? ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
Re: New version of articulate available
On Thu, Mar 17, 2011 at 10:20:38PM -0300, Bernardo Barros wrote: 2011/3/17 Graham Percival gra...@percival-music.ca: I estimate it would take about 5 hours from a Frog. I've been estimating this for the past few years, but nobody's even attempted to tackle it yet. It is a feature that already works... would be nice to have! :-) Patches appreciated. Are there any downside? increased rendering time? anyknown bugs? No known downsides by me, at least. Theoretically I suppose it would be slightly slower rendering time, but certainly not humanly-noticeably slower. Cheers, - Graham ___ lilypond-user mailing list lilypond-user@gnu.org http://lists.gnu.org/mailman/listinfo/lilypond-user
