|
|
Created:
13 years, 3 months ago by Carl Modified:
13 years, 3 months ago CC:
lilypond-devel_gnu.org Visibility:
Public. |
DescriptionAdd /chordGlissando to music functions
Patch Set 1 #
MessagesTotal messages: 11
In response to requests from the tablatures list, I've added this function to ly/music-functions-init.ly. I'm not totally sure that this should be part of the default lilypond installation. It seems a bit hacky to me. Please review. Thanks, Carl
Sign in to reply to this message.
I really like it. It is hackish indeed, and I can understand your concern. It certainly would make a great snippet, but I don't feel strongly against adding it to the default distribution. It probably depends whether this feature is used a lot or not (and I'm too unfamiliar with guitar music to be able to tell). As it is, I can't see anything missing or any room for improvements. The only other option I can imagine would be to heavily modify the glissando engraver, but I suspect it would be overkill. That being said, if we're to start accepting such tricks in the default distribution, then I can think of several great snippets that would also make good candidates for inclusion :-)
Sign in to reply to this message.
On 2010/12/11 18:52:28, Valentin Villenave wrote: > I really like it. [snip ..] > > That being said, if we're to start accepting such tricks in the default > distribution, then I can think of several great snippets that would also make > good candidates for inclusion :-) Maybe we could create a directory called hacks/, where items that we don't really want in the main code base but are of use to users could be stored. We could then add snippets demonstrating those hacks to the documentation, and they'd be accessed by something like \include "hacks/chord-glissando.ly" If we started doing this, though, how would we distinguish between hacks that go only in the LSR and those that go in the hacks/ directory? So perhaps this idea is a non-starter. Thanks, Carl
Sign in to reply to this message.
On 2010/12/11 18:52:28, Valentin Villenave wrote: > As it is, I can't see anything missing or any room for improvements. The only > other option I can imagine would be to heavily modify the glissando engraver, > but I suspect it would be overkill. Oh, I've just seen that Patrick S. suggested to place it in an optional .ly file; if it appears that this notation is specific to guitar, it would certainly be a more appropriate place than music-function-init.ly. That being said, I remember having seen such things in piano and violin scores as well... hm, tricky. Cheers, Valentin.
Sign in to reply to this message.
On Sat, Dec 11, 2010 at 8:04 PM, <Carl.D.Sorensen@gmail.com> wrote: > Maybe we could create a directory called hacks/, where items that we > don't really want in the main code base but are of use to users could be > stored. We could then add snippets demonstrating those hacks to the > documentation, and they'd be accessed by something like > > \include "hacks/chord-glissando.ly" > > If we started doing this, though, how would we distinguish between hacks > that go only in the LSR and those that go in the hacks/ directory? I like this a lot! I can imagine a way of doing that through a new LSR "hacks" tag, that would be automatically kept in sync with the hacks/ directory (except that these files would be treated differently, for example their \score block would be automatically commented out). The LSR isn't write-enabled right now, but as soon as I hear from Sebastiano I'll see if he finds this idea reasonable. Cheers, Valentin.
Sign in to reply to this message.
On 2010/12/11 19:16:13, Valentin Villenave wrote: > On Sat, Dec 11, 2010 at 8:04 PM, <mailto:Carl.D.Sorensen@gmail.com> wrote: > > If we started doing this, though, how would we distinguish between hacks > > that go only in the LSR and those that go in the hacks/ directory? > > I like this a lot! I can imagine a way of doing that through a new LSR > "hacks" tag, that would be automatically kept in sync with the hacks/ > directory (except that these files would be treated differently, for > example their \score block would be automatically commented out). My question wasn't technical, but logical. Not "How can we keep the hacks snippets synchronized", but "How do we decide which snippets deserve to go in hacks?" If we could establish some criteria, then maybe this is a feasible idea.
Sign in to reply to this message.
On Sat, Dec 11, 2010 at 07:04:20PM +0000, Carl.D.Sorensen@gmail.com wrote: > On 2010/12/11 18:52:28, Valentin Villenave wrote: > >That being said, if we're to start accepting such tricks in the > default > >distribution, then I can think of several great snippets that would > also make > >good candidates for inclusion :-) > > Maybe we could create a directory called hacks/, where items that we > don't really want in the main code base but are of use to users could be > stored. I tried to organize that during GDP. Nobody was interested. I tried to get somebody to look into a few technical questions over the summer: http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00407.html but nobody was interested. Granted, that last email isn't terribly encouraging, but I stand by the main points: 1. somebody needs to do some research 2. nothing is happening until 2.14 is out > If we started doing this, though, how would we distinguish between hacks > that go only in the LSR and those that go in the hacks/ directory? That's the easiest part. One person takes responsibility as the ly/ maintainer (or ly/hacks/, if you prefer), and *they* decide. Or, given our collective disinterest in taking on responsibilities, maybe that's the hardest part. :| > So perhaps this idea is a non-starter. *sigh* Like so many ideas that people have for lilypond, it's a nice idea. It's such a nice idea that multiple people have had it years previously. Our problem is not a lack of nice ideas. The problem is people willing to work on those ideas. There's a bunch of areas where we suffer from a lack of organization, of course, but we have a plan for sorting those out, and in six months or so they should all be settled. Our main problem is that we have too many ideas and not enough work being done to implement those ideas. In army terms, we need "boots on the ground". Cheers, - Graham
Sign in to reply to this message.
Could it go in a separate optional-include \include "guitar.ly" file? I'd sign off with no qualms if it were optional.
Sign in to reply to this message.
On 12/11/10 12:39 PM, "Graham Percival" <graham@percival-music.ca> wrote: > On Sat, Dec 11, 2010 at 07:04:20PM +0000, Carl.D.Sorensen@gmail.com wrote: >> On 2010/12/11 18:52:28, Valentin Villenave wrote: >>> That being said, if we're to start accepting such tricks in the >> default >>> distribution, then I can think of several great snippets that would >> also make >>> good candidates for inclusion :-) >> >> Maybe we could create a directory called hacks/, where items that we >> don't really want in the main code base but are of use to users could be >> stored. > > I tried to organize that during GDP. Nobody was interested. I > tried to get somebody to look into a few technical questions over > the summer: > http://lists.gnu.org/archive/html/lilypond-devel/2010-07/msg00407.html > but nobody was interested. > > Granted, that last email isn't terribly encouraging, but I stand > by the main points: > 1. somebody needs to do some research > 2. nothing is happening until 2.14 is out I agree with the main points. I think, though, that my proposal was different from Mike's. My proposal is a simple directory with hacks in it. Mike's is a modular architecture that supports documentation as well as .ly code. > >> If we started doing this, though, how would we distinguish between hacks >> that go only in the LSR and those that go in the hacks/ directory? > > That's the easiest part. One person takes responsibility as the > ly/ maintainer (or ly/hacks/, if you prefer), and *they* decide. > Or, given our collective disinterest in taking on > responsibilities, maybe that's the hardest part. :| > OK. > > There's a bunch of areas where we suffer from a lack of > organization, of course, but we have a plan for sorting those out, > and in six months or so they should all be settled. Our main > problem is that we have too many ideas and not enough work being > done to implement those ideas. In army terms, we need "boots on > the ground". OK. Carl
Sign in to reply to this message.
On 2010/12/11 19:42:50, Graham Percival wrote: > Could it go in a separate optional-include > \include "guitar.ly" > file? I'd sign off with no qualms if it were optional. Absolutely, but it won't be guitar.ly, it'll be stringed-instruments.ly. New patch coming soon.
Sign in to reply to this message.
On 2010/12/11 20:11:45, Carl wrote: > On 2010/12/11 19:42:50, Graham Percival wrote: > > Could it go in a separate optional-include > > \include "guitar.ly" > > file? I'd sign off with no qualms if it were optional. > > Absolutely, but it won't be guitar.ly, it'll be stringed-instruments.ly. I've transferred this to Patrick Schmidt, since he wants to take it on. I'm closing this issue.
Sign in to reply to this message.
|